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,我承认我认为他们是很棒的工具。 我正在考虑切换到哈德森,因为它更容易设置和维护。

https://hudson.dev.java.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集成脚本

Interesting Posts