continuous-integration - CruiseControl [.Net] 与 TeamCity 进行持续集成？

Question

我想问一下，根据实际经验，您认为哪种自动化构建环境更好。我计划进行一些 .Net 和 Java 开发，因此我希望有一个支持这两个平台的工具。

我一直在阅读并发现CruiseControl.NET ，用于 stackoverflow 开发，以及 TeamCity支持不同操作系统平台上基于不同编程语言的构建代理。那么，如果您对这两者都有一些实际经验，那么您更喜欢哪一个，为什么？

目前，我最感兴趣的是该工具的易用性和管理，更不用说 CC 是开源的，而当您有很多项目要运行时，TC 在某些时候需要获得许可(因为，我需要它来完成少量项目)。

此外，如果有其他工具满足上述要求并且您认为值得推荐 - 请随时将其纳入讨论中。

Answer 1

自从产生 Cruise Control(java 版本)以来，我就一直致力于持续集成工具的开发和使用。我在某个时候尝试过几乎所有这些。我从未像在 TeamCity 中那样快乐过。它的设置非常简单，并且仍然提供强大的功能。显示构建时间、单元测试计数、通过率等的构建统计页面非常好。 TeamCity 的项目主页也非常有值(value)。对于简单的 .NET 项目，您只需告诉 TeamCity 解决方案在哪里以及哪些程序集进行了测试，这就是它所需要的全部(除了源代码控制位置)。我们还使用了一些复杂的 MSBuild 脚本并完成了构建链接。我还经历了两次 TeamCity 升级，而且很顺利。

CruiseControl.NET 也运行良好。设置起来比较棘手，但它有较长的历史，因此很容易在网上找到解决方案。由于 CruiseControl.NET 是开源的，您还可以选择添加或更改您喜欢的任何内容。自 CruiseControl.NET 发布以来，我一直在使用它，并为 cc.tray 编写了一些早期代码(值得庆幸的是，由更了解的人重写了)。

来自 ThoughtWorks 的 Cruise 看起来也相当不错，但我没有看到有令人信服的理由让我更换。如果我要开始一个新项目，我可能会尝试一下，但 TeamCity 做得很好，让简单的事情变得简单，同时让复杂的事情变得轻松。

编辑:几周前，我们刚刚升级到 TeamCity 5.0，这又是一次轻松的升级。它让我们能够利用改进的代码覆盖能力和 GIT 支持。我们现在还使用已经存在一段时间的个人构建和预先测试的提交功能。我只是想我应该更新答案以表明 TeamCity 不断改进并且仍然易于使用。