我们是一家从事.NET LOB开发工作的MS商店 . 我们还为我们的CRM应用程序使用MS Dynamics ...所有开发人员目前都在使用VS / SQL Server 2008.我们也使用VSS，但是每个人都讨厌它在工作中并且很快就会出局 .
我们正在开始整个团队的TDD实施计划（〜十几个人） . 我已经获得TeamCity设置并使用2008 sln构建器成功运行我的第一个自动构建，并使用同事已设置的SVN进行源代码控制分析 . 在演示管理时，我认为他们开始购买我的蛇油，并提出了调查TFS的建议 .
这让我对TDD架构的计划产生了不小的影响 . 尽管如此，因为我一直认为TFS太昂贵而且对我们的团队来说不值得（而且我在其他商店也看到了相同的情况） . 我觉得MS在TDD / CI领域已落后多年，第三方产品可能更好，更成熟......我还需要做很多研究，但我想我会来这里看看如果有人实际使用过两个系统 .
我意识到TFS包含的内容远远多于构建服务器......但我不想至少故意将这个问题过于宽泛 . What are the practical pros/cons of using TFS/TFB instead of TeamCity - e.g. which benefits would we lose/gain? Has anyone here actually used both systems (TFS for TDD/CI and TeamCity/SVN) and can speak from practical standpoint?
我已经对这个主题做了一些搜索，我在SO上找到的一篇帖子提到TFB的缺点是它只支持MSBuild . 我打算在TeamCity上使用FinalBuilder;看来它也支持TFS ......
谢谢你的建议
EDIT: Has anyone used TFS as their Build/CI server and can tell of success/failure stories?
7 回答
我们是一家小型开发商店，并认为Team Foundation Server为我们带来了太多的开销 . 我们曾经编写过自定义MSBuild脚本来从命令行运行，但在我们发现TeamCity之后，我们将整个构建过程移到了它上面 .
我们发现TeamCity易于使用和配置，JetBrains提供了出色的支持和文档 . 它们的发布和更新周期也比微软快得多 .
他们对SVN源代码控制的支持非常好，我们喜欢它们支持MSTest和NUnit进行单元测试 .
我们还喜欢TeamCity Professional版本是免费的，因此我们可以对其进行评估以确定它是否适用于我们 . 我们还没有达到要求我们升级到企业版的项目配置数量（20） .
This question对TeamCity有很多好的答案 . 它与TFS无法比较，但它可能会为您提供一些关于TeamCity的信息 .
我已经使用了两者，并且两者都取得了成功，但TeamCity更加容易 . TeamCity设置和配置轻而易举 . TFS不是 . TeamCity坚如磐石，易于维护，只是简单的工作 . JetBrains的开发人员在回应社区方面做得很好 . 他们每6至8个月发布一次，增加了真正的 Value . TFS的周期为2年或更长 .
TeamCity为您提供了更多选择，包括您的构建方式以及您使用的源代码控制 . 它不是一体的，但这有时是一件好事 . 它也有一套很好的扩展点 . 我们也非常满意它的代理模型 .
我在TeamCity中经历了3次绝对痛苦的升级 . 我们确实进行了一次TFS升级，将我们的构建和源代码控制权降低了3天 . 我是我们项目的TeamCity管理员，每个月需要花费几个小时 . TFS每周花费几天时间 .
TeamCity SVN VisualSVN一直是我工作过的最顺畅的环境.TFS在日常工作中一般都很流畅，但前提是有人在那里继续运行 .
希望有所帮助
TFS的好处是Microsoft支持的一个集成环境 . 我个人不喜欢TFS进行源代码管理，并且遇到了很多问题 . 它很笨重，但它有VS集成的好处（在VisualSVN中也可用，但不是那么健壮） .
就个人而言，我认为使用SVN / TeamCity会好得多 . 它更容易使用，并且表现得更像您期望的那样 . 与大多数开源软件一样，两者都在不断发展，并且在Microsoft之前将始终拥有最新和最强大的功能 . 2之间的整合非常好，我发现系统中没有致命的缺陷 . 我不断推动我现有的公司（我们使用TFS）走这条路，因为我相信这是一个更好的工作流程 . 它是一个额外的好处比去TFS路线要便宜得多 .
我也使用了TFS的FinalBuilder - 我的问题是你真的用FinalBuilder购买了什么，你不能用NANT / MSBuild做什么？不幸的是，我店里的答案很少 .
首先，请看这篇文章：
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的额外每个许可证成本是合理的，这可能很重要 .
旧的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 .
将TeamCity与Visual Studio Team Services（Microsoft最新的基于 Cloud 的产品）进行比较：
两者都非常适合实施持续集成流程
TeamCity更成熟，一切正常 .
相比之下，Visual Studio Team Services不断发展以赶上TeamCity，有些事情不能很好地工作（例如尝试根据Git变化的路径触发构建 - 文档很弱而且功能本身不是工作（截至2016年8月））
Visual Studio Team Services使得只运行构建的基于 Cloud 的代理变得容易（但是缺点是每个构建都需要为每个构建清理一下，这可能会为构建添加一分钟或更长时间） . 两者都可以支持本地构建代理，这些代理不需要为每个新构建擦除工作目录 .
但在任何一种情况下，我都强烈建议您查看CakeBuild，它将大部分有关如何构建CI系统的配置信息移动到Git存储库中的C＃代码以及所有其他源代码 . 使用CakeBuild，您可以在本地运行相同的构建，因为您将在CI系统中运行，如果您需要返回一个月来构建特定版本，则可以使用源代码和构建脚本来执行此操作 .
使用CakeBuild，您现在可以在TeamCity和Visual Studio Team Services之间轻松切换 .
唯一的缺点是CakeBuild是将所有构建步骤捆绑到CI系统中的单个任务中，这使得报告稍微不那么好，并且可能需要一些额外的工作来将测试结果转换为CI报告系统可以使用的格式 .
成为TDD已经4年的人现在你是对的 . MS仍然没有推广它，也没有提供与TDD流程兼容的工具 .
不要因为任何类型的自动化，源代码控制或敏捷工作流程而处理Visual Studio（请停止使用TFS !!） . 那些东西即使他们说是“新的”是单一的，总是伴随着奇怪的问题和膨胀 . 这总是很痛苦 .
我使用过Team City，它简直太棒了，工作正常，它是为可用性而设计的，它设计得很好并且与大多数测试工具兼容，等等 . 很好地使用Visual Studio代码，没有别的 . 寻找外部和开源工具来帮助构建更好的CI . “你可以在VS中做一切正确”的销售不是卖，而且它不起作用 . 人们现在习惯并且总是将来自外部的不同工具结合起来以完成工作 . 依赖于所有MS工具集并不是IMO for .NET的方法 . MS喜欢卖“嘿，你可以在这里做所有事情” . 但是当你走这条路并且喝他们的koolade（TFS，MS Fakes等）时，你最终只会感到痛苦 .
如果您计划进行TDD，您绝对不希望使用所有MS工具 . 当你尝试使用他们的工具进行TDD或者完全限制时，你要么被推倒“做事”，这些做事往往是专有的和/或臃肿的 . 对于TDD，当您决定在不同的测试框架，断言库等中进行分层时，您需要能够有一些灵活性和选择 .
在Team City之上添加Octopus，这是一个很棒的...你只会爱上它作为开发人员或任何做DevOps的人 .
停止尝试依赖微软在敏捷工具产品上的持续失败
开始在盒子外面寻找新的东西是我不断重复的.NET世界，我过去是一名.NET开发人员，曾在MS世界之外尝试过新的东西 .