CruiseControl [.Net] vs TeamCity进行持续集成？ [英] CruiseControl [.Net] vs TeamCity for continuous integration?

问题描述

我想询问您根据实际经验更好地考虑自动化构建环境。我计划做一些.Net和一些Java开发，所以我想有一个工具，支持这两个平台。

I would like to ask you which automated build environment you consider better, based on practical experience. I'm planning to do some .Net and some Java development, so I would like to have a tool that supports both these platforms.

我一直在读书，了解 CruiseControl.NET （用于stackoverflow开发）和 TeamCity 及其在不同操作系统平台上基于不同编程语言的构建代理的支持。所以，如果你对这两个方面都有一些实践经验，你喜欢哪一个，为什么？

I've been reading around and found out about CruiseControl.NET, used on stackoverflow development, and TeamCity with its support for build agents on different OS-platforms and based on different programming languages. So, if you have some practical experience on both of those, which one do you prefer and why?

目前，我最感兴趣的是易于使用和管理的工具，更不用说CC是开源的事实，而且当你有很多项目要运行时（因为我需要它少量的项目），TC是一个许可证。

Currently, I'm mostly interested in the ease of use and management of the tool, much less in the fact that CC is open source, and TC is a subject to licensing at some point when you have much projects to run (because, I need it for a small amount of projects).

此外，如果还有其他工具能够满足上述要求，而且您认为这是值得推荐的话，欢迎随时加入讨论。

Also, if there is some other tool that meets the above-mentioned and you believe it's worth a recommendation - feel free to include it in the discussion.

推荐答案

自从生成Cruise Control（java版本）以来，我一直使用和使用Continuous Integration工具。我已经尝试了几乎所有的他们在某一点。我从来没有比我和TeamCity更快乐。它设置非常简单，仍然提供大量的电源。显示构建时间，单元测试计数，通过率等的构建统计页面非常好。 TeamCity的项目主页也非常有价值。
对于简单的.NET项目，你可以告诉TeamCity解决方案在哪里，什么程序集有测试，这是所有需要（除了源控制位置）。我们还使用了一些复杂的MSBuild脚本和完成构建链接。
我也经历了两次TeamCity升级，他们很痛苦。

I have worked on and with Continuous Integration tools since the one that spawned Cruise Control (java version). I've tried almost all of them at some point. I've never been happier than I am with TeamCity. It is very simple to set up and still provides a great deal of power. The build statistics page that shows build times, unit test count, pass rate etc. is very nice. TeamCity's project home page is also very valuable. For simple .NET projects you can just tell TeamCity where the solution is and what assemblies have tests and that is all it needs (other than source control location). We have also used some complicated MSBuild scripts with it and done build chaining. I have also gone through two TeamCity upgrades and they were painless.

CruiseControl.NET也很好用。它是很复杂的设置，但它有一个更长的历史，所以它很容易找到解决方案在网络上。由于CruiseControl.NET是开源的，你还可以选择添加或更改任何你喜欢的。我使用CruiseControl.NET从它的发布，并写了一些早期的代码cc.tray（感谢重新编写的人谁知道更好）。

CruiseControl.NET also works well. It is trickier to set up but it has a longer history so it is easy to find solutions on the web. Since CruiseControl.NET is open source you also have the option of adding or changing whatever you like. I had used CruiseControl.NET since its release and wrote some of the early code for cc.tray (thankfully re-written by someone who knew better).

来自ThoughtWorks的Cruise也看起来不错，但我没有看到令人信服的原因让我切换。如果我开始一个新项目，我可以试一试，但TeamCity做了一个伟大的工作，使简单的事情简单，而使复杂相当痛苦。

Cruise, from ThoughtWorks, also looks quite good but I don't see a compelling reason for me to switch. If I were starting a new project I might give it a try, but TeamCity has done a great job of making the simple things simple while making the complex quite painless.

编辑：
我们刚刚升级到TeamCity 5.0几个星期前，这是另一个无痛的升级。它让我们利用改进的代码覆盖能力和GIT支持。我们现在也使用了一段时间的个人构建和预先测试的提交功能。我只是想我应该更新答案，表明TeamCity不断改进，仍然很容易使用。

We just upgraded to TeamCity 5.0 a few weeks ago and it was another painless upgrade. It let us take advantage of the improved code coverage capabilities and GIT support. We are also now using the personal build and pre-tested commit features that have been in for a while. I just thought I should update the answer to indicate that TeamCity keeps improving and is still easy to use.

这篇关于CruiseControl [.Net] vs TeamCity进行持续集成？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！