根据实际经验，我想问一下您认为哪种自动化构建环境更好。我打算做一些.Net 和一些Java 开发，所以我想要一个支持这两个平台的工具。
我一直在阅读并发现了用于 stackoverflow 开发的CruiseControl.NET和TeamCity，它支持在不同的操作系统平台上基于不同的编程语言构建代理。那么，如果您在这两个方面都有一些实践经验，您更喜欢哪一个，为什么？
目前，我最感兴趣的是该工具的易用性和管理性，更不用说 CC 是开源的，而且当你有很多项目要运行时，TC 在某些时候会受到许可（因为，我少量项目需要它）。
此外，如果有其他工具可以满足上述要求，并且您认为值得推荐 - 请随时将其包含在讨论中。
自从产生 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：持续集成和更好的单元测试截屏之后（关于 TeamCity 的前 1/3），我也会检查 TeamCity。我喜欢集成的单元测试仪表板和配置界面。
我认为每个人都应该在选择 CC.NET 或 TeamCity 之前观看此视频。
ps：希望网上也有有价值的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，这对我们来说是一个加分项，因为我们是 Microsoft 商店。
我没有使用过 TeamCity，但我听说过很多关于它的建议，而且它看起来很漂亮。
在我以前的公司期间，我有在 Linux 上设置和运行 CruiseControl（Java 版本）的经验。就像大多数人建议的那样，设置它并不是最简单的事情。您需要了解它的框架才能提出可行/可管理的配置。然而，一旦你通过了那个坎，我觉得 CruiseControl 非常灵活，可以让你做不同的事情来适应不同的场景。
此外，CruiseControl 文档，它的wiki 页面也有一些有用的信息。
我没有使用 TeamCity 的直接经验。虽然它的预测试提交功能看起来很有趣。
您可能会看到的另一个 CC 工具是Atlassian 的Bamboo。设置起来更容易，界面也更好。不过，它不像 CruiseControl 提供的那样灵活。
您可能要考虑的第三种选择：Thoughtworks 的 Cruise。它建立在 CruiseControl 之上，但提供了更多功能、更简单的设置等。不是免费的（或开源的）。
http://studios.thoughtworks.com/cruise-continuous-integration
在过去的 1 年半中，我一直在使用 Teamcity，并获得了很棒的体验。我已经集成了许多 .Net 和 Java 项目，并使用了 MSBuild、Maven 等工具。我发现 Teamcity 的设置和使用非常简单。我还设法让 CI 运行在一些 sql 项目中，这有点像噩梦，如果使用其他 CI 工具可能会更糟。
最近升级到无痛的 Teamcity 8.0.6。Teamcity 还提供了一个REST API，这对于某些场景非常有用。如果您使用 powershell 进行自动化构建，GitHub 上提供了许多 Psake/Teamcity 集成脚本