根据实际经验，我想问一下您认为哪种自动化构建环境更好。我打算做一些 .Net 和一些 Java 开发，所以我想要一个支持这两个平台的工具。
我一直在阅读并发现CruiseControl.NET，用于stackoverflow 开发，以及TeamCity，它支持不同操作系统平台上的构建代理并基于不同的编程语言。那么，如果您在这两个方面都有一些实践经验，您更喜欢哪一个，为什么？
目前，我最感兴趣的是该工具的易用性和管理性，更不用说 CC 是开源的，而且当您有很多项目要运行时，TC 有时会受到许可（因为，我在少量项目中需要它）。
此外，如果有其他工具满足上述要求，并且您认为值得推荐 - 请随时将其纳入讨论。
【问题讨论】：
标签： continuous-integration build-automation cruisecontrol.net teamcity cruisecontrol
自从产生 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 不断改进并且仍然易于使用。
【讨论】：
我曾经/我是 CC.NET 的忠实粉丝。我们目前在 CruiseControl 中有 5 个项目，并且效果很好。手动编写配置文件可能会很痛苦，但没关系。
但是。
在Kona: Continuous Integration and Better Unit Testing 截屏视频（关于 TeamCity 的前 1/3）之后，我也会查看 TeamCity。我喜欢集成的单元测试仪表板和配置界面。
我认为每个人都应该在选择 CC.NET 或 TeamCity 之前观看此视频。
p.s.：希望网上也有有价值的CC.NET视频。
【讨论】：
到目前为止，我最喜欢的 CI 服务器是 Hudson。易于设置和维护，有许多漂亮的图表可以向开发人员和非开发人员展示趋势，而且是免费的。
我目前在一个项目中使用 TeamCity，我通常对它感到满意，但它生成的许多图表并不是特别有用，而且它的配置比 Hudson 更复杂。
也就是说，TeamCity 功能强大，可免费用于多种用途，并且有一个杀手级功能：远程运行。您可以直接从 IDEA 或 Eclipse 中“预先提交”您的签入，在 TeamCity 服务器上运行一个或多个构建配置，并且仅在构建成功时提交更改（例如，编译并且所有测试都通过）。
鉴于您可以在几个小时内启动并运行 TeamCity 和 Hudson，因此可能值得同时将它们与您能想到的任何其他（例如 CruiseControl）一起运行。如果您不能让 CI 服务器快速进行并排比较，那么至少您有一个易于安装和/或配置的数据点。
【讨论】：
我在不同的项目中都成功地使用了它们。从设置和管理的角度来看，Team City 更容易处理。您不必像使用 CC 一样修改 .config 文件，而且设置起来轻而易举。由于您没有很多项目，我会推荐 Team City 而不是 CC，直到您发现 Team City 的成本为 $$。
【讨论】：
我使用过 CC.net 和 TeamCity。我的任务是为我的组织（5 个开发人员）设置和安装 TeamCity。我们的组织使用了一些不常见的实践和工具（至少对于我们这种规模的组织而言），例如用于源代码控制的 Perforce 和在异构操作系统上运行的多个构建代理，这导致了一些初始设置问题。但是，通过电子邮件提供的支持在一切设置方面绝对是一流的。我在几分钟内就收到了我愚蠢问题的答案。
界面直观且响应迅速，并且功能丰富。该产品感觉非常昂贵。配置简单，Web 界面智能到足以更新自身，无需重新启动代理或服务器服务，甚至无需刷新页面。
我觉得我们几乎使用了该产品的所有高级功能，并且到目前为止还没有发现任何错误。 Ndepend 集成、嵌套的 NAnt 脚本、Perforce 版本标签，只要你说出来，我们就在做。
我向任何正在寻找持续集成服务器或任何构建服务器的人强烈推荐 TeamCity。
【讨论】：
不想向你扔替代工具:-)
Hudson 是一个很棒的开源替代品，我使用过 CC 和 CC.net，我承认我确实认为它们是很棒的工具。我正在考虑改用 hudson，因为它看起来更容易设置和维护。
【讨论】：
确保您决定使用的系统可以扩展到您需要它处理的项目数量...
我使用 CruiseControl.Net，但我不建议将它用于构建大量项目......我有一个（可能有点奇怪）的安排，我有许多 C++ 静态库，我将它们组合成应用程序。每个库都依赖于其他库，并且应用程序会引入一组库并进行构建。每个库都有一个测试套件。每个应用程序都有一个测试套件。我为 5 个编译器和（Windows）平台的变体构建。
我发现的第一件事是 CC.Net 的项目触发器并不是你真正需要的，而且多触发器不能很好地与项目触发器配合使用。项目触发器的工作方式（他们使用远程连接到存储项目的服务器（即使它是由同一 CC.Net 实例管理的项目），然后从该服务器中拉出所有项目并按顺序搜索列表正在寻找您感兴趣的项目...）意味着它们不能很好地扩展。一旦你完成了一定数量的项目，你会发现 CC.Net 正在为你的构建机器占用大部分 CPU。
当然，它是开源的，所以你可以修复它......而且，我相信它对于少量非相互依赖的项目来说没问题。
有关我遇到的问题和 CC.Net 的一些补丁的更多详细信息，请参阅此处http://www.lenholgate.com/archives/cat_ccnet.html
【讨论】：
我最近设置了 cc .net。这是一个很棒的应用程序，但确实需要一点耐心。您将在记事本中编辑配置文件很多:)
它已经有一段时间了，所以它得到了很好的支持，你通常可以找到以前做过你想做的事情的人。 Web 界面也是 .net，这对我们来说是一个加分项，因为我们是一家微软商店。
我没有使用过 TeamCity，但我听过很多关于它的推荐，而且它看起来很漂亮。
【讨论】：
在我以前的公司期间，我有过在 Linux 上设置和运行 CruiseControl（Java 版本）的经验。就像大多数人建议的那样，设置它并不是最简单的事情。您需要了解它的框架才能提出可行/可管理的配置。然而，一旦你通过了那个坎，我觉得 CruiseControl 非常灵活，可以让你做不同的事情来适应不同的场景。
此外，CruiseControl 文档，其wiki page 也有一些有用的信息。
我没有使用 TeamCity 的直接经验。虽然它的预测试提交功能看起来很有趣。
您可能会看到的另一个 CC 工具是来自 Atlassian 的 Bamboo。设置起来更容易，界面也更好。不过，它不如 CruiseControl 提供的灵活。
【讨论】：
您可能要考虑的第三个选项：Thoughtworks 的 Cruise。它基于 CruiseControl 构建，但提供了更多功能、更简单的设置等。不是免费的（或开源的）。
http://studios.thoughtworks.com/cruise-continuous-integration
【讨论】：