我觉得标题就是总结。我只是想知道为什么其中一个对于从 Svn 持续集成 Java 项目构建更好。
一个不同之处在于,哈德逊是一个天才智力的产物。因此,它是一致的,连贯的,坚如磐石。缺点可能是进展速度受到一些限制。然而,Kohsuke 是难以置信的多产,所以我不会太担心。而且,它是可扩展的,所以如果 Kohsuke 没有时间做(或者不想做)的事情,你也许可以自己做。
我的上一个项目,我们从 CruiseControl 开始。太棒了。然后我们搬到了哈德逊,那里更加摇滚。我喜欢 Hudson 的地方:
上游或下游。因此,对数据访问代码的提交最终也将触发表示层的构建。
轻松地使用一个现有的项目作为一个新项目的起点——因此,如果您有创建开发分支的习惯,那么确保这些分支处于持续集成之下是很容易的。
在我看来,Hudson 是一个更加人性化的选择。它可以完全通过 web 界面进行设置和维护(当然,除了最初的 webapp 安装)。
关于 CruiseControl,唯一可以说明这一点的方法是将内置的 XML 文件编辑器计算在内。
尽管如此,在同时使用了这两种方法之后,我仍然更喜欢任何一种方法,而不是没有自动构建的方法。
我看了巡航控制和哈德逊,但选择哈德逊,因为它更容易设置和配置。Hudson 最近似乎被广泛使用,通过定期发布和大量的插件扩展。我强烈推荐。
作为一个长期的 CruiseControl 提交者 还有的人谁从来没有使用过 Hudson 我是非常有偏见的,但我的看法是:
Hudson 更容易启动和运行(在很大程度上来自一个漂亮的 web 界面) ,并且有一个非常活跃的插件开发社区。
CruiseControl 得到了很多 第三方的东西的支持,并且有一些好处,可以对 xml 配置进行一些简洁的处理,比如插件预配置和 include. project,它们允许您使用项目对配置信息进行版本控制。
如果你只打算有一些建设,我认为哈德森是明确的赢家。如果您将拥有很多——并且不介意 xml ——那么我认为 CruiseControl 的 xml 配置技巧将成为一个真正的强项。
我同意 这个答案,但是想补充几点。
简而言之,哈德森(更新: 詹金斯)现在可能是更好的选择。首先,因为创建和配置作业(CC 词汇中的“项目”)只是通过 Hudson 的 web UI 进行的 快多了,而编辑 CruiseControl 的 XML 配置文件(我们过去常常保存在版本控制中,只是为了更好地跟踪它)。后者并不特别困难——它只是更慢、更乏味。
CruiseControl 一直很棒,但正如丹•戴尔(Dan Dyer)在其名为 为什么你仍然不使用 Hudson的博客文章中所指出的那样,它在成为第一名方面遇到了困难。(嗯,像英国,如果你愿意,后来进入工业革命,当其他人开始用新技术超越它。)
我们大量使用 CruiseControl,并逐渐转向 Hudson,最终完全使用它。而且 甚至更多非常重要: 在这个过程中,我们已经开始使用 CI 服务器来完成比以前更多的事情,因为设置和管理 Hudson 作业非常方便。(我们现在在 Hudson 有大约40多个作业: 为稳定和开发分支的常规构建和测试作业; 与发布相关的作业(构建安装程序等) ; 针对代码库运行一些(实验性)指标的作业; 针对特定数据库版本运行(缓慢的) UI 或集成测试的作业; 等等)
根据这个经验,我认为即使您有大量的构建,包括复杂的构建,Hudson 也是一个相当安全的选择,因为像 CC 一样,您基本上可以使用它来执行 什么都行。只需将作业配置为运行 Ant 或 Maven 目标、 Unix shell 脚本或 Windows 即可。Bat 脚本,按照您希望的顺序。
至于第三方的东西(杰弗里 · 弗雷德里克提到过)-这是一个很好的观点,但我的印象是,哈德森正在迅速赶上,并已经有一个非常大的数量的 插件可用为它。
对我来说,CruiseControl 让我想念的两件事是:
小小的免责声明: 在过去一年左右的时间里,我并没有密切关注 CC 项目。(但从 快看来看,它没有发生任何戏剧性的变化。)
注意 (2011-02-03) : Hudson 已经被 改名[分叉]当作 詹金斯(由 Hudson 的创作者 川口康介和其他人)。看起来,控制着哈德逊(Hudson)品牌的甲骨文(Oracle)似乎也会保留“ 哈德森”,但我个人建议,不管甲骨文怎么说,还是选择 詹金斯。
我试过巡航控制... 很好... 但文件都碎了。仪表盘很混乱。小部件的创建也令人困惑。从没试过 Hudson。会在周末试试。
我最近设置詹金斯为建立 Borland BDS 2006项目使用 Subversion,我很高兴与它。我从来没有使用过 CruiseControl,所以我不能比较。更多信息请阅读我的博客文章。
Delphi 项目与 Jenkins 的持续整合