团队基础构build或TeamCity？
我们是在做.NET LOB开发的大多数MS商店。 我们还为我们的CRM应用程序使用MS Dynamics …所有的开发人员目前都在使用VS / SQL Server 2008.我们也使用VSS，但每个人都讨厌它在工作，而且很快就会出来。
我们正在开始在整个团队中开展TDD实施（约十人）。 我已经获得了TeamCity的设置，并且使用2008 sln构build器成功运行了我的第一个自动构build版本，并且还使用了一名同事正在进行源代码控制分析的SVN。 在进行pipe理的时候，我觉得他们开始买进我的蛇油，抛出了看TFS的build议。
这就为我们的TDD架构计划了一把扳手; 尽pipe如此，因为我一直认为TFS太昂贵，不值得为我们的团队（我见过的其他商店也一样）。 我觉得MS在TDD / CI领域落后了多年，第三方产品可能更好，更成熟……我仍然需要做很多研究，但是我想我会来这里看看如果有人真的使用了这两个系统。
我意识到TFS包含了更多的构build服务器……但是我至less故意不想让这个问题过于宽泛。 使用TFS / TFB而不是TeamCity的实际利弊是什么 – 例如，我们会失去/获得哪些好处？ 这里有没有人真正使用过这两个系统（TFS的TDD / CI和TeamCity / SVN），可以从实际angular度讲？
我在这个话题上做了一些研究，我在SO上发现的一篇文章提到TFB的缺点是它只支持MSBuild。 我打算在TeamCity上使用FinalBuilder; 它似乎也支持TFS以及…
感谢您的任何build议
编辑：有没有人使用TFS作为他们的Build / CI服务器，可以告诉成功/失败的故事？
我们是一家小型开发商店，并决定Team Foundation Server为我们带来了太多的开销。 我们习惯编写自定义的MSBuild脚本从命令行运行，但是在我们发现TeamCity之后，我们将整个构build过程转移到了它上面。
我们发现TeamCity易于使用和configuration，JetBrains提供了出色的支持和文档。 与微软相比，它们的发布和更新周期也要快得多。
他们对SVN源代码控制的支持非常好，我们喜欢它们支持MSTest和NUnit进行unit testing。
我们也喜欢TeamCity专业版是免费的，所以我们可以评估它是否适合我们。 我们还没有达到需要我们升级到企业版的项目configuration数量（20）。
这个问题有很多关于TeamCity的很好的答案。 它不和TFS相比，但它可能会为TeamCity带来一些亮点。
我已经使用了两者，而且两者都取得了成功，但TeamCity要容易得多。 TeamCity很容易设置和configuration。 TFS不是。 TeamCity坚如磐石，易于维护，简单易用。 JetBrains的开发人员在响应社区方面做得很好。 他们每6到8个月就会发布一次，增加实际价值。 TFS是在2年或更多的周期。
TeamCity为您提供了更多的select，如何构build和使用什么源代码控制。 这并不是一回事，但这有时是一件好事。 它也有一个很好的扩展点。 我们也对它的代理模式感到非常满意。
我在TeamCity中经历了3次绝对的痛苦升级。 我们做的一个TFS升级把我们的构build和源代码控制下来了3天。 我是TeamCity的pipe理员，每个月需要花费几个小时。 TFS每周花了几天时间。
TeamCity + SVN + VisualSVN是我曾经工作过的最stream畅的环境.TFS在日常工作中一般都很stream畅，但只有当有人在那里保持运行的时候。
希望有所帮助
TFS的好处是微软支持的一个集成环境。 我个人不喜欢TFS的源代码控制，并有一些与它的问题。 它是笨重的，但它有VS集成的好处（VisualSVN中也有这个function，但不是那么强大）。
我个人认为使用SVN / TeamCity会更好。 这只是更容易工作，并像你所期望的那样行事。 和大多数开源软件一样，它们都在不断地发展，并将永远拥有微软之前的最新和最伟大的function。 2之间的整合非常好，我发现系统中没有致命的缺陷。 我经常在我现在的公司（我们使用TFS）推动这条路线，因为我相信这是一个更好的工作stream程。 作为一个额外的好处，它比TFS路线要便宜得多。
我也用过TFS的FinalBuilder – 我的问题是，你真的用FinalBuilder购买了你用NANT / MSBuild不能做的事情？ 在我的店里的答案不幸的是IMO很less。
首先，看到这个post：
SVN vs. Team Foundation Server
至于你的问题是哪个环境更好的培养了TDD等等，我的两分钱就是构buildpipe理系统的重要性远远低于构build文件本身。 你的Ant或MSBuild文件应该有你的testing目标。 使用MSBuild或Ant，您不必使用MS的testing套件。 你仍然可以使用nUnit或任何你想要的。 这意味着如果TFS正在调用您的MSBuild文件，或者CruiseControl是，或者TeamCity是无关紧要的。 智能都在构build文件中，并与你整合的工具。
我个人的select并不是把TFS的方式locking，因为你拥有更多的自由度，而且开源testing工具的成本要低很多。 TFS即将获得重大升级。 如果你打算使用TFS，我的build议是至less要等到2010年才能发布。 集中精力使你的MSBuild文件尽可能的好。
这就是说，我必须承认，TFS拥有最好的构build系统之一（2005年非常糟糕，2008年不错）。 在.NET代码中能够轻松定制通知和发布过程非常酷 – 与CruiseControl.NET相比，您对构build和发布策略拥有更多的中央控制权。
所以我使用了TFS和SVN / CCNet。 我对TeamCity不太了解。 但是海事组织的build设pipe理体系应该对正在build设什么以及如何build设有相当的把握。 对于我们来说，TFS给我们带来的发布pipe理stream程的额外控制权，对我们来说是不足以certificate完全集成的TFS解决scheme大大增加pipe理成本的。 也不足以certificateTFS额外的每个许可证费用是可观的。
旧的TFS Build是基于XAML的，非常麻烦，而且不太好用。 也就是说，新的TFS 2015构build系统是跨越式的，并且是基于大量Web钩子和第三方集成的脚本。 与Team City非常相似。 此外，TFS现在支持Git，因此您不再局限于使用Team Foundation版本控制（TFVC）。 另外，通过TFS，您可以使用自己的本地安装，也可以通过visualstudio.com利用托pipe解决scheme。 TFS很棒，因为它是一个完全集成的环境（工作项目，计划，构build，testing，部署），而Team City只是一个构build解决scheme。 当这个问题最初在2010年被问到的时候，我会build议Team City的。 现在虽然这两个是非常有竞争力的。 我想说，如果你想要一个全function于一身的解决scheme，然后去TFS，但如果你正在寻找纯粹的构build系统，然后团队城市。
比较TeamCity和Visual Studio Team Services（微软提供的最新的基于云的产品）：
-
两者对于实施持续集成过程都非常有效
-
TeamCity更成熟，一切正常。
-
相比之下，Visual Studio Team Services不断发展，赶上了TeamCity，有些东西不能正常工作（例如尝试触发基于Git变化的path构build – 文档太弱，而且function本身不起作用（截至2016年8月））
-
Visual Studio Team Services使得只有基于云的代理运行你的构build变得容易（然而，不利的一面是每个构build都需要为每个构build执行一次清理，这可能会增加一分钟或更多的构build）。 两者都可以支持本地构build代理，不需要为每个新构build擦除工作目录。
但无论哪种情况，我都强烈build议您查看一下CakeBuild，它将大部分有关如何从CI系统构build出来的configuration信息移植到Git存储库中的C＃代码以及所有其他源代码中。 使用CakeBuild，您可以在本地运行相同的构build，因为您将在CI系统中运行，并且如果您需要返回一个月以构build特定版本，则需要使用源代码和构build脚本来执行此操作。
使用CakeBuild，您现在可以轻松地在TeamCity和Visual Studio Team Services之间切换。
CakeBuild唯一的缺点是你所有的构build步骤都捆绑在CI系统中的一个任务中，这使得报告稍微不太好，并且可能需要一些额外的工作来将testing结果转换成CI报告系统可以使用的格式。
MS在TDD / CI领域落后多年
作为TDD已经有4年了，现在你是对的。 MS甚至还没有推广它，也没有提供与TDDstream程一致的工具。
不要因为任何types的自动化，源代码pipe理或敏捷工作stream程而停滞不前（请停止使用TFS !!）。 即使他们说“新”，这东西是铁板一块，总是带有怪异的问题和膨胀。 这总是很痛苦。
我已经使用了Team City，这真是太神奇了，事情起作用了，它是为可用性devise的，而且它devise的很好，并且与大多数所有testing工具等兼容。使用Visual Studio代码很好，没有别的。 寻找外部和开源工具来帮助构build更好的CI。 “你可以做一切正确的VS”卖不卖，它不工作。 现在的人们习惯于总是把外面的各种工具组合起来，把事情做好。 依赖于所有的MS工具集，只是没有去的国际海事组织的.NET。 MS喜欢卖“嘿，你可以做一切就在这里”。 但是，当你走上这条路线并喝着它们的青葱（TFS，MS Fakes等）时，你最终只会感到痛苦。
如果你打算做TDD，你肯定不想使用所有的MS工具。 当你试图用工具进行TDD或完全限制时，你可能会被推倒“做他们自己的方式”，这些做法往往是专有的和/或臃肿的。 对于TDD，当您决定在不同的testing框架，断言库等中进行分层时，您需要能够具有一定的灵活性和select性。
在团队城市之上添加八达通 ，而且它非常出色…您只需要以开发人员或DevOps的任何人的身份爱上它。
不要试图依靠微软在敏捷工具方面继续失败
从盒子外面开始寻找，尝试新的东西是我一直重复.NET世界的东西，我过去是.NET开发人员，曾经在MS世界以外尝试过新的东西。
