持续集成方案，Hudson还是Jenkins?

IT业非常喜欢好的”圣战”。最近的一次发生Hudson和Jenkins之间。最近Oracle宣布有将Hudson捐献给Eclipse基金会，引发了一些关于这是否可以避免的Hudson和Jenkins之间竞争的有趣问题。

随着状况的快速改变，那么开发团队或公司如何做出正确的选择呢？在跟踪了这两个服务器后，我可以告诉大家，其实并没有什么关系。

从打斗中后退一步

经常，我与客户交流时，都都发现持续集成不是他们开发/集成工具箱中的一个工具。这些项目经常会遭受长久不能工作的自动化测试集，在不同环境间部署时非常困难。简单来说他们缺乏可见性和可重复性。这经常导致产品的bug和非常昂贵的产品发布。

持续集成过程通过脚本自动化强制可重复性，通过测试执行和趋势报告实现可见性。这是实现持续集成的核心价值。每次我为客户设置持续集成，他们都会奇怪之前没有持续集成他们是如何做的。

当为持续集成设置一个项目你将看到在自动化方式（Ant、Maven、Gradle等）上有非常多的不同，具体的配置方式根据持续集成的服务器而不同。

那么哪个更好呢？

每个持续集成服务器的核心都有两个基本特性：触发自动化和报告结果。所有的测试和公共执行都由你在定义和构建你的自动化脚本时所做的决策来控制。你的决策将被持续集成服务器所使用，基于如下的条件：

1. 是否足够快，是否容易设置/维护，而不需要很多的底层操作？
2. 它是否支持我的版本控制系统？
3. 它能执行或消耗我的构建脚本的输出吗？
4. 它提供我选择测试框架的报告吗？

Jenkins和Hudson都有自己的长处和短处，但是好消息是他们都具备持续集成服务器所具备的重要特性。

他们都非常快和容易设置，在两个间切换是非常简单的。因此选一个你喜欢的，然后使用它，如果它不能完全满足你的需求，可以在一天内切换到另一个！真的非常容易。

底线…为什么没关系

任何好的持续集成解决方案都提供了基本的触发和报表。持续集成的真实价值不是执行它的服务器，而是它所产生的数据。能够查看代码的趋势、单元和集成测试然后下载最新的构建产品才是所需要的，这两个方案都提供了这些支持。服务器自身是任何持续集成解决方案最不重要的特性。

失去在你项目中提高可见性和可重复性的机会的代价比在选择持续集成环境时所做的”错误”决定的代价更大。对于像Hudson和Jenkins这两个强大的产品来说，很难选错。你只需要去根据自己的喜好选择！

引用：

Martin Fowler on Continuous Integration:http://martinfowler.com/articles/continuousIntegration.html

Hudson Continuous Integration Server: http://www.hudson-ci.org/

Jenkins Continuous Integration Server: http://www.jenkins-ci.org/

转自： http://javasight.net/2011/05/hudson-or-jenkins/