持续集成工具的选择

持续集成(continuous integration)作为敏捷编程的基石现在已经被绝大多数的开发团队所广泛采用。而持续集成的工具现如今也是百花齐放，各有千秋，本文主要对比了在Java 领域中比较常见的几种CI server（因为公司要求统一整个公司的CI server）。如果想了解更多的工具，可以看这里：

http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix，这个网页集中了决大多数比较流行的CI server，但是我发现很多的内容已经落后于实际产品的功能了，所以如果要对比的话，可能要实际到产品的站点去看一下，最好还是下载下来运行起来看。

在本文中，我主要针对以下几种CI Server作对比，这也是公司里各个项目组目前自行选用的（版本有点多，国内的多选用了一些open source的，而老外那边用得比较多的是商用版本，CruiseControl 和TeamCity 是我加的，因为名气非常大。）：

∙

∙

∙

∙

∙

∙

∙ CruiseControl (http://cruisecontrol.sourceforge.net/) Hudson (https://hudson.dev.java.net/) LuntBuild (http://luntbuild.javaforge.com/) TeamCity (http://www.jetbrains.com/teamcity/) AntHill Pro (http://www.anthillpro.com/) Bamboo (http://www.atlassian.com/software/bamboo/) QuickBuild (http://www.pmease.com/)

在持续集成领域，OpenSource 的CruiseControl 和LuntBuild 可谓老牌了，尤其是CruiseControl ，出自thoughtworks ，这可是Martin Fowler的老巢啊。Hudson 作为

OpenSource 里持续集成的后起之秀，现在已经赶超了这两个前辈，目前恐怕是使用最多的一个CI Server了。而后面4个是商用的CI Server，其中TeamCity 是来自jetbrains 的，jetbrains 是开发著名的IDE IntelliJ的公司。Bamboo 则是开发著名的Bug Tracking工具Jira 和Wiki Confluence的公司atlassian 公司出品的。AntHill 也属于Continuous Integration界的元老，QuickBuild 则是LuntBuild 的商业版本，我在下面重点考量的是QuickBuild ，因为LuntBuild 好像现在更新较慢了，而且QuickBuild 现在好像也有了免费的所谓的Community Edition ，功能齐全，只是配置数有所限制。在这些商业版本中，TeamCity 应该是目前市场占有率最高的。由于公司里比较倾向使用商业版本的服务器，所以我重点比较的是后4种，捎带比较了一下CruiseControl 和Hudson 。TeamCity 和QuickBuild 都有各自的免费版本，有兴趣的也可以去看看。

功能对比

CI Server在本质上就是一个定时调度器。我们配置一系列的项目，然后设定一个定时器，让它干一些活，然后通知大家。所以很多公司都使用所谓Home-made 的工具，用

cron+Ant/Maven来做持续集成，这个就已经可以达到CI 的最简单的功能了。而使用工具，就是我们除了基本的编译和通知功能以外，我们还有很多其它的需求，在我们公司里，选择CI Server主要考虑以下几点：

∙

∙

∙

∙ 便于公司的统一管理（大约有200+ Projects需要统一管理） 对于项目本身进行流程管理: Daily Build -> QA Build -> Release Build 和公司AD （Active Directory）的连接以对用户进行权限管理 Continuous Testing的支持，即对于项目的Test 要能产生出详尽的报告以及收集Test

的统计数据以作为项目的分析和考量

∙ Continuous Code Quality Analysis的支持，即能处理项目产生的Coverage 报告，Code

的static analysis报告，并且能收集这些报告的统计数据以作项目的分析和考量

∙

∙ 与SCM 工具的集成，我们公司主要有三种VCS ，ClearCase, Subversion和StarTeam 与其它工具的集成，如bug tracking工具，IDE 集成等等。

首先，我们从安装的角度来查看一下

安装CI

安装是我们开始的第一步，同时也对各个CI server都有了初步的印象。按照各自的手册，很快就装好了，我基本上选择的是Standalone 的版本，就是不配置数据库，使用自带的，也不deploy 到Tomcat 或者其它容器，这点，基本上每个CI Server都非常简单。所以也没看出什么好坏来。这里不得不提一下AntHill ，有点小家子气，要download 还得提交一个request ，然后才能下载，安装，有点烦。

配置项目

在大多数的CI Server中，绝大部分都是以Project 或者Project Group来进行管理，只有LuntBuild 和QuickBuild 比较另类，它们使用了Configuration 这个术语，意即一个配置。在配置一个典型的项目的时候，即只处理基本的一个流程：CheckOut, Build, Publish

Artifacts ，这些工具都完成的非常好，也非常简单，我使用下来，觉得TeamCity 的导航最方便，一目了然。而LuntBuild 和QuickBuild 在这方面稍显人性化不足，这两个工具都没有使用wizard 的模式。

下面，我接着实验配置50个测试项目，这也就开始考验一个CI Server的管理能力了（因为我们项目较多）。使用下来，我发现QuickBuild 对于我而言，最实用。因为它使用

Configuration 而不是Project ，并且QuickBuild 是这些CI Server中唯一支持树状结构配置的。我可以把Configuration 配置成Team A, Team B ...，然后根据实际情况，对每个Team

配置任意多个子节点，孙节点（注意，Configuration 的数目在QuickBuild 的Community Edition 里是要限制的，好像是最多16个），另外，QuickBuild 的继承关系使用起来也非常方便，如果要管理一个大型的CI Server，没有这种继承对我而言简直是一种折磨。比如说用hudson 来配置50个项目，我折腾了大半天，而用QuickBuild 来，我大约只用了一个小时，我实际配置的Configuration （含有实际step 定义的）只有3个，其它的都是继承下来，然后修改了一下参数而已，而如果我们需要批量修改一系列的configurations 的时候，则由于有继承关系，通常我们只要去修改一下父节点的设置就可以了。TeamCity 支持Project Group 的概念，类似于一种树形，但是还不完备，它只能分成两级关系，即Project Group和Project 。另外QuickBuild 所拥有的继承的功能，在别的CI 里没有看到过，有的只是象TeamCity 类似的copy project的功能。而QuickBuild 在复制的能力上远远胜过其它的CI Server ，它可以整个子树拷贝，这也就意味着，我可以配置一个公司用的template

configuration 树，然后复制出A 部门，B 部门，C 部门，等等等等。对于不同项目之间的区别则通过变量来控制，赞一个！TeamCity 在配置的方便上真得是没话说，非常直观，最酷的是象JUnit ，NUnit 这样的Tests ，连Ant 脚本都不需要写了，它直接就可以找出项目里的unit tests，这个在其它的工具里也没有看到过。至于CruiseControl ，Hudson ，Bamboo 等则是中规中矩，无甚亮点。这个环节，QuickBuild 和TeamCity 胜出。

另外配置一个项目要配的就是项目持续集成的流程管理，在我们这里，基本上是这样一个流程: Daily Build -> QA Build -> Integration Build -> Release Build。所谓Daily Build，顾名思义，就是每天一次的，由development team管理以保证项目的顺畅执行，然后经过一段时间后，development team要提交到QA 那边进行测试，通常是2个星期到一个月左右，随项目大小不等，QA 测试结束之后，如果没有重大的问题，则提交作Integration Test，以保证在模拟的实际环境中能正常工作，最后，如果没有什么问题的话则作Release Build以形成发布版本。对于公司里有一些Team 使用敏捷编程的，则需要增加所谓的Commit Test Build ，也就是developer 在作每一个checkin 的时候自动触发一个build ，以保证build 不会被这个checkin 破坏（包括不会破坏unit tests和code quality)。这也是所谓的要作

continuous testing和continuous code quality analysis，这些都是通过利用JUnit, NUnit，CheckStyle, PMD，Cobertura ，FxCop 等工具来实现的。我们在后面也会讲到，这里略过。这个环节里，个人比较喜欢AntHill Pro和QuickBuild ，这两个工具都是比较强调流程的，尤其是AntHill Pro更是将其作为卖点。AntHill Pro以工作流的模式来定义这个流程，一个项目可以定义多个的workflow ，对应于我们的case ，就是定义Daily Build的workflow ，定义QA Build的workflow ，等等，然后在作promote 的时候，通过选择不同的workflow 来达到目的。而QuickBuild 则是利用已有的configuration 的概念，定义不同的Configuration ，然后在Configuration 的setting 里定义一个或多个要promote 的configurations 。要作promote 的时候，则通过点击某个build 的promote 按钮将其promote 到指定的configuration 上去，也很方便。使用AntHill 的模式，概念上很清晰，因为我们要作的是流程管理嘛，所以workflow 会听起来比较容易接受。而QuickBuild 则是把它绑定在Configuration 上，使

用起来比较简单，但是找起来要费点事，至少对于我而言是这样。Hudson 也有类似的流程管理，但是它是自动的，而promote 在我们这里是需要人来作review 的，也就是说要人去参与，判断究竟使用哪个版本来promote ，所以在我们这里，不是很合适。

在配置项目这个环节里，个人感觉QuickBuild 比较灵活，既可以做到很简单的配置，也可以做到非常复杂的配置，而且配置起来方便性非常好。只是术语与其它的CI Server有些不同，需要熟悉一下。

Build 功能

CI Server最重要的就是Build 本身的功能，包括SCM 的连接，用户的权限管理，Build 工具的支持。首先我们来看看SCM 的支持。

SCM 支持

在这些CI Server中，AntHill Pro和Hudson 支持的种类最多，尤其是Hudson ，基本上市面上的SCM 都有所支持。对于象比较常见的Subversion ，CVS ，ClearCase ，StarTeam ，SourceSafe 等，各家都已经支持了。而在上一项目中表现较好的QuickBuild ，则属于在SCM 里支持最少的一家，它还不支持git ，Team Foundation Server，这个目前已经很流行的两种SCM ，实在有些遗憾。不过瑕不掩瑜，QuickBuild 在支持SCM 的时候，由于使用变量的支持，却是多家CI Server中最灵活的一家，它可以使用变量来配置SCM 的URL ，而其它的，则是通过定义一个基本的URL ，然后针对不同项目来定义各自的SCM repository。而QuickBuild 还有一个它自有的QuickBuild Repository，用于在不同的Configuration 中传递artifacts ，实际用起来也很方便，比如说我们在一个项目里要用到别的项目的artifacts ，那么就可以定义一下这个repository 。当然，这个功能也可以通过Maven 的repository 来完成来达到相同的目的。TeamCity 也提供了类似的机制，只不过TeamCity 的Repository 其实就是一个Ivy 的扩展。

SCM 的数据在这些CI Server中都有体现，从每一个Build 的change sets到历史统计。说明现在大家都很重视对于这些数据的收集和分析。其中TeamCity 能直接从Web 页面上直接调用IDE 来打开这些改动的文件是一大亮点，毕竟是做IntelliJ 的公司啊！

用户管理

这个基本上是每个CI Server的必备功能了，基本上都是既可以用内置的数据库管理

（Hudson 好像没用数据库），又可以连接LDAP 服务器。我只是简单测试了一下，没有深入，也就没有什么发言权了。

Build 的Dependencies 管理 (Dependent Builds)

在实际的项目中，我们常常会出现项目之间的依赖关系，比如说A 项目依赖于B 项目，B 项目依赖于C 项目。所以当我们要编译A 项目的时候，我们需要先编译C 项目，然后编译B 项目，最后再来编译A 项目，这样做的好处显而易见，就是保证我们总是使用最新开发的code 来编译一个版本，如果发生了什么问题，我们也可以很容易的知道究竟是哪个项目break 了整个build 的流程。这个功能基本上所有的这些CI Server都有提供，而能力各有千秋。TeamCity 在这里属于最弱的一个，它只能通过定义Ivy 来达到Artifacts 在不同项目中的依赖管理，而AntHill Pro，Bamboo 和QuickBuild 则都有提供两种类型的dependency 管理，即artifacts 和项目本身的依赖管理。不过TeamCity 却有另外的杀手锏，就是导入项目的功能，它支持从IntelliJ 的项目，Maven 的项目中直接导入创建这种依赖关系。

分布式Build Pool

由于公司的项目繁多，平台繁多，对于一个项目需要分布到不同的平台去编译，测试，这时候就需要建立一个Build Pool了，基本上上述各家的CI Server都已经支持了这种分布式的build pool，其实质是利用了grid computing技术来进行管理。也就是一个build server带上一群的build agent，然后把build 的任务分布到不同的agent 上去执行。在这里不得不再赞一个QuickBuild 了（呵呵，这个QuickBuild 好像给人惊喜不断啊），其实QuickBuild 的agent 与其它家的倒没什么不同，只不过就是一个computing unit，关键在于QuickBuild 里配置一个configuration ，它使用了step 的概念（这个QuickBuild 的术语倒是不少嘛），这个step 在AntHill Pro里也存在，关键在于这个step 是可以分布的，也就是说，我配置一个项目的时候，可以定义一系列并行的分布式的step ，这样对于管理和收集artifacts 非常方便，我们可以定义Test On Windows, Test On Mac, Test On Linux，然后设置一下运行这些step 的时候需要什么类型的agent ，QuickBuild 就可以把这些任务分布到这些平台的agents 上去运行了。而其它家的可能是因为收费的方式，象TeamCity ，一个build 只能在一个agent 上运行，我如果要做到同样的效果，就需要定义出三个项目，然后让这三个项目在不同的agents 上运行，最后，还要再定义一个项目，让这个项目去收集它们的artifacts ，非常麻烦。Bamboo 和AntHill 也类似于TeamCity 。而Hudson 在这块的能力很弱，个人感觉不如其它的产品强大，而且使用起来也更复杂一些。

Report 功能和统计

上述各家CI SERVER都提供了Report 的功能和统计的功能，在这个领域里，Hudson 毫无悬念的是支持报告类型最多，最全的（谁叫咱OpenSource 呢，有的是人开发）。Bamboo 属于支持报告类型最少的，不过也有很多第三方的plugin 供选择。我们所关心的几个reports 都有被各家支持，其中QuickBuild 的report 给我的感觉最华丽，不过好像是参考google analytics 来的，从界面上看和analytics 简直就是一个翻版。在使用上，QuickBuild 和TeamCity 的最方便，直接点报告中的链接就可以作一些过滤。在统计信息方面，各家对tests

的统计都非常完备，这也从一个侧面反应出test driven现在那是深入人心啊。在支持Test Driven 方面，TeamCity 是力拔头筹，得益于开发IntelliJ 的经验，TeamCity 不仅可以自动寻找出项目中的unit tests（你不用在Ant 脚本里调用junit task，或者在Maven 里调用surefire ），而且对于上次运行失败的test cases，它可以在下次build 中自动先运行，这样就可以避免一个build 运行了很久才发现上次失败的test 还没有被更正过来呢，强！

另外，要提一下的是QuickBuild 中那个Build 的Dashboard 我非常喜欢，对于一个项目当前的状况可以一目了然，有多少个tests 成功了，多少失败了，多少被fix 了，多少还没有fix ，总之，信息很丰富，不过就是配置起来有点复杂，需要我去一个报告一个报告去加step ，如果能做到TeamCity 的程度，简直就是完美了。

对于其它的CI Server则是亮点不多（其实也很强，只不过是对比而言，我觉得TeamCity 和QuickBuild 更强，更好）。

与第三方工具的集成

在与第三方工具的集成中，Hudson 遥遥领先，是所有CI Server里Plugin 最多的。可以和FaceBook ，Google Calendar，Twitter ，反正基本上你能想到的，它都有。不过对于我们而言，好多Plugin 没有太大的价值。Bamboo 在与它自己的几个产品中集成度也非常好，比如说Jira ，Wiki ，Clover 等。这几个我们公司都有用到，在这点上非常理想。 价格

不得不考虑一下价格的因素，好像记得有人说过，Price is nothing, but price is everything，尤其在这个金融危机的年代里。这点，勿庸置疑，OpenSource 永远是最好的。而在商用的这几个里QuickBuild 最便宜，它使用的是Site License，一个Site 收$2999，AntHill 最贵，我询问了一下，按我的配置，随便搞搞就要$10000了，TeamCity 的入门也很便宜，$1999带3个agents ，可是针对我们的情况，算了一下也要上$8000了（它是按agent 收费的），Bamboo 也很贵，按照它的功能而言，我觉得性价比不是很好。

总结

综合各方面因素的考虑，我们最终选择了QuickBuild ，虽然这个产品名声不是很大，不过想想它的客户中，不乏象Cisco ，HP 这样级别的公司，应该还是可以值得信赖的吧。另外就是我们使用下来觉得它还是拥有诸多亮点，对于我们的统一管理来说，可谓是方便至极。另外价格方面考虑也很不错。当然如果你的团队不是很大，那么选择QuickBuild 的Community Edition 和TeamCity 的Professional Edition都是非常值得的，这两者都是免费的，而且QuickBuild 的Community Edition功能没有任何裁剪，只是限制了一下configuration 的数目，非常适合要求比较高而项目不是很多的团队。

好了，有太多太多需要讨论的东西了，CI 这个领域现在还处于高速发展阶段，本文纯属探讨，欢迎大家拍砖。由于时间有限，对每个产品了解的不是很深入，错误在所难免，如果我有什么地方不是很准确，也欢迎告诉我。