Team Foundation Build或TeamCity？

我们大多是在做.NET LOB开发工作的MS商店。我们还为我们的CRM应用程序使用MS Dynamics ...所有的开发人员目前都在使用VS/SQL Server 2008.我们也使用VSS，但每个人都在讨厌它在工作，而且很快就会出来。Team Foundation Build或TeamCity？

我们正在开始在整个团队中开展TDD实施（约10人）。我已经获得了TeamCity的设置，并使用2008 sln构建器成功运行了我的第一个自动构建版本，并且还使用了SVN，一名同事设置了谁在进行源代码控制分析。在向管理层演示时，我认为他们开始购买我的蛇油，并抛出了关注TFS的建议。

这引发了我为我们的TDD架构计划的一个扳手;尽管如此，因为我一直认为TFS太昂贵，不值得为我们的团队服务（我在其他工作过的商店也看到过相同的情况）。我觉得MS在TDD/CI领域落后多年，第三方产品可能更好，更成熟......我仍然需要做很多研究，但我想我会来这里看看如果任何人实际上使用了两个系统。

我意识到TFS包含更多的构建服务器......但我不想让这个问题太宽泛，至少是故意的。使用TFS/TFB代替TeamCity的实际优点/缺点是什么？我们会失去/获得哪些好处？有没有人在这里实际使用过两种系统（TFS用于TDD/CI和TeamCity/SVN），并且可以从实际角度讲话？

我已经做了一些关于这个主题的搜索，我在SO上发现的一篇文章提到TFB的缺点是它只支持MSBuild。我正计划在TeamCity上使用FinalBuilder;它似乎它也支持TFS以及...

感谢您的任何意见

编辑：有没有人使用TFS作为他们的编译/ CI服务器，可以告诉成功/失败的故事？

来源

2010-02-10 dferraro

它不一定是一个/或问题。我们使用TFS进行源代码控制和项目管理，TeamCity for CI（它与TFS源代码控制集成），NUnit用于编写测试，NAnt用于扩展TeamCity，以及ReSharper用于NUnit/VS集成（等等）。 – TrueWill 2010-02-20 17:24:23

@TrueWill，你是否能够将TeamCity构建连接回TFS构建报告？我们正在做类似于您的商店，但希望TFS项目管理能够查看构建，以便我们可以将测试结果和错误报告相关联。 – 2011-02-03 16:27:15

@Rob - 不，我们还没有完成那么紧密的整合。我希望你不是建议发布失败的测试... – TrueWill 2011-02-03 18:38:19

我们是一家小型开发商店，并决定Team Foundation Server为我们承担了太多开销。我们习惯编写自定义的MSBuild脚本从命令行运行，但是在我们发现TeamCity之后，我们将整个构建过程转移到了它上面。

我们发现TeamCity易于使用和配置，而JetBrains提供了出色的支持和文档。与微软相比，它们的发布和更新周期也更快。

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

我们也很喜欢TeamCity专业版是免费的，所以我们可以评估它是否适合我们。我们还没有达到需要升级到企业版的项目配置数量（20）。

来源

2010-02-18 17:20:19 dthrasher

非常感谢这篇文章。这对于从TFS移动到TeamCity的人听到非常有用。出于好奇 - 你们是不是微软的商店？ – dferraro 2010-02-20 23:30:57

我不会说我们是严格的微软。我们主要使用.NET技术，但愿意从微软的视野之外寻找其他有用的工具和技术。我想这会让我们进入Alt.NET阵营。 :) – dthrasher 2010-02-22 19:01:53

我们也从TFS转移到了TeamCity + Subversion + VersionOne。首先，我们遇到了TFS下源代码控制的严重问题。然后，在经历了TFS项目管理的一些痛苦之后，我们被一个主要的MS咨询公司告知，我们应该调整我们的方法以适应MFS-Agile流程模板！此时，我们从TFS迁移出去，从未回头。 – 2010-07-15 07:20:12

TFS的好处是微软支持的一个集成环境。我个人不喜欢TFS的源代码控制，并且有许多问题。它很笨重，但是它具有VS集成的好处（VisualSVN也可以使用它，但并不稳健）。我个人认为你使用SVN/TeamCity会好得多。与您所期望的一样，它更容易合作并且表现得更加出色。与大多数开源软件一样，两者都在不断发展，并将始终具有微软之前的最新和最强大的功能。 2之间的整合非常好，我发现系统中没有致命的缺陷。我经常在我现在的公司（我们使用TFS）推动这条路线，因为我相信这是一个更好的工作流程。作为额外的好处，它比TFS路线要便宜得多。

我也用过Final Cutler与TFS--我的问题是你真的用FinalBuilder购买了你不能用NANT/MSBuild做什么？我的店里的答案不幸的是IMO很少。

来源

2010-02-11 13:54:29

感谢您的回应。真棒听到实际使用这两个系统的人。至于你的问题 - 因为我只是在设置TDD基础设施的概念验证阶段，所以我不确定FinalBuilder是否值得使用。从我读过的内容来看，虽然它使创建构建脚本变得更加容易，并且人们对它有很高的赞誉 - 但您是否发现要用手编辑构建脚本要好得多呢？ – dferraro 2010-02-11 16:29:09

它可能与我们对FinalBuilder的设置有很大关系，但是我们遇到了一系列问题，因为我们对解决方案的文件夹结构的假设在过去是不成立的。所以我们的FinalBuilder脚本已经变成了一个可以做很多不同事情的野兽。我没有看到它为我们带来了很多好处，超出了我们能够独自处理南特的情况。 – 2010-02-11 18:35:59

很好记住。 FinalBuilder看起来像一个伟大的销售 - 不必编写自己的构建脚本，只需按下按钮。猜猜它对于某些设置还是不成熟的。但是我听说它与使用它的人们在TeamCity上表现良好。也许TFS是你的阻碍因素？ – dferraro 2010-02-11 18:58:13

首先，看到这个帖子：

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额外的每次许可证费用，这可能很重要。

来源

2010-02-11 14:19:08

您提出了维护TFS解决方案的开销增加的好处。如果您真的尝试充分利用TFS，您至少需要一个全职工作为TFS管理员的人员。当然，你可以没有这个，但是TFS确实证明了成本。 – 2010-02-11 18:38:07

感谢您的好消息。不幸的是，从我在商业LOB软件方面的6年左右的经验来看，管理层几乎总是逃避并躲避附近的任何“开放源码”这个词。我想我永远不会明白为什么......如果你从他们那里隐瞒它的开源，他们永远不会注意到......; – dferraro 2010-08-25 02:07:10

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通常都很顺利，但只有当有人在那里保持运行。

希望帮助

来源

2010-02-18 17:38:38

旧TFS构建了基于XAML和非常繁琐，而不是好的工作。也就是说，新的TFS 2015构建系统是跨越式的，并且是基于大量Web钩子和第三方集成的脚本;与Team City非常相似。此外，TFS现在支持Git，因此您不再局限于使用Team Foundation版本控制（TFVC）。另外，通过TFS，您可以使用自己的本地安装，也可以通过visualstudio.com利用托管解决方案。 TFS非常棒，因为它是一个完全集成的环境（工作项目，计划，构建，测试和部署），而Team City只是一个构建解决方案。当这个问题最初在2010年被问到时，我会建议团队城市下手。但现在，这2人非常有竞争力。我想说的是，如果你想要一个全功能于一身的解决方案，那么可以归结为TFS，但是如果你只是在寻找纯粹的构建系统，那么Team City就是这样。

来源

2015-12-07 21:08:27 deadlydog

的TeamCity相较于Visual Studio团队服务（微软最新的基于云计算的产品）：

两个用于实现持续集成过程
TeamCity的是更加成熟和一切工作的伟大只是作品。
相比之下，Visual Studio团队服务不断发展，以赶上TeamCity，有些东西不能很好地工作（例如，尝试基于Git发生更改的路径触发构建 - 文档很弱并且功能本身只是不起作用（截至2016年8月））
Visual Studio Team Services使得只有基于云的代理运行您的构建变得很容易（但不利之处在于，每个代理都必须清理您的存储库对于每个构建可能会增加一分钟或更多的构建）。两者都可以支持本地构建代理，无需为每个新构建擦除工作目录。

但是在这两种情况下，我会强烈建议你也看看CakeBuild其移动量最多的配置信息有关如何做一个打造出来的CI系统，进入C＃代码，在你的Git仓库以及所有其他源代码。使用CakeBuild，您可以在本地运行相同的构建版本，因为您将在CI系统中运行，并且如果您需要返回一个月以构建特定版本，则需要使用源代码和构建脚本来执行此操作。

使用CakeBuild，您现在可以轻松地在TeamCity和Visual Studio Team Services之间切换。

CakeBuild唯一的缺点是你所有的构建步骤都捆绑到CI系统中的单个任务中，这使得报告稍微不太好，并且可能需要一些额外的工作来将测试结果转换为CI报告的格式系统可以使用。

来源

2016-08-30 00:50:23

MS是多年落后于TDD/CI区域

作为一个谁也TDD'd现在你是正确的4年。 MS仍然没有推广它，也没有提供与TDD流程相配的工具。

不要因为任何类型的自动化，源代码控制或敏捷工作流程期限而停止处理Visual Studio（请停止使用TFS请!!）。尽管他们说这些东西是“新的”，但它是单一的，总是伴随着奇怪的问题和膨胀。这总是很痛苦。

我已经使用Team City，它简直太棒了，事情有效，它是为可用性设计的，它设计的很好，并且与大多数所有测试工具等兼容。使用Visual Studio代码很好，没有别的。寻找外部和开源工具来帮助构建更好的CI。 “你可以做一切正确的VS”出售不是销售，它不工作。现在的人们习惯于并总是将来自外部的不同工具组合起来，以完成工作。依赖于所有的MS工具集只是不是去.NET for .NET的方式。 MS喜欢出售“嘿，你可以在这里做一切事情”。但是当你走上这条路线并喝着它们的小吃（TFS，MS Fakes等等）时，你最终只会感到痛苦。

如果你打算做TDD，你肯定不想使用所有的MS工具。当你尝试使用他们的工具进行TDD或完全限制时，你可能会被迫“做他们自己的做法”，这些做法往往是专有和/或臃肿的。对于TDD，当您决定在不同的测试框架，断言库等中分层时，您需要能够具有一定的灵活性和选择性。

在Team City之上添加Octopus，并且它非常出色......您将简单地落下爱上它作为开发人员或任何正在进行DevOps的人。

停止试图依靠微软继续在失败敏捷工具产品

开始看外包装箱和尝试新的东西是什么，我不断重复的.NET世界中，我是在过去的一个.NET开发人员，谁在MS世界以外尝试过新事物。

来源

2016-09-17 05:33:10 PositiveGuy

Team Foundation Build或TeamCity？

回答

相关问题