Hudson和CruiseControl for Java项目的区别是什么?

我同意 this answer ,但想补充几点。

简言之 哈德逊 Jenkins )现在可能是更好的选择。首先也是最重要的,因为创建和配置作业(CC词汇表中的“项目”)只是 快多了 通过Hudson的web UI,与编辑CruiseControl的XML配置文件(我们使用它来保持版本控制,只是为了更好地跟踪它)相比。后者并不是特别困难——它只是更慢、更乏味。

CruiseControl非常棒,但正如丹·戴尔(Dan Dyer)恰当命名的博客文章所指出的, Why are you still not using Hudson?

我们大量使用CruiseControl,并逐渐切换到Hudson,最后只使用它。和 甚至更多 严重:在此过程中,我们开始将CI服务器用于许多其他事情,因为设置和管理Hudson作业非常方便。(我们现在在Hudson有大约40多个作业:稳定和开发分支的常见构建和测试作业;与发布相关的作业(构建安装程序等);针对代码库运行一些(实验性)度量的作业;针对特定数据库版本运行(缓慢)UI或集成测试的作业;等等。)

根据这段经历,我认为即使你有很多构建,包括复杂的构建,Hudson也是一个非常安全的选择,因为像CC一样,你也可以使用它来完成 任何东西

至于第三方的东西( mentioned here by Jeffrey Fredrick )-这是一个很好的观点,但我的印象是哈德逊正在迅速赶上,而且已经有大量的 plugins available 为了它。

对我来说,我怀念CruiseControl的两件事是:

1. 与哈德逊公司相比,该公司发出的关于破损建筑的警告电子邮件信息量更大。在大多数情况下,根本原因显然来自CC格式良好的HTML邮件本身,而对于Hudson,我通常需要按照Hudson web UI的链接,点击一点以获取详细信息。
2. 这个 CruiseControl dashboard 更适合,开箱即用,作为“ information radiator

次要免责声明:我在过去一年左右没有密切关注CC项目。(但是从一个 quick look ,它没有发生任何戏剧性的变化。)

(2011-02-03):哈德逊已经 renamed/forked 像 詹金斯 (作者:哈德逊创造者) Kohsuke Kawaguchi 和其他人)。看起来,控制哈德逊名字的Oracle将保留“ Hudson “也有,但我个人的建议是 詹金斯

作为一名长期的CruiseControl提交人 和

Hudson更容易启动和运行(很大程度上是通过一个漂亮的web界面),并且有一个非常活跃的插件开发社区。

CruiseControl得到了许多公司的支持 3rd party stuff

• 上游和下游项目。因此,对数据访问代码的提交最终也会触发表示层的构建。

• 轻松地使用现有项目作为新项目的起点-因此,如果您有创建开发分支的习惯,那么确保这些分支处于持续集成之下是一件轻而易举的事。

一个不同之处是哈德逊是一个天才知识分子川口康介的产物。因此,它是一致的、连贯的、坚如磐石的。不利的一面可能是进展速度受到一些限制。然而,Kohsuke是难以置信的多产,所以我不会太担心这一点。而且,它是可扩展的,所以如果Kohsuke没有时间做(或不想做)某些事情,您可以自己做。

我看了巡航控制和哈德逊,但选择哈德逊,因为它更容易设置和配置。Hudson现在似乎得到了广泛的应用,它有常规的发行版,并通过插件进行了大量的扩展。我强烈推荐它。

关于CruiseControl,唯一可以这样说的方法是计算内置的XML文件编辑器。

尽管如此,在使用了两者之后,我仍然更喜欢任何一种,而不是没有自动构建。

最近,我利用Subversion为Jenkins建立了Borland BDS 2006项目,我对此非常满意。我还没用过CruiseControl,所以我无法比较。阅读我的博客文章了解更多信息。

Continuous integration of Delphi project with Jenkins