Team Foundation Build 还是 TeamCity？

StackOverflow https://stackoverflow.com/questions/2239249

题

我们主要是一家从事 .NET LOB 开发的 MS 商店。我们还在 CRM 应用程序中使用 MS Dynamics...目前所有开发人员都在使用 VS/SQL Server 2008。我们也使用 VSS，但每个人在工作中都讨厌它，而且很快就会被淘汰。

我们正在开始在整个团队（约十几个人）中实施 TDD。我已经安装了 TeamCity，并使用 2008 sln 构建器以及使用同事设置的 SVN（正在进行源代码控制分析）成功运行了我的第一个自动构建。当向管理层进行演示时，我认为他们开始相信我的万金油，并抛弃了研究 TFS 的建议。

这打乱了我对 TDD 架构的规划；不过，这是一种好的方式，因为我一直认为 TFS 太贵了，对于我们的团队来说不值得（而且我在我工作过/知道的其他商店中也看到过同样的情况）。我确实觉得微软在 TDD/CI 领域落后了很多年，而且第三方产品可能更好、更成熟......我仍然需要做很多研究，但我想我应该来这里看看是否有人真正使用过这两个系统。

我意识到 TFS 不仅仅包含构建服务器......但我不想让这个问题变得太宽泛，至少是故意的。 使用 TFS/TFB 而不是 TeamCity 有哪些实际优点/缺点 - 例如我们会失去/获得哪些好处？这里有人实际使用过这两个系统（TFS for TDD/CI 和 TeamCity/SVN）并且可以从实际角度发言吗？

我对此主题进行了一些搜索，我在 SO 上找到的一篇文章提到 TFB 的缺点是它仅支持 MSBuild。我计划将 FinalBuilder 与 TeamCity 一起使用；看来它也支持 TFS...

感谢您的任何建议

编辑：有没有人使用 TFS 作为他们的构建/CI 服务器并且可以讲述成功/失败的故事？

有帮助吗？

解决方案

我们是一家小型开发公司，并认为 Team Foundation Server 为我们带来了太多开销。我们过去常常编写自定义 MSBuild 脚本以从命令行运行，但在发现 TeamCity 后，我们将整个构建过程转移到了它上面。

我们发现 TeamCity 易于使用和配置，并且 JetBrains 提供了出色的支持和文档。他们的发布和更新周期也比微软快得多。

他们对 SVN 源代码控制的支持非常好，我们喜欢他们支持 MSTest 和 NUnit 进行单元测试。

我们还喜欢 TeamCity Professional 版本是免费的，因此我们可以对其进行评估，看看它是否适合我们。我们尚未达到需要升级到企业版的项目配置数量 (20)。

其他提示

这个问题 有很多关于 TeamCity 的很好的答案。它无法与 TFS 进行比较，但它可能会让您对 TeamCity 有一些了解。

我使用过这两种工具，并且都取得了成功，但 TeamCity 简单得多。TeamCity 的设置和配置非常简单。TFS 不是。TeamCity 坚如磐石，易于维护，而且运行简单。JetBrains 的开发人员在响应社区方面做得非常出色。他们每 6 到 8 个月发布一次版本，以增加真正的价值。TFS 的周期为 2 年或更长。

TeamCity 为您提供了更多构建方式和使用源代码控制的选择。虽然这不是全部，但有时这是一件好事。它还有一组很好的扩展点。我们也对其代理模式感到非常满意。

我在 TeamCity 中经历了 3 次绝对痛苦的升级。我们所做的一次 TFS 升级使我们的构建和源代码控制停止了 3 天。我是我们项目的 TeamCity 管理员，每个月需要花费几个小时。TFS 每周需要几天时间。

TeamCity + SVN + VisualSVN 是我工作过的最流畅的环境。TFS 日常运行总体上很顺利，但前提是有人在场保持其运行。

希望有帮助

TFS 的优点是 Microsoft 支持的一种集成环境。我个人不喜欢使用 TFS 进行源代码控制，并且遇到了很多问题。它很笨重，但是它具有 VS 集成的好处（VisualSVN 中也提供了这种集成，但没有那么强大）。

就我个人而言，我认为使用 SVN/TeamCity 会更好。它只是更容易使用并且表现得更符合您的预期。与大多数开源软件一样，两者都在不断发展，并且始终会先于 Microsoft 拥有最新、最强大的功能。两者之间的集成非常好，我没有发现系统中存在致命缺陷。我在当前的公司不断推动走这条路（我们使用 TFS），因为我相信这是一个更好的工作流程。另一个好处是，它比采用 TFS 路线便宜得多。

我还将 FinalBuilder 与 TFS 一起使用 - 我的问题是，您真正使用 FinalBuilder 购买的东西是您无法使用 NANT/MSBuild 实现的吗？不幸的是，我店里的答案在我看来很少。

首先，请看这个帖子：

SVN 对比团队基础服务器

至于您提出的关于哪种环境更好地促进 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 不能说太多。但在我看来，构建管理系统应该完全不知道正在构建的内容以及构建方式。对于我们来说，TFS 为我们带来的发布管理流程中的额外控制不足以让我们证明完全集成的 TFS 解决方案大幅增加的管理工作是合理的。这也不足以证明 TFS 每个许可证的额外成本是合理的，这一成本可能很高。

旧的 TFS Build 基于 XAML，非常麻烦，而且不好用。也就是说，新的 TFS 2015 构建系统实现了跨越式发展，并且基于脚本，具有大量 Web 挂钩和第 3 方集成；与团队城市非常相似。此外，TFS 现在支持 Git，因此您不再局限于使用 Team Foundation 版本控制 (TFVC)。此外，借助 TFS，您可以使用自己的本地安装，或者可以通过 Visualstudio.com 利用托管解决方案。TFS 很棒，因为它是一个完全集成的环境（工作项、规划、构建、测试、部署），而 Team City 只是一个构建解决方案。当这个问题最初在 2010 年被问到时，我会毫不犹豫地推荐 Team City。但现在，两者的竞争非常激烈。我想说，如果您想要一个一体化的解决方案，那么可能会选择 TFS，但如果您只是寻找一个纯粹的构建系统，那么 Team City。

将 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 报告系统可以使用的格式。

MS 在 TDD/CI 领域落后多年

作为一个已经 TDD 了 4 年的人，你是对的。MS 甚至还没有推广它，也没有提供与 TDD 流程配合良好的工具。

不要在任何类型的自动化、源代码控制或敏捷工作流程期间陷入使用 Visual Studio 的困境（请停止使用 TFS！！）。即使他们说这些东西是“新的”，但它们却是单一的，并且总是伴随着奇怪的问题和臃肿。总是很痛苦。

我使用过 Team City，它简直太棒了，一切正常，它是为可用性而设计的，而且它设计得很好并且与大多数测试工具兼容，等等。可以使用 Visual Studio 编写代码，仅此而已。寻找外部和开源工具来帮助构建更好的 CI。“你可以在 VS 中做所有正确的事”这样的推销不是推销，也行不通。现在的人们习惯于并且总是结合外部的不同工具来完成工作。在我看来，依赖所有 MS 工具集并不是 .NET 的最佳选择。MS 喜欢推销“嘿，你可以在这里做所有事情”。但当你走这条路并喝他们的 kolade（TFS、MS Fakes 等）时，你最终除了痛苦什么也没有。

如果您打算进行 TDD，您肯定不想使用所有 MS 工具。当您尝试使用他们的工具进行 TDD 时，您要么会被迫采用“他们的方式”做事，而这些方式通常是专有的和/或臃肿的，要么会受到完全的限制。对于 TDD，当您决定分层使用不同的测试框架、断言库等时，您需要能够有一定的灵活性和选择。

添加 章鱼 在 Team City 之上，它非常出色……作为开发人员或从事 DevOps 的任何人，您都会爱上它。

停止尝试依赖微软在敏捷工具产品方面的持续失败

开始跳出框框并尝试新事物是我在 .NET 世界中不断重复的内容，我过去是一名 .NET 开发人员，并且尝试过 MS 世界之外的新事物。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top