问题描述
今天我们使用TFS 2008进行源代码管理，我想我们将在TFS 2010的RTM上加快。
Today we are using TFS 2008 for source control, and I imagine we will go for TFS 2010 as quick it goes RTM.
我们将使用一些继续集成工具但是哪一个？
我一直在寻找TeamCity和CruiseControl.NET两者看起来不错（TeamCity有一点更容易配置）。我看到一些关于TFS 2010自动化工具的真正有希望的截屏，它看起来真的很好。
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.
我应该使用哪一个？
推荐答案
鉴于您已在使用TFS，我会首先尝试TFS的CI工具，并在您的决定不满足您的需求时重新考虑您的决定。事实上，TFS 2008具有CI功能：我会尽快设置它们，而不是等到2010年才会下降。
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.
我的团队正在使用TFS 2008的CI功能他们为我们工作得相当不错。设置构建本身并不困难，并且与TFS的工作项的集成是相当牢固的（工作项是在构建失败的情况下创建的）。
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).
我承认我们的系统是相当简单的：我们还没有把腿的工作在组件版本控制（因为它看起来像一个大量的腿工作） 不是单元测试（不幸的是）。看来MSTest单元测试只会下降，虽然！
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!
这篇关于CruiseControl，TeamCity和Team Foundation Server之间的比较的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！