我想请问您，根据实践经验，您认为哪种自动化构建环境更好。 我计划进行一些 .Net 和 Java 开发，因此我希望有一个支持这两个平台的工具。
我一直在阅读并发现有关 CruiseControl.NET（用于 stackoverflow 开发）和 TeamCity 支持不同操作系统平台上并基于不同编程语言的构建代理。 那么，如果您对这两者都有一些实际经验，那么您更喜欢哪一个，为什么？
目前，我最感兴趣的是该工具的易用性和管理，更不用说 CC 是开源的，而当您有很多项目要运行时，TC 在某些时候需要获得许可（因为，我少量项目需要它）。
另外，如果有其他工具满足上述要求并且您认为值得推荐 - 请随意将其包含在讨论中。
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.
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?
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.
发布评论
评论（11）
自从产生 Cruise Control（java 版本）以来，我一直致力于持续集成工具的开发和使用。 我在某个时候尝试过几乎所有这些。 我从未像在 TeamCity 中那样快乐过。 它的设置非常简单，并且仍然提供强大的功能。 显示构建时间、单元测试计数、通过率等的构建统计页面非常好。 TeamCity 的项目主页也非常有价值。
对于简单的 .NET 项目，您只需告诉 TeamCity 解决方案在哪里以及哪些程序集进行了测试，这就是它所需要的全部（除了源代码控制位置）。 我们还使用了一些复杂的 MSBuild 脚本并完成了构建链接。
我还经历了两次 TeamCity 升级，而且很顺利。
CruiseControl.NET 也运行良好。 设置起来比较棘手，但它有较长的历史，因此很容易在网上找到解决方案。 由于 CruiseControl.NET 是开源的，您还可以选择添加或更改您喜欢的任何内容。 自 CruiseControl.NET 发布以来，我一直在使用它，并为 cc.tray 编写了一些早期代码（谢天谢地，由更了解的人重写了）。
来自 ThoughtWorks 的 Cruise 看起来也相当不错，但我认为没有令人信服的理由让我更换。 如果我要开始一个新项目，我可能会尝试一下，但 TeamCity 做得非常出色，它使简单的事情变得简单，同时使复杂的事情变得非常轻松。
编辑：
几周前，我们刚刚升级到 TeamCity 5.0，这又是一次轻松的升级。 它让我们能够利用改进的代码覆盖能力和 GIT 支持。 我们现在还使用已经存在一段时间的个人构建和预先测试的提交功能。 我只是想我应该更新答案以表明 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 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).
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.
Edit:
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.
我曾经/现在是 CC.NET 的忠实粉丝。 目前我们在 CruiseControl 中有 5 个项目，并且运行良好。 手动编写配置文件可能会很痛苦，但没关系。
但是。
在Kona：持续集成和更好的单元测试截屏视频之后（第一个 1/3关于 TeamCity）我也会检查 TeamCity。 我喜欢集成的单元测试仪表板和配置界面。
我认为每个人在选择 CC.NET 或 TeamCity 之前都应该观看此视频。
ps：我希望网上也有有价值的CC.NET视频。
I was/I'm a big fan of CC.NET. We have currently 5 projects in CruiseControl, and works great. Writing config files with hand can be painfull but it's okay.
But.
After the Kona: Continuous Integration and Better Unit Testing screencast (the first 1/3 about TeamCity) I'll check TeamCity too. I love the integrated unit test dashboard and the configuration interface.
I think everybody should watch this video before choosing CC.NET or TeamCity.
p.s.: I hope there is a valuable CC.NET video on the net too.
到目前为止，我最喜欢的 CI 服务器是 Hudson。 易于设置和维护，有很多漂亮的图表可以向开发人员和非开发人员展示趋势，而且免费。
我目前正在一个项目中使用 TeamCity，总体上我对它很满意，但它生成的许多图表并不是特别有用，而且它的配置比 Hudson 更复杂。
也就是说，TeamCity 功能强大，免费供多种用途，并且有一个杀手级功能：远程运行。 您可以直接从 IDEA 或 Eclipse“预提交”签入，在 TeamCity 服务器上运行一个或多个构建配置，并且仅在构建成功（例如，编译且所有测试通过）时才提交更改。
鉴于您可以在几个小时内启动并运行 TeamCity 和 Hudson，因此可能值得同时使用这两个工具并与您能想到的任何其他工具（例如 CruiseControl）一起运行它们。 如果您无法快速建立 CI 服务器来进行并排比较，那么至少您有一个易于安装和/或配置的数据点。
My favorite CI server by far is Hudson. Easy to set up and maintain, lots of nice graphs for showing trends to developers and non-developers, and free.
I am using TeamCity currently on a project and I'm generally pleased with it, but many of the graphs it generates aren't especially useful, and it is more complicated to configure than Hudson.
That said, TeamCity is powerful, free for many uses, and has one killer feature: Remote Run. You can "pre-commit" your check in straight from IDEA or Eclipse, run one or more build configurations on the TeamCity server, and only commit the changes if the build is successful (e.g., compiles and all tests pass).
Given that you could get both TeamCity and Hudson up and running in a few hours, it might be worth grabbing both and running them side-by-side, along with any others (such as CruiseControl) that you can think of. If you can't stand a CI server up quickly to do a side-by-side comparison, then at least you have a data point for easy of install and/or configuration.
我已经在不同的项目中成功地使用了它们。 从设置和管理的角度来看，Team City 更容易处理。 您不必像使用 CC 那样对 .config 文件进行修改，并且设置非常简单。 由于您没有很多项目，我会推荐 Team City 而不是 CC，直到您达到 Team City 花费 $$ 的地步。
I have used them both successfully on different projects. From a setup and administrative standpoint Team City is far easier to deal with. You don't have to hack around with .config files like you do with CC and setup is a breeze. Since you do not have a lot of projects I would recommend Team City over CC until you get to the point that Team City costs $$.
我使用过 CC.net 和 TeamCity。 我的任务是为我的组织（5 名开发人员）设置和安装 TeamCity。 我们的组织使用一些不常见的实践和工具（至少对于我们这种规模的组织来说），例如用于源代码控制的 Perforce 和在异构操作系统上运行的多个构建代理，这导致了一些初始设置问题。 然而，通过电子邮件提供的支持在一切设置方面绝对是一流的。 我在短短几分钟内就收到了我的愚蠢问题的答案。
该界面直观、反应灵敏，而且功能丰富。 感觉产品非常贵。 配置很简单，Web 界面足够智能，可以自行更新，无需重新启动代理或服务器服务，甚至无需刷新页面。
我觉得我们正在使用该产品的几乎所有高级功能，并且到目前为止还没有发现任何错误。 Ndepend 集成、嵌套 NAnt 脚本、Perforce 版本标签，凡是您能想到的，我们都在做。
我强烈向任何寻求持续集成服务器或任何构建服务器的人推荐 TeamCity。
I have used both CC.net and TeamCity. I am tasked with setting up and installing TeamCity for my organization (5 developers). Our organization uses some uncommon practices and tools (at least, for orgs of our size), such as Perforce for source control and multiple build agents running on heterogeneous operating systems, which caused some initial setup headaches. However, the support via email was absolutely top-notch in getting everything set up. I received answers to my dumb questions in literally minutes.
The interface is intuitive and responsive, as well as feature-packed. The product feels very expensive. Configuration is easy, and the web interface is intellegent enough to update itself without any restarting of the agent or server services, or even refreshing of the page.
I feel like we're using just about every advanced feature of the product and have found no bugs at all so far. Ndepend integration, nested NAnt scripts, Perforce version labeling, you name it, we're doing it.
I highly recommend TeamCity to anyone looking for a continuous integration server, or any build server, really.
不想向您扔替代工具:-)
Hudson 是一个很棒的开源替代品，我使用过 CC 和 CC.net，我承认我确实认为它们是很棒的工具。 我正在考虑切换到 hudson，因为它看起来更容易设置和维护。
https://hudson.dev.java.net/
Without wanting to throw alternative tools at you :-)
Hudson is a great open source alternative, I have used CC and CC.net, and I confess i do think they are fantastic tools. I am pondering switching to hudson as it apears a lot easier to setup and maintain.
https://hudson.dev.java.net/
确保您决定的系统能够适应您需要它处理的项目数量...
我使用 CruiseControl.Net，但我不会推荐它来构建大量项目...我有一个（可能有点奇怪）我有许多 C++ 静态库的安排，我将它们组成应用程序。 每个库都依赖于其他库，并且应用程序会引入一组库并进行构建。 每个库都有一个测试套件。 每个应用程序都有一个测试套件。 我为 5 个编译器和（Windows）平台的变体构建。
我发现的第一件事是 CC.Net 的项目触发器并不完全符合您的需要，并且多触发器与项目触发器不能很好地配合。 项目触发器的工作方式（它们使用远程处理连接到存储项目的服务器（即使它是由同一 CC.Net 实例管理的项目），然后从该服务器提取所有项目并按顺序搜索列表寻找您感兴趣的项目...）意味着它们无法很好地扩展。 一旦您的项目数量超过一定数量，您就会发现 CC.Net 占用了您的构建机器的大部分 CPU。
当然，它是开源的，所以你可以修复它......而且，我确信这对于少量非相互依赖的项目来说是没问题的。
有关我遇到的问题的更多详细信息以及 CC.Net 的一些补丁，请参阅此处 < a href="http://www.lenholgate.com/archives/cat_ccnet.html" rel="nofollow noreferrer">http://www.lenholgate.com/archives/cat_ccnet.html
Make sure the system that you decide on scales to the number of projects that you'll need it to handle...
I use CruiseControl.Net but I wouldn't recommend it for building lots of projects... I have a (possibly slightly strange) arrangement where I have many C++ static libraries which I compose into applications. Each library depends on other libraries and the apps pull in a set of libs and build. Each lib has a test suite. Each app has a test suite. I build for 5 compilers and variations of (windows) platforms.
The first thing I found was that CC.Net's project triggers aren't really quite what you need and the multi-trigger doesn't play well with project triggers. The way project triggers work (they use remoting to connect to the server where the project is stored (even if it's a project that is managed by the same instance of CC.Net) and then pull all projects from that server and search the list sequentially looking for the project that you're interested in...) means that they don't scale well. Once you get above a certain number of projects you'll find that CC.Net is taking most of the CPU for your build machine.
Of course, it's open source, so you can fix it... And, I'm sure it's fine for small numbers of non-interdependent projects.
For more details of the problems I had and some patches for CC.Net see here http://www.lenholgate.com/archives/cat_ccnet.html
我最近设置了 cc .net。 这是一个很棒的应用程序，但确实需要一点耐心。 您将在记事本中大量编辑配置文件:)
它已经存在了一段时间，因此它得到了很好的支持，您通常可以找到以前做过您想做的事情的人。 网络界面也是.net，这对我们来说是一个优势，因为我们是一家微软商店。
我没有使用过 TeamCity，但我听过很多关于它的推荐，而且它看起来很漂亮。
I have recently setup cc .net. It is a great application but does require a bit of patience. You will be editing config files in notepad alot :)
It has been around a while so its well supported and you can normally find someone who has done what you wantto do before. The web interface is .net as well which was a plus for us as we are a Microsoft shop.
I havent used TeamCity but I have heard quite a few recommendations of it and it looks pretty.
我在上一家公司期间有过在 Linux 上设置和运行 CruiseControl（Java 版本）的经验。 正如大多数人所建议的那样，这并不是最简单的设置。 您需要了解其框架才能提出可行/可管理的配置。 然而，一旦你度过了这个难关，我觉得 CruiseControl 足够灵活，可以让你做不同类型的事情来适应不同的场景。
此外，CruiseControl 文档及其 wiki 页面 也有一些有用的信息。
我没有直接使用 TeamCity 的经验。 尽管它的预测试提交功能看起来很有趣。
您可能会看一下的另一个 CC 工具是 Atlassian 的 Bamboo。 设置起来更容易，界面也更好。 不过，它不如 CruiseControl 提供的那么灵活。
I had an experience setting up and running CruiseControl (Java version) on Linux during my previous company. Like most people suggest, it is not the most trivial thing to setup. You need to understand its framework in order to come up with the workable/managable config. However, once you passed that hump, I feel that CruiseControl is pretty flexible enough to allow you to do different sort of things to fit different scenarios.
Besides, CruiseControl documentation, its wiki page also has some useful information as well.
I do not have a direct experience with TeamCity. Though its pre-test commit feature looks interesting enough.
The other CC tool that you might give it a look is Bamboo from Atlassian. It is a lot more easier to setup and the interface is nicer. Though, it is not as flexible as what CruiseControl offers.
您可能需要考虑的第三个选择：Thoughtworks 的 Cruise。 它基于 CruiseControl 构建，但提供了更多功能、更简单的设置等。不是免费（或开源）的。
http://studios.thoughtworks.com/cruise-continuous-integration
A third option you might want to consider: Thoughtworks' Cruise. It's built on CruiseControl, but offers a lot more features, easier setup, etc, etc. Not free (or open source).
http://studios.thoughtworks.com/cruise-continuous-integration
在过去的一年半中，我一直在使用 Teamcity，并且获得了很好的体验。 我集成了许多 .Net 和 Java 项目，并使用了 MSBuild、Maven 等工具。我发现 Teamcity 的设置和使用非常简单。 我也成功地为一些 sql 项目运行 CI，这有点像噩梦，如果使用其他 CI 工具，情况可能会更糟。
最近升级到 Teamcity 8.0.6，很轻松。 Teamcity还提供了REST API，这对于某些场景非常有用。 如果您使用 powershell 进行自动化构建，可以在 GitHub
I have been using Teamcity for the last 1 and a half years, and having a great experience. I have integrated a number of .Net and Java projects and used tools like MSBuild, Maven etc. I found Teamcity pretty simple to set up and work with. I have managed to get CI running for some sql projects as well which was a bit of nightmare which could have been worse with other CI tools.
Recently upgraded to Teamcity 8.0.6 which was painless. Also Teamcity provides a REST API which is very useful for some scenarios. If you are using powershell for automating builds a number of Psake/Teamcity integration scripts are available on GitHub