我认为标题总结了它.我只是想知道为什么一个或另一个对于Svn的Java项目的连续集成构建更好.
我同意这个答案,但想补充几点.
简而言之,Hudson(更新:Jenkins)现在可能是更好的选择.首先是因为创建和配置作业(CC词汇表中的"项目")比编辑CruiseControl的XML配置文件(我们过去只保留版本控制以便更好地跟踪它),通过Hudson的Web UI 快得多..后者并不是特别困难 - 它只是更慢,更乏味.
CruiseControl一直都很棒,但正如丹·戴尔(Dan Dyer)恰如其分的博客文章所述,为什么你还没有使用哈德森？,它首先受到影响.(嗯,就像英国一样,如果你愿意,后来进入工业革命,当其他人开始用更新的技术超越它时.)
我们大量使用了CruiseControl并逐渐切换到Hudson,最后完全使用它.而更为严重:在这个过程中,我们已经使用很多其他的事情比以前的CI服务器开始,因为建立和管理工作哈德森如此得心应手.(我们现在在Hudson有大约40多个工作:稳定和开发分支的常规构建和测试工作;与发布(构建安装程序等)相关的工作;针对代码库运行一些(实验性)指标的工作;运行的工作(缓慢) )针对特定数据库版本的UI或集成测试;等等.)
根据这一经验,我认为即使你有很多构建,包括复杂的构建,Hudson也是一个非常安全的选择,因为像CC一样,你可以用它来做任何事情.只需将您的作业配置为按您希望的顺序运行Ant或Maven目标,Unix shell脚本或Windows .bat脚本.
至于第三方的东西(Jeffrey Fredrick在这里提到) - 这是一个很好的观点,但我的印象是Hudson很快就赶上了,而且已经有很多可用的插件了.
对我来说,我想念的关于CruiseControl的两件事是:
它关于破碎版本的警告电子邮件比Hudson的信息量更多.在大多数情况下,根本原因很明显来自CC格式良好的HTML邮件本身,而对于Hudson,我通常需要关注Hudson Web UI的链接,然后点击一下以获取详细信息.
在CruiseControl的仪表板更适合,开箱即用,作为" 信息散热器 "(公共显示器上显示或投影在墙壁上,让你可以随时快速查看所有项目的状态).有了Hudson的头版,我们需要一些Greasemonkey技巧来获得所有绿色/红色的工作行.
轻微免责声明:过去一年左右,我没有密切关注CC项目.(但从快速看,它没有任何戏剧性的变化.)
注释(2011-02-03):Hudson已被重命名/分叉为Jenkins(由Hudson创建者Kohsuke Kawaguchi和其他人).看起来,控制着Hudson名称的Oracle也将保留" Hudson ",但我的个人建议是与Jenkins一起使用,无论Oracle说什么.
很长一段时间CruiseControl的提交者和从未使用过Hudson的人我很偏颇,但我的看法是:
Hudson更容易启动和运行(很大程度上来自一个漂亮的Web界面),并且有一个非常活跃的插件开发社区.
CruiseControl得到了许多第三方的支持,并且可以使用xml配置做一些巧妙的技巧,例如插件预配置和include.projects,它允许您使用项目对配置信息进行版本化.
如果你只有一些版本,我认为哈德森是明显的赢家.如果你有很多 - 而且不介意xml - 那么我认为CruiseControl的xml配置技巧成为真正的优势.
我的上一个项目,我们开始使用CruiseControl.哪个摇摇欲坠.然后我们搬到了哈德森,后者震得更厉害.关于哈德森我喜欢的事情:
上游和下游项目.因此,对数据访问代码的提交最终也会触发表示层的构建.
轻松使用现有项目作为新项目的起点 - 因此,如果您习惯于创建开发分支,那么确保这些项目处于持续集成中是一件轻而易举的事.
一个区别是哈德森是一个天才智力的产物 - Kohsuke Kawaguchi.因此,它是一致的,连贯的,坚如磐石的.不利方面可能是对进度的限制.然而,Kohsuke是非常多产的,所以我不会太担心.而且,它是可扩展的,所以如果Kohsuke没有时间(或不想要),你可以自己做.
京公网安备 11010802040832号 | 京ICP备19059560号-6 