CruiseControl 与TeamCity的持续集成？
基于实际经验，我想问你考虑哪个自动化构build环境更好。 我打算做一些.NET和一些Java开发，所以我想有一个支持这两个平台的工具。
我一直在阅读，发现了关于在stackoverflow开发中使用的CruiseControl.NET ，以及TeamCity在不同操作系统平台上基于不同编程语言支持构build代理的情况。 所以，如果你在这两方面有一些实际的经验，你更喜欢哪一个，为什么？
目前，我最感兴趣的是这个工具的易用性和pipe理，更不用说CC是开源的，而当你有很多项目运行的时候，TC是一个许可的对象（因为我需要less量的项目）。
另外，如果还有其他工具符合上述条件，并且您认为这是值得推荐的，请随时将其纳入讨论中。
自从产生Cruise Control（java版）以来，我一直在使用持续集成工具。 我已经尝试了几乎所有的人。 我从来没有比TeamCity更快乐。 build立起来非常简单，而且还提供了很大的权力。 显示编译时间，unit testing计数，合格率等的构build统计页面是非常好的。 TeamCity的项目主页也非常有价值。 对于简单的.NET项目，你可以告诉TeamCity解决scheme在哪里，什么程序集有testing，这是所有需要（除了源代码pipe理位置）。 我们还使用了一些复杂的MSBuild脚本并完成了构build链接。 我也经历了两次TeamCity升级，他们没有痛苦。
CruiseControl.NET也很好。 设置起来比较麻烦，但历史较长，所以很容易在网上find解决scheme。 由于CruiseControl.NET是开源的，您还可以select添加或更改您喜欢的任何内容。 自发布以来，我使用了CruiseControl.NET，并为cc.tray写了一些早期的代码（幸好由知道更好的人重写）。
来自ThoughtWorks的Cruise也看起来相当不错，但是我没有看到一个令人信服的理由让我切换。 如果我正在开始一个新的项目，我可能会尝试一下，但TeamCity做了简单的事情很简单，同时使复杂非常痛苦的工作做得很好。
编辑：我们刚刚升级到TeamCity 5.0几个星期前，这是另一个无痛升级。 它让我们利用了改进的代码覆盖function和GIT支持。 我们现在也正在使用已经存在一段时间的个人构build和预testing提交function。 我只是想我应该更新答案，以表明TeamCity不断改进，仍然易于使用。
我是/我是CC.NET的忠实粉丝。 我们目前在CruiseControl有5个项目，效果很好。 用手写configuration文件可能是痛苦的，但没关系。
但是 。
在科纳之后：持续集成和更好的unit testing截屏（关于TeamCity的第一个1/3），我也会检查TeamCity。 我喜欢集成的unit testing仪表板和configuration界面。
我认为在selectCC.NET或TeamCity之前， 每个人都应该看这个video。
ps：我希望网上也有一个有价值的CC.NETvideo。
我最喜欢的CI服务器是Hudson。 易于设置和维护，许多漂亮的图表可以向开发人员和非开发人员显示趋势，而且是免费的。
我目前正在使用TeamCity进行一个项目，我对它一般感到满意，但是它生成的许多graphics并不是特别有用，而且configuration比哈德森更复杂。
也就是说，TeamCityfunction强大，免费使用，并具有一个杀手级function：远程运行。 您可以直接从IDEA或Eclipse“预先提交”您的支票，在TeamCity服务器上运行一个或多个构buildconfiguration，并且只在构build成功（例如编译和所有testing通过）时才提交更改。
考虑到你可以在几个小时内使TeamCity和Hudson都运行起来，可能需要同时运行它们，以及可以想象的任何其他（如CruiseControl）。 如果您无法快速站立CI服务器进行并行比较，那么至less您有一个易于安装和/或configuration的数据点。
我已经在不同的项目上成功地使用了它们。 从设置和pipe理的angular度来看，Team City更容易处理。 你不必像使用CC一样对.config文件进行破解，安装起来很轻松。 由于你没有很多项目，我会推荐Team City over CC，直到你达到Team City的成本$$。
我已经使用CC.net和TeamCity。 我的任务是为我的组织（5个开发人员）设置和安装TeamCity。 我们的组织使用一些不常见的实践和工具（至less对于我们规模的组织），比如Perforce用于源代码pipe理和在异构操作系统上运行的多个构build代理，这导致一些初始设置令人头疼的问题。 但是，通过电子邮件提供的支持绝对是一切设置的一stream。 我在几分钟之内收到了我愚蠢的问题的答案。
界面直观，响应迅速，function丰富。 该产品感觉非常昂贵。 configuration简单，Web界面足够智能，无需重新启动代理或服务器服务，甚至刷新页面即可自行更新。
我觉得我们正在使用该产品的所有先进function，迄今为止根本没有发现任何错误。 Ndepend集成，嵌套NAnt脚本，Perforce版本标签，你的名字，我们正在做。
我强烈推荐TeamCity给任何寻找持续集成服务器或任何构build服务器的人。
不想丢弃替代工具:-)
哈德森是一个很好的开源替代品，我用CC和CC.net，我承认我认为他们是很棒的工具。 我正在考虑切换到哈德森，因为它更容易设置和维护。
确保你决定的系统扩展到你需要处理的项目数量。
我使用CruiseControl.Net，但我不会推荐它构build大量的项目…我有一个（可能有点奇怪）的安排，我有许多C ++静态库，我写入应用程序。 每个库都依赖于其他库，应用程序将引入一组库并构build。 每个lib都有一个testing套件。 每个应用程序有一个testing套件。 我为5个编译器和（windows）平台的变体构build。
我发现的第一件事情是，CC.Net的项目触发器并不完全是你所需要的，多触发器在项目触发器中运行得不好。 项目触发器的工作方式（他们使用远程连接到存储项目的服务器（即使它是由同一个CC.Net实例pipe理的项目），然后从该服务器中提取所有项目并按顺序search列表寻找你感兴趣的项目…）意味着它们不能很好地扩展。 一旦你超过了一定数量的项目，你会发现CC.Net正在为你的构build机器占用大部分CPU。
当然，它是开源的，所以你可以修复它…而且，我相信对于less数不相互依赖的项目来说，这是没问题的。
有关CC.Net问题的更多详细信息，请参阅http://www.lenholgate.com/archives/cat_ccnet.html
我最近设置了cc .net。 这是一个很好的应用程序，但需要一点耐心。 您将在记事本很多编辑configuration文件:)
它已经有一段时间了，所以它得到很好的支持，你通常可以find一个做过你想做的事情的人。 网页界面也是.net，对我们来说是一个很好的select，因为我们是一家微软商店。
我还没有使用TeamCity，但我听到了不less的build议，它看起来很漂亮。
在我以前的公司里，我有一个在Linux上设置和运行CruiseControl（Java版本）的经验。 像大多数人所说的那样，这并不是最简单的事情。 你需要了解它的框架，以提出可行的/可pipe理的configuration。 但是，一旦你通过这个驼峰，我觉得CruiseControl非常灵活，可以让你做不同的事情，以适应不同的情况。
此外，CruiseControl文档，其wiki页面也有一些有用的信息。
我没有TeamCity的直接经验。 虽然它的预testing提交function看起来足够有趣。
您可能会看到的其他CC工具是Atlassian的Bamboo 。 这是更容易设置和接口更好。 虽然，它不像CruiseControl提供的那样灵活。
您可能想要考虑的第三个选项：Thoughttworks Cruise。 它build立在CruiseControl上，但是提供了更多的function，更简单的设置等等，不是免费的（或者是开源的）。
http://studios.thoughtworks.com/cruise-continuous-integration
我在过去的一年半时间里一直在使用TeamCity，并且有着非常棒的经验。 我已经集成了许多.Net和Java项目，并使用了像MSBuild，Maven等工具。我发现Teamcity很容易设置和使用。 我已经设法得到一些SQL项目的CI运行以及这是一个噩梦，其他CI工具可能会更糟。
最近升级到Teamcity 8.0.6，这是无痛的。 Teamcity还提供了一个REST API ，对于某些场景非常有用。 如果您正在使用PowerShell进行自动化构build，那么在GitHub上可以使用许多Psake / Teamcity集成脚本
