CruiseControl、TeamCity 和 Team Foundation Server 之间的比较
今天我们使用 TFS 2008 进行源代码控制，我想我们会像 RTM 一样快速地使用 TFS 2010。
我们将使用一些持续集成工具，但是哪一个呢？ 我一直在研究 TeamCity 和 CruiseControl.NET，两者似乎都相当不错（TeamCity 更容易配置）。我看过一些关于 TFS 2010 自动化工具的非常有前途的截屏视频，它看起来非常好。但我只触及了这些工具的表面。
我应该使用哪一个？
Today we are using TFS 2008 for source control, and I imagine we will go for TFS 2010 as quick it goes RTM.
We are going to use some continues integration tool but which one?
I have been looking at both TeamCity and CruiseControl.NET both seems quite good (TeamCity were a little more easy to configure). I have seen some really promising screencast about TFS 2010 automation tools and it looks really good. But I have only scratched the surface of the tools.
Which one should I use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我们从 CruiseControl.NET 和 NAnt 开始。这些都是免费工具，让您完全掌控。它们确实通过插件与TFS源代码管理集成。缺点是学习曲线、糟糕的文档（针对 CC.NET）和 XML 编辑。这归结为一名开发人员（我）维护脚本。
我们最终切换到了 TeamCity。它与TFS源代码控制集成；大多数标准操作都可以立即完成。它易于使用（基于网络），因此任何开发人员都可以在其中设置他或她的项目，只需最少的培训。对于高级用法，它与 NAnt 集成。您将需要一个相当大的服务器来用于构建机器（尽管代理可以是分布式的）。
我还没有尝试过 TFS CI 功能； TeamCity 做我们需要它做的事情。对于初学者来说有一个免费版本；如果您的规模超出了这个范围，那么对于中型开发商店来说，许可证的价格是合理的。
We started with CruiseControl.NET and NAnt. These are free tools and give you total control. They do integrate with TFS source control through a plug-in. The disadvantages were learning curve, poor documentation (for CC.NET), and XML editing. It came down to one developer (me) maintaining the scripts.
We finally switched to TeamCity. It integrates with TFS source control; most standard actions can be done out of the box. It's easy to use (web-based), so any developer can set up his or her project in it with minimal training. For advanced usages, it integrates with NAnt. You will want a fairly hefty server for the build machine (although agents can be distributed).
I haven't tried the TFS CI features; TeamCity does what we need it to do. There's a free version for starters; if you outgrow that, a license is reasonably priced for a mid-size development shop.
鉴于您已经在使用 TFS，我会首先尝试 TFS 的 CI 工具，如果它不能满足您的需求，我会重新考虑您的决定。事实上，TFS 2008 具有 CI 功能：我会尽早设置它们，而不是等到 2010 年才放弃。
我的团队现在正在使用 TFS 2008 的一些 CI 功能，它们对我们来说运行得相当好。设置构建本身并不困难，并且与 TFS 工作项的集成非常可靠（在构建失败时会立即创建工作项）。
我承认我们的系统相当简单：我们还没有进行组装版本控制的腿部工作（因为它看起来像是大量的腿部工作），并且我们也没有进行单元测试（不幸的是）。看来 MSTest 单元测试会直接介入！
Given that you're already using TFS, I'd try TFS' CI tools first and reconsider your decision in the event that it doesn't meet your needs. In fact, TFS 2008 has CI features: I'd set them up sooner rather than waiting until 2010 to drop.
My team is using some of TFS 2008's CI features now and they've been working reasonably well for us. Setting up the builds themselves was not difficult and the integration with TFS's work items is quite solid (work items are created in the event of build failure out of the box).
I will admit our system is fairly simplistic: we have not yet put the leg work in for assembly versioning (since it looked like a great deal of leg work) and we're not unit testing either (unfortunately). It seems MSTest unit testing would just drop right in though!