Team Foundation Build 还是 TeamCity？
我们主要是一家从事 .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）并且可以从实际角度进行发言？
我已经对此主题进行了一些搜索，并且我在这里找到了一篇文章SO 提到 TFB 的缺点是它只支持 MSBuild。我计划将 FinalBuilder 与 TeamCity 一起使用；看起来它也支持 TFS...
感谢您的任何建议
编辑：有人使用 TFS 作为他们的构建/CI 服务器并可以讲述成功/失败的故事吗？
We are a mostly MS shop at work doing .NET LOB development. We also use MS Dynamics for our CRM app... all the devs are currently using VS/SQL Server 2008. We also use VSS, but everyone hates it at work and that is quickly on its way out.
We are begining our initiative for TDD implementation across the team (~dozen ppl). I've gotten TeamCity setup and have my first automated builds running succesfully using the 2008 sln builder and also using SVN that a co-worker had setup who is doing the source control analysis. When demoing to managament, I think they started to buy into my snake oil and threw out the suggestions of looking into TFS.
This threw a wrench in what I had planned for our TDD architecture; In a good way though, because I had always assumed that TFS was just too expensive and not worth it for our team (and i've seen the same in other shops i've worked at / know of). I do feel like MS is years behind in the TDD/CI area and that the third party products were probably much better and more mature... I still need to do a lot of research, but I figured I'd come here to see if anyone has actually used both systems.
I realize the TFS encompasses a lot more then just a build server... but I didn't want to make this too broad of a question at least on purpose. 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?
I've done some searching on this topic, and one post I found here on SO mentioned that the cons of TFB was it only supported MSBuild. I was planning on using FinalBuilder with TeamCity; and it appears it also supports TFS as well...
Thanks for any advice
EDIT: Has anyone used TFS as their Build/CI server and can tell of success/failure stories?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我们是一家小型开发公司，并认为 Team Foundation Server 为我们带来了太多开销。我们过去常常编写自定义的 MSBuild 脚本以从命令行运行，但在发现 TeamCity 后，我们将整个构建过程转移到它上面。
我们发现 TeamCity 易于使用和配置，并且 JetBrains 提供了出色的支持和文档。他们的发布和更新周期也比微软快得多。
他们对 SVN 源代码控制的支持非常好，我们喜欢他们支持 MSTest 和 NUnit 进行单元测试。
我们还喜欢 TeamCity Professional 版本是免费的，因此我们可以对其进行评估，看看它是否适合我们。我们尚未达到需要升级到企业版的项目配置数量 (20)。
We are a small development shop, and decided that Team Foundation Server carries too much overhead for us. We used to write custom MSBuild scripts to run from the command line, but after we discovered TeamCity, we moved our entire build process over to it.
We've found TeamCity to be easy to use and configure, and JetBrains provides excellent support and documentation. They are also on a much faster release and update cycle than Microsoft.
Their support for SVN source control is excellent, and we like the fact that they support both MSTest and NUnit for unit testing.
We also liked the fact that the TeamCity Professional edition was free, so we could evaluate it to see if it worked for us. We haven't hit the number of project configurations (20) that would require us to upgrade to the Enterprise edition.
这个问题有很多关于 TeamCity 的很好的答案。它无法与 TFS 进行比较，但它可能会让您对 TeamCity 有一些了解。
我使用过这两种工具，并且都取得了成功，但 TeamCity 简单得多。 TeamCity 的设置和配置非常简单。 TFS 不是。 TeamCity 坚如磐石，易于维护，而且运行简单。 JetBrains 的开发人员在响应社区方面做得非常出色。他们每 6 到 8 个月发布一次版本，以增加真正的价值。 TFS 的周期为 2 年或更长。
TeamCity 为您提供了更多构建方式和使用源代码控制的选择。虽然这不是全部，但有时这是一件好事。它还有一组很好的扩展点。我们也对其代理模式感到非常满意。
我在 TeamCity 中经历了 3 次绝对痛苦的升级。我们所做的一次 TFS 升级使我们的构建和源代码控制停止了 3 天。我是我们项目的 TeamCity 管理员，每个月需要花费几个小时。 TFS 每周需要几天时间。
TeamCity + SVN + VisualSVN 是我工作过的最流畅的环境。TFS 通常每天都很流畅，但前提是有人在那里保持它运行。
希望有帮助
This question has a lot of good answers about TeamCity. It does not compare to TFS but it might shed some light on TeamCity for you.
I have used both, and I have had success with both, but TeamCity was so much easier. TeamCity was a breeze to set up and configure. TFS was not. TeamCity is rock solid, it's easy to maintain and it just plain works. The developers at JetBrains have done a great job responding to the community. They get a release out every 6 to 8 months that adds real value. TFS is on a 2 year or more cycle.
TeamCity gives you more choice in how you build and what source control you use. It's not all in one, but that's sometimes a good thing. It's got a good set of extension points as well. We have also been really happy with the agent model it has.
I've gone through 3 absolutely painles upgrades in TeamCity. The one TFS upgrade we did took our build and source control down for 3 days. I'm the admin for TeamCity on our project and it takes up a couple of hours a month. TFS took a couple of days a week.
TeamCity + SVN + VisualSVN has been the smoothest environment I have ever worked in. TFS was generally smooth on the day to day, but only if someone was there keeping it running.
Hope that helps
TFS 的优点是 Microsoft 支持的一种集成环境。我个人不喜欢使用 TFS 进行源代码控制，并且遇到了很多问题。它很笨重，但是它具有 VS 集成的好处（VisualSVN 中也提供了这种集成，但没有那么强大）。
就我个人而言，我认为使用 SVN/TeamCity 会更好。它只是更容易使用并且表现得更符合您的预期。与大多数开源软件一样，两者都在不断发展，并且始终会先于 Microsoft 拥有最新、最强大的功能。两者之间的集成非常好，我没有发现系统中存在致命缺陷。我在当前的公司不断推动走这条路（我们使用 TFS），因为我相信这是一个更好的工作流程。另一个好处是，它比采用 TFS 路线便宜得多。
我还将 FinalBuilder 与 TFS 一起使用 - 我的问题是，您真正使用 FinalBuilder 购买的东西是您无法使用 NANT/MSBuild 实现的吗？不幸的是，我店里的答案在我看来很少。
The benefits of TFS are one integrated environment that is supported by Microsoft. I personally do not like TFS for source control and have had a number of issues with it. It is clunky, however it had the benefit of having VS integration (which is also available in VisualSVN, but is not as robust).
Personally, I think you would be much better off using SVN/TeamCity. It is just easier to work with and behaves more as you would expect. As with most open source software, both are constantly evolving and will always have the latest and greatest feature before Microsoft. The integration between the 2 is really good and I have found no fatal flaws in the system. I constantly push to go this route in my current company (we use TFS), as I believe it is a much better workflow. As an added benefit, it is significantly cheaper than going the TFS route.
I have also used FinalBuilder with TFS - my question there is what are you really buying with FinalBuilder that you can't do with NANT/MSBuild? The answer at my shop is unfortunately very little IMO.
首先，请参阅这篇文章：
SVN 与 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 不能说太多。但在我看来，构建管理系统应该完全不知道正在构建的内容以及构建方式。对于我们来说，TFS 为我们带来的发布管理流程中的额外控制不足以让我们证明完全集成的 TFS 解决方案大幅增加的管理工作是合理的。这也不足以证明 TFS 每个许可证的额外成本是合理的，这一成本可能很高。
First off, see this post:
SVN vs. Team Foundation Server
As to your question about which environment better fosters TDD and such, my two cents is that the build management system matters much less than what's in the build file itself. Your Ant or MSBuild file should have the targets that do your testing. With MSBuild or Ant, you don't have to use MS's test suite. You can still use nUnit or whatever else you want. That means it doesn't matter if TFS is calling your MSBuild file, or if CruiseControl is, or if TeamCity is. The smarts are all in the build file and the tools you integrate with it.
My personal choice is not to get locked down into TFS's way of doing things, since you have a lot more freedom for a lot less cost with the wealth open-source testing tools that are out there. TFS is about to receive a major upgrade, as well. If you are going to go with TFS, my advice is to at least wait until 2010 is released. Concentrate on making your MSBuild files as good as they can be right now.
That being said, I must admit that TFS has one of the nicest build systems out there (2005 was terrible, 2008 was nice). Being able to easily customize notifications and the release process all inside .NET code was pretty cool -- you had a lot more central control over build and release policy than we did with CruiseControl.NET.
So I've used TFS and SVN/CCNet. I can't speak much to TeamCity. But IMO a build management system should be fairly agnostic to what is being built and how it's being built. For us, the extra control in the release management process that TFS brought us just wasn't enough of a bonus for us to justify the greatly increased administrative effort of a fully integrated TFS solution. Nor was it enough to justify the extra per-license cost of TFS, which can be significant.
旧的 TFS Build 基于 XAML，非常麻烦，而且不好用。也就是说，新的 TFS 2015 构建系统实现了跨越式发展，并且基于脚本，具有大量 Web 挂钩和第 3 方集成；与团队城市非常相似。此外，TFS 现在支持 Git，因此您不再局限于使用 Team Foundation 版本控制 (TFVC)。此外，借助 TFS，您可以使用自己的本地安装，或者可以通过 Visualstudio.com 利用托管解决方案。 TFS 很棒，因为它是一个完全集成的环境（工作项、规划、构建、测试、部署），而 Team City 只是一个构建解决方案。当这个问题最初在 2010 年被问到时，我会毫不犹豫地推荐 Team City。但现在，两者的竞争非常激烈。我想说，如果您想要一个一体化的解决方案，那么可能会选择 TFS，但如果您只是寻找一个纯粹的构建系统，那么 Team City。
The old TFS Build was XAML based and very cumbersome and and not nice to work with. That said, the new TFS 2015 build system is leaps and bounds better, and is script based with lots of web hooks and 3rd party integrations; very similar to Team City. Also, TFS now supports Git, so you are no longer confined to using Team Foundation Version Control (TFVC). Also, with TFS you can use your own on-prem installation, or can take advantage of a hosted solution through visualstudio.com. TFS is great because it's one completely integrated environment (work items, planning, builds, tests, deployments), whereas Team City is just a build solution. When this question was originally asked in 2010 I would've recommended Team City hands down. Now though, the 2 are very competitive. I would say that it would maybe boil down to if you want an all-in-one solution, then go with TFS, but if you are looking for purely just a build system, then 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 报告系统可以使用的格式。
Comparing TeamCity to Visual Studio Team Services (the latest cloud-based offering from Microsoft):
Both work great for implementing a continuous integration process
TeamCity is more mature and everything just works.
Visual Studio Team Services by contrast is constantly evolving to catch up with TeamCity and some things just don't work well (e.g. try triggering builds based on paths that have changes from Git - the documentation is weak and the feature itself just doesn't work (as of August 2016))
Visual Studio Team Services makes it easy to have only cloud-based agents running your build (the downside however is that each has to do a clean pull of your repository for each build which may add a minute or more to the build). Both can also support local build agents which do not need to wipe the working directory for each fresh build.
But in either case I would highly recommend you also look at CakeBuild which moves most of the configuration information about how to do a build out of the CI system and into C# code that is in your Git repository along with all your other source code. With CakeBuild you can run the same build locally as you will run in the CI system and if you need to go back a month to build a specific version you have the source code and the build script to do it.
With CakeBuild in place you are now free to easily switch between TeamCity and Visual Studio Team Services.
The only downside to CakeBuild is that all your build steps are bundled into a single task in the CI system which makes reporting slightly less nice and may involve some extra work to get the test results out into a format that the CI reporting system can use.
作为一个已经 TDD 了 4 年的人，你是对的。 MS 甚至还没有推广它，也没有提供与 TDD 流程配合良好的工具。
不要在任何类型的自动化、源代码控制或敏捷工作流程期间陷入使用 Visual Studio 的困境（请停止使用 TFS！！）。即使他们说这些东西是“新的”，但它们却是单一的，并且总是伴随着奇怪的问题和臃肿。总是很痛苦。
我使用过 Team City，它简直太神奇了，一切正常，它是为可用性而设计的，而且它设计得很好，并且与大多数测试工具兼容等。很好地使用 Visual Studio 编写代码，仅此而已。寻找外部和开源工具来帮助构建更好的 CI。 “你可以在 VS 中做所有正确的事”这样的推销不是推销，也行不通。现在的人们习惯于并且总是结合外部的不同工具来完成工作。在我看来，依赖所有 MS 工具集并不是 .NET 的最佳选择。 MS 喜欢推销“嘿，你可以在这里做所有事情”。但当你走这条路并喝他们的 kolade（TFS、MS Fakes 等）时，你最终除了痛苦什么也没有。
如果您打算进行 TDD，您肯定不想使用所有 MS 工具。当您尝试使用他们的工具进行 TDD 时，您要么会被迫采用“他们的方式”做事，而这些方式通常是专有的和/或臃肿的，要么会受到完全的限制。对于 TDD，当您决定分层使用不同的测试框架、断言库等时，您需要能够有一些灵活性和选择。
添加 Octopus 在 Team City 之上，它非常出色......作为开发人员或任何从事 DevOps 的人，您都会爱上它。
停止尝试依赖 Microsoft 在敏捷工具产品方面的持续失败
开始跳出框框并尝试新事物，这是我在 .NET 世界中不断重复的内容，我过去是一名 .NET 开发人员，并且尝试过 MS 之外的新事物世界。
Being one who has TDD'd for 4 years now you are correct. MS is still not even promoting it nor do they offer tools that work well with the TDD flow.
Don't get stuck dealing with Visual Studio for any kind of automation, source control, or agile workflow period (stop using TFS please!!). That stuff even though they say is "new" is monolithic and always comes with weird issues and bloat. It is always painful.
I've used Team City and it's simply amazing, things work, it's designed for usability, and it's simply designed well and compatible with most all test tools, etc. Fine use Visual Studio for code, nothing else. Look for external and open source tools to help build a better CI. The "you can do everything right in VS" sell is not selling, and it's not working. People nowdays are used to and always combining different tools from the outside to get things done. Relying on all MS toolsets is just not the way to go IMO for .NET. MS likes to sell "hey you can just do everything right here". But you end up with nothing but pain when you go that route and drink their koolade (TFS, MS Fakes, etc.).
If you plan on doing TDD, you definitely don't want to be using all MS tools. You'll either be pushed down "their way" of doing things which is often proprietary and/or bloated when you try to TDD with their tools or be totally restrictive. For TDD you need to be able to have some flexibility and choices when you decide to layer in different test frameworks, assertion libraries, etc.
Add Octopus on top of Team City, and it's stellar...you will simply fall in love with it as developer or for anyone doing DevOps.
Stop trying to rely on Microsofts continued failure at agile tool offerings
Start looking outside the box and try new things is what I keep repeating to the .NET world, me being a .NET developer in the past and who has tried new things outside the MS world.