我们是一家主要负责.NET LOB开发的MS工作室。我们还为我们的CRM应用程序使用MS Dynamics ...所有开发人员目前都在使用VS / SQL Server 2008.我们也使用VSS，但是每个人都讨厌它在工作中并且很快就会出局。
我们正在开始整个团队的TDD实施计划（〜十几个人）。我已经获得TeamCity设置并使用2008 sln构建器成功运行我的第一个自动构建，并使用同事已设置的SVN进行源代码控制分析。在演示管理时，我认为他们开始购买我的蛇油，并提出了调查TFS的建议。
这让我对我的TDD架构的计划感到不满;尽管如此，因为我一直认为TFS太昂贵而且对我们的团队来说不值得（而且我在其他商店也看到了相同的情况）。我觉得MS在TDD / CI领域已落后多年，第三方产品可能更好，更成熟......我还需要做很多研究，但我想我会来这里看看如果有人实际使用过两个系统。
我意识到TFS包含的内容远远多于构建服务器......但我不想至少故意将这个问题过于宽泛。 使用TFS / TFB代替TeamCity的实际利弊是什么 - 例如我们会失去/获得哪些好处？有没有人在这里实际使用过这两个系统（TFS for TDD / CI和TeamCity / SVN）并且可以从实际的角度讲话？</ em>
我已经对这个主题进行了一些搜索，我在SO上找到的一篇帖子提到TFB的缺点是它只支持MSBuild。我打算在TeamCity上使用FinalBuilder;它似乎也支持TFS ......
感谢您的任何建议
编辑：有没有人使用TFS作为他们的构建/ CI服务器，可以判断成功/失败的故事？
答案 0 :(得分：75)
我们是一家小型开发商店，并认为Team Foundation Server为我们带来了太多开销。我们曾经编写过自定义MSBuild脚本来从命令行运行，但在我们发现TeamCity之后，我们将整个构建过程移到了它上面。
我们发现TeamCity易于使用和配置，JetBrains提供了出色的支持和文档。与Microsoft相比，它们的发布和更新周期也要快得多。
他们对SVN源代码控制的支持非常好，我们喜欢它们同时支持MSTest和NUnit进行单元测试。
我们也很喜欢TeamCity Professional版本是免费的，因此我们可以对其进行评估以确定它是否适用于我们。我们还没有达到需要我们升级到企业版的项目配置数量（20）。
答案 1 :(得分：29)
This question对TeamCity有很多好的答案。它与TFS无法比较，但它可能会为您提供一些关于TeamCity的信息。
我已经使用了两者，并且两者都取得了成功，但TeamCity变得如此简单。 TeamCity设置和配置轻而易举。 TFS不是。 TeamCity坚如磐石，易于维护，只是简单的工作。 JetBrains的开发人员在回应社区方面做得很好。他们每6至8个月发布一次，增加了真正的价值。 TFS的周期为2年或更长。
TeamCity为您提供了更多选择，包括您的构建方式以及您使用的源代码控制。它不是一体的，但这有时是一件好事。它也有一套很好的扩展点。我们也非常满意它的代理模型。
我在TeamCity中经历了3次绝对痛苦的升级。我们确实进行了一次TFS升级，将我们的构建和源代码控制权降低了3天。我是我们项目中TeamCity的管理员，每个月需要花费几个小时。 TFS每周花费几天时间。
TeamCity + SVN + VisualSVN一直是我工作过的最顺畅的环境.TFS在日常工作中一般都很流畅，但前提是有人在那里继续运行。
希望有所帮助
答案 2 :(得分：6)
TFS的好处是Microsoft支持的一个集成环境。我个人不喜欢TFS进行源代码管理，并且遇到了很多问题。这是笨重的，但它有VS集成的好处（在VisualSVN中也可用，但不是很强大）。
就个人而言，我认为使用SVN / TeamCity会好得多。它更容易使用，并且表现得更像您期望的那样。与大多数开源软件一样，两者都在不断发展，并且在Microsoft之前将始终拥有最新和最强大的功能。 2之间的整合非常好，我发现系统中没有致命的缺陷。我不断推动我现有的公司（我们使用TFS）走这条路，因为我相信这是一个更好的工作流程。作为额外的好处，它比通过TFS路线便宜得多。
我还使用了TFS的FinalBuilder - 我的问题是你在使用NANT / MSBuild无法用FinalBuilder购买什么？不幸的是，我店里的答案很少有IMO。
答案 3 :(得分：4)
首先，请看这篇文章：
SVN vs. Team Foundation Server
关于哪个环境更适合TDD等问题，我的两个问题是构建管理系统的重要性远远低于构建文件本身的内容。您的Ant或MSBuild文件应具有执行测试的目标。使用MSBuild或Ant，您不必使用MS的测试套件。您仍然可以使用nUnit或其他任何您想要的东西。这意味着，如果TFS正在调用您的MSBuild文件，或者如果是CruiseControl，或者TeamCity是否正常，则无关紧要。这些智能都在构建文件和与之集成的工具中。
我个人的选择不是被锁定在TFS的做事方式，因为你可以通过财富开源测试工具以更低的成本获得更多的自由。 TFS即将进行重大升级。如果您打算使用TFS，我的建议是至少等到2010年发布。专注于使您的MSBuild文件尽可能好。
话虽如此，我必须承认TFS拥有最好的构建系统之一（2005年很糟糕，2008年很不错）。能够在.NET代码中轻松自定义通知和发布过程非常酷 - 与CruiseControl.NET相比，您对构建和发布策略有更多的集中控制。
所以我使用了TFS和SVN / CCNet。我对TeamCity说的不多。但IMO构建管理系统应该与正在构建的内容及其构建方式相当不可知。对于我们来说，TFS为我们带来的发布管理流程中的额外控制对于我们来说，不足以证明完全集成的TFS解决方案的管理工作量大大增加。也不足以证明TFS额外的每个许可证成本是合理的，这可能很重要。
答案 4 :(得分：2)
旧的TFS Build是基于XAML的，非常繁琐且不适合使用。也就是说，新的TFS 2015构建系统更加突飞猛进，并且基于脚本，具有大量的Web挂钩和第三方集成;与Team City非常相似。此外，TFS现在支持Git，因此您不再局限于使用Team Foundation版本控制（TFVC）。此外，使用TFS，您可以使用自己的本地安装，也可以通过visualstudio.com利用托管解决方案。 TFS很棒，因为它是一个完全集成的环境（工作项目，规划，构建，测试，部署），而Team City只是一个构建解决方案。当这个问题最初在2010年被问到时，我会推荐Team City。但现在，这两个人非常有竞争力。我想说，如果你想要一个一体化的解决方案，那么可以归结为TFS，但如果你正在寻找纯粹的构建系统，那么Team City。
答案 5 :(得分：2)
将TeamCity与Visual Studio Team Services（Microsoft提供的最新基于云的产品）进行比较：
两者都非常适合实施持续集成流程
TeamCity更加成熟，一切正常。
相比之下，Visual Studio Team Services不断发展以赶上TeamCity，有些事情不能很好地工作（例如尝试根据Git发生变化的路径触发构建 - 文档很弱且功能很少本身不起作用（截至2016年8月））
Visual Studio Team Services使得只有基于云的代理运行您的构建变得容易（但是缺点是每个构建都需要为每个构建清理一下，这可能会增加一分钟或更长时间构建）。两者都可以支持本地构建代理，这些代理不需要为每个新构建擦除工作目录。
但在任何一种情况下，我都强烈建议您再看看CakeBuild，它会移动大部分有关如何从CI系统构建的配置信息以及Git中的C＃代码的大部分配置信息存储库以及所有其他源代码。使用CakeBuild，您可以在本地运行相同的构建，就像在CI系统中运行一样，如果您需要返回一个月来构建特定版本，则可以使用源代码和构建脚本来执行此操作。
使用CakeBuild，您现在可以在TeamCity和Visual Studio Team Services之间轻松切换。
CakeBuild的唯一缺点是所有构建步骤都捆绑在CI系统中的单个任务中，这使得报告稍微不那么好，并且可能需要一些额外的工作来将测试结果输出到CI报告系统的格式中可以使用。
答案 6 :(得分：1)
MS在TDD / CI领域落后数年
成为拥有TDD 4年的人，现在你是正确的。 MS仍然没有推广它，也没有提供与TDD流程兼容的工具。
不要因为任何类型的自动化，源代码控制或敏捷工作流程而处理Visual Studio（请停止使用TFS !!）。那些东西即使他们说的是＆＃34; new＆＃34;是单片的，总是带着奇怪的问题和臃肿。这总是很痛苦。
我使用过Team City，它简直太棒了，工作正常，专为可用性而设计，并且它设计得很好并且与大多数测试工具兼容等等很好地使用Visual Studio代码，没有别的。寻找外部和开源工具来帮助构建更好的CI。 ＆＃34;你可以在VS＆＃34;中做正确的事。卖不卖，而且不起作用。人们现在习惯并且总是将来自外部的不同工具结合起来以完成任务。依赖于所有MS工具集并不是IMO for .NET的方法。 MS喜欢卖＃34;嘿，你可以在这里做所有事情＆＃34;。但是当你走这条路并喝他们的koolade（TFS，MS Fakes等）时，你最终只会感到痛苦。
如果您计划进行TDD，那么您绝对不想使用所有MS工具。你要么被推下去，要么按照自己的方式推进＃34;当您尝试使用他们的工具进行TDD或完全限制时，通常是专有的和/或膨胀的。对于TDD，当您决定在不同的测试框架，断言库等中进行分层时，您需要能够有一些灵活性和选择。
在Team City之上添加Octopus，这是一个很棒的...你只会爱上它作为开发者或任何做DevOps的人。
停止尝试依赖微软在敏捷工具产品上的持续失败
开始在盒子外面寻找并尝试新的东西是我一直在重复的.NET世界，我过去是一名.NET开发人员，并且曾在MS世界之外尝试过新的东西。