持续集成工具的选择-装载(2)

　　另外配置一个项目要配的就是项目持续集成的流程管理，在我们这里，基本上是这样一个流程: 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在这块的能力很弱，个人感觉不如其它的产品强大，而且使用起来也更复杂一些。

原文转自：http://www.ltesting.net