我花了一个小时左右的时间才弄清楚哈德森最近才开店(2011年1月)。 我不知道现在每个分支的变化有多快,但更重要的是,每个分支的方向是什么,关键点是什么,让人可以做出选择。
有人有产品路线图和功能差异的链接吗?
我花了一个小时左右的时间才弄清楚哈德森最近才开店(2011年1月)。 我不知道现在每个分支的变化有多快,但更重要的是,每个分支的方向是什么,关键点是什么,让人可以做出选择。
有人有产品路线图和功能差异的链接吗?
当前回答
我有两点要补充:第一,Hudson/Jenkins是关于插件的。插件开发人员已经转向Jenkins,我们这些用户也应该如此。第二,我个人并不是甲骨文产品的忠实粉丝。事实上,我对他们避之唯恐不及。用在甲骨文解决方案的授权和硬件上的钱,你可以雇佣两倍的工程人员,还可以每周五买啤酒。
其他回答
正如chmullig所写,使用Jenkins。一些附加的要点:
In fact, arguably it was Oracle who did the forking! And technically, too, that's kinda what happened. It's interesting to see what comes out of "Hudson" though. While the "Winston summarizes the state and rosy future of the Hudson project" stuff they posted on the (new) Hudson website originally seemed like odd humour to me, perhaps this was a purposeful takeover, and the Sonatype guys actually have some big ideas up their sleeve. This analysis, suggesting a deliberate strategy by Oracle/Sonatype to oust Kohsuke and crew to create a more "enterprisy" Hudson is a very interesting read! In any case, this brief comparison a fortnight after the split—while not exactly scientific—shows Jenkins to be by far more active of the two projects.
...还有一点背景信息:
Hudson的创造者Kohsuke Kawaguchi在他的空闲时间开始了这个项目,即使他在Sun Microsystems工作,后来他们付钱让他进一步开发。正如@erickson在另一个SO问题中指出的那样,
[哈德森/詹金斯]是一位天才的产物 intellect-Kohsuke川口。因为 这是一致的,连贯的, 坚如磐石。
After the acquisition by Oracle, Kohsuke didn't hang around for long (due to lack of monitors...? ;-]), and went to work for CloudBees. What started in late 2010 as conflict over tools between the dev community and Oracle and ended in the rename/fork/split is well documented in the links chmullig provided. To me, that whole conundrum speaks, perhaps more than anything else, to Oracle's utter inability or unwillingness to sponsor an open-source project in a way that keeps all parties (Oracle, developers, users) happy. It's not in their DNA or something, as we've seen in other cases too.
综上所述,我个人认为Kohsuke和其他核心开发者在这个问题上的看法是一致的,我认为Jenkins是正确的。
使用詹金斯。
Jenkins是Hudson核心开发者最近的一个分支。要理解其中的原因,您需要了解项目的历史。它最初是开源的,并得到Sun的支持。就像Sun做的很多事情一样,它是相当开放的,但有一点善意的忽视。源代码、跟踪器、网站等都由Sun托管在他们相对封闭的java.net平台上。
后来甲骨文收购了Sun。出于各种原因,甲骨文并不羞于利用它所认为的资产。其中包括对哈德逊物流平台的一些控制,特别是对哈德逊名称的控制。许多用户和贡献者对此感到不舒服,决定离开。
所以这取决于Hudson vs Jenkins提供了什么。甲骨文的哈德森和詹金斯都有代码。Hudson拥有甲骨文和Sonatype的企业支持和品牌。Jenkins拥有大多数核心开发人员、社区和(到目前为止)更多的实际工作。
阅读我在上面链接的那篇文章,然后按时间顺序阅读其余的文章。为了达到平衡,你可以阅读Hudson/Oracle对它的看法。我很清楚谁在防守,谁对这个项目有真正的意图。
在前面…我是哈德逊的提交者和哈德逊书的作者,但我没有参与整个项目的分割。
无论如何,我的建议是:
看看这两种,看看哪种更适合你的需求。
Hudson is going to complete the migration to be a top level Eclipse projects later this year and has gotten a whole bunch of full time developers, QA and others working on the project. It is still going strong and has a lot of users and with being the default CI server at Eclipse it will continue to serve the needs of many Java developers. Looking at the roadmap and plans for the future you can see that after the Maven 3 integration accomplished with the 2.1.0 release a whole bunch of other interesting feature are ahead.
http://www.eclipse.org/hudson
另一方面,Jenkins赢得了许多Hudson的原始用户,拥有跨越多种技术的庞大用户社区,还有一大批开发人员在开发它。
在这个阶段,两个CI服务器都是很好的工具,根据您在技术方面的需求,与其中一个集成可能更好。这两个产品都是开源的,您可以从不同的公司获得这两个产品的商业支持。
无论如何…如果你还没有使用CI服务器..从现在开始,你会看到巨大的好处。
2013年1月更新:经过长时间的IP清理和进一步的改进,Hudson 3.0作为第一个Eclipse基金会批准的版本现在可用。
三个月后,我对这件事的看法是:
詹金斯继续了原来哈德逊的道路,频繁发布包括许多小更新。
Oracle似乎已经将关于Hudson未来路径的大部分工作委托给Sonatype团队,Sonatype团队已经完成了一些重要的更改,特别是在Maven方面。他们已经共同将其转移到Eclipse基金会。
如果你喜欢这个声音,我建议你:
不太频繁的发布,但是在向后兼容性方面进行了更严格的测试(更多的是“企业风格”发布周期) 一个主要专注于强大的Maven和/或Nexus集成的产品(也就是说,你对Gradle和Artifactory等不感兴趣) Sonatype或Oracle提供的专业支持,而不是Cloudbees等 你不介意拥有一个较小的插件开发者社区等等。
,那么我建议你去哈德森。
相反,如果你喜欢:
more frequent updates, even if they require a bit more frequent tweaking and are perhaps slightly riskier in terms of compatibility (more of a "latest and greatest" release cycle) a system with more active community support for e.g., other build systems / artifact repositories support offerings from the original creator et al. and/or you have no interest in professional support (e.g., you're happy as long as you can get a fix in next week's "latest and greatest") a classical OSS-style witches' brew of a development ecosystem
那我建议詹金斯(正如一位评论者所指出的,Jenkins现在也有“LTS”版本,这是在一个更“稳定”的分支上维护的)
保守的做法是现在选择Hudson,如果必备功能不可用,则迁移到Jenkins。动态的过程是现在选择Jenkins并迁移到Hudson,如果追赶更新变得太耗时而无法证明是合理的。
对于那些提到和解作为哈德森和詹金斯潜在未来的人来说,事实上詹金斯将加入SPI,在这一点上他们不太可能和解。