持续集成学习总结(二)

安装CI

安装是我们开始的第一步,同时也对各个CI server都有了初步的印象。按照各自的手册,很快就装好了,我基本上选择的是Standalone的版本,就是不配置数据库,使用自带的,也不deployTomcat或者其它容器,这点,基本上每个CI Server都非常简单。

AntHilldownload还得提交一个request,然后才能下载,安装。

配置项目

在大多数的CI Server中,绝大部分都是以Project或者Project Group来进行管理,只有LuntBuildQuickBuild比较另类,它们使用了Configuration这个术语,意即一个配置。在配置一个典型的项目的时候,即只处理基本的一个流程:CheckOut, Build, Publish Artifacts,这些工具都完成的非常好,也非常简单。

TeamCity的导航最方便,一目了然。

LuntBuildQuickBuild在这方面稍显人性化不足,这两个工具都没有使用wizard的模式。

下面,我接着实验配置50个测试项目,这也就开始考验一个CI Server的管理能力了。

QuickBuild最实用,因为它使用Configuration而不是Project,并且它是这些CI Server中唯一支持树状结构配置的。我可以把Configuration配置成Team A, Team B ...,然后根据实际情况,对每个Team配置任意多个子节点,孙节点(注意,Configuration的数目在QuickBuildCommunity Edition里是要限制的,好像是最多16个)。QuickBuild的继承关系使用起来也非常方便,如果要管理一个大型的CI Server,没有这种继承简直是一种折磨。比如说用hudson来配置50个项目,要需要大半天,而用QuickBuild来,只需大约一个小时,我实际配置的Configuration(含有实际step定义的)只有3个,其它的都是继承下来,然后修改了一下参数而已,而如果我们需要批量修改一系列的configurations的时候,则由于有继承关系,通常我们只要去修改一下父节点的设置就可以了。

TeamCity支持Project Group的概念,类似于一种树形,但是还不完备,它只能分成两级关系,即Project GroupProject。另外QuickBuild所拥有的继承的功能,在别的CI里没有看到过,有的只是象TeamCity类似的copy project的功能。而QuickBuild在复制的能力上远远胜过其它的CI Server,它可以整个子树拷贝,这也就意味着,我可以配置一个公司用的template configuration树,然后复制出A部门,B部门,C部门,等等等等。对于不同项目之间的区别则通过变量来控制,赞一个!TeamCity在配置的方便上真得是没话说,非常直观,最酷的是象JUnitNUnit这样的Tests,连Ant脚本都不需要写了,它直接就可以找出项目里的unit tests,这个在其它的工具里也没有看到过。

至于CruiseControlHudsonBamboo等则是中规中矩,无甚亮点。

另外配置一个项目要配的就是项目持续集成的流程管理,在我们这里,基本上是这样一个流程: 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在作每一个check in的时候自动触发一个build,以保证build不会被这个check in破坏(包括不会破坏unit testscode quality)。这也是所谓的要作continuous testingcontinuous code quality analysis,这些都是通过利用JUnit, NUnitCheckStyle, PMDCoberturaFxCop等工具来实现的。

这个环节里,个人比较喜欢AntHill ProQuickBuild,这两个工具都是比较强调流程的,尤其是AntHill Pro更是将其作为卖点。AntHill Pro以工作流的模式来定义这个流程,一个项目可以定义多个的workflow,对应于我们的case,就是定义Daily Buildworkflow,定义QA Buildworkflow,等等,然后在作promote的时候,通过选择不同的workflow来达到目的。

QuickBuild则是利用已有的configuration的概念,定义不同的Configuration,然后在Configurationsetting里定义一个或多个要promoteconfigurations。要作promote的时候,则通过点击某个buildpromote按钮将其promote到指定的configuration上去,也很方便。使用AntHill的模式,概念上很清晰,因为我们要作的是流程管理嘛,所以workflow会听起来比较容易接受。而QuickBuild则是把它绑定在Configuration上,使用起来比较简单,但是找起来要费点事,至少对于我而言是这样。Hudson也有类似的流程管理,但是它是自动的,而promote在我们这里是需要人来作review的,也就是说要人去参与,判断究竟使用哪个版本来promote,所以在我们这里,不是很合适。

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

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

 

SCM支持

在这些CI Server中,AntHill ProHudson支持的种类最多,尤其是Hudson,基本上市面上的SCM都有所支持。对于象比较常见的SubversionCVSClearCaseStarTeamSourceSafe等,各家都已经支持了。

QuickBuild,则属于在SCM里支持最少的一家,它还不支持gitTeam Foundation Server,这个目前已经很流行的两种SCMQuickBuild在支持SCM的时候,由于使用变量的支持,却是多家CI Server中最灵活的一家,它可以使用变量来配置SCMURL,而其它的,则是通过定义一个基本的URL,然后针对不同项目来定义各自的SCM repository。而QuickBuild还有一个它自有的QuickBuild  Repository,用于在不同的Configuration中传递artifacts,实际用起来也很方便,比如说我们在一个项目里要用到别的项目的artifacts,那么就可以定义一下这个repository。当然,这个功能也可以通过Mavenrepository来完成来达到相同的目的。TeamCity也提供了类似的机制,只不过TeamCityRepository其实就是一个Ivy的扩展。

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

 

用户管理

这个基本上是每个CI Server的必备功能了,基本上都是既可以用内置的数据库管理(Hudson好像没用数据库),又可以连接LDAP服务器。

 

BuildDependencies管理 (Dependent Builds)

在实际的项目中,我们常常会出现项目之间的依赖关系,比如说A项目依赖于B项目,B项目依赖于C项目。所以当我们要编译A项目的时候,我们需要先编译C项目,然后编译B项目,最后再来编译A项目,这样做的好处显而易见,就是保证我们总是使用最新开发的code来编译一个版本,如果发生了什么问题,我们也可以很容易的知道究竟是哪个项目break了整个build的流程。这个功能基本上所有的这些CI Server都有提供,而能力各有千秋。

TeamCity在这里属于最弱的一个,它只能通过定义Ivy来达到Artifacts在不同项目中的依赖管理。

AntHill ProBambooQuickBuild则都有提供两种类型的dependency管理,即artifacts和项目本身的依赖管理。

不过TeamCity却有另外的杀手锏,就是导入项目的功能,它支持从IntelliJ的项目,Maven的项目中直接导入创建这种依赖关系。

 

分布式Build Pool

由于公司的项目繁多,平台繁多,对于一个项目需要分布到不同的平台去编译,测试,这时候就需要建立一个Build Pool了,基本上述各家的CI Server都已经支持了这种分布式的build pool,其实质是利用了grid computing技术来进行管理。也就是一个build server带上一群的build agent,然后把build的任务分布到不同的agent上去执行。

在这里不得不再赞一个QuickBuild了,其实QuickBuildagent与其它家的倒没什么不同,只不过就是一个computing unit,关键在于QuickBuild里配置一个configuration,它使用了step的概念,这个stepAntHill Pro里也存在,关键在于这个step是可以分布的,也就是说,我配置一个项目的时候,可以定义一系列并行的分布式的step,这样对于管理和收集artifacts非常方便,我们可以定义Test On Windows, Test On Mac, Test On Linux,然后设置一下运行这些step的时候需要什么类型的agentQuickBuild就可以把这些任务分布到这些平台的agents上去运行了。

而其它家的可能是因为收费的方式,象TeamCity,一个build只能在一个agent上运行,我如果要做到同样的效果,就需要定义出三个项目,然后让这三个项目在不同的agents上运行,最后,还要再定义一个项目,让这个项目去收集它们的artifacts,非常麻烦。

BambooAntHill也类似于TeamCity

Hudson在这块的能力很弱,个人感觉不如其它的产品强大,而且使用起来也更复杂一些。

Report功能和统计

上述各家CI SERVER都提供了Report的功能和统计的功能。

Hudson是支持报告类型最多,最全的,因为是OpenSource的,有太多人开发。

Bamboo属于支持报告类型最少的,不过也有很多第三方的plugin(插入式的)供选择。

我们所关心的几个reports都有被各家支持;

QuickBuildreport给我的感觉最华丽,不过好像是参考google analytics来的,从界面上看和analytics简直就是一个翻版。

在使用上,QuickBuildTeamCity的最方便,直接点报告中的链接就可以作一些过滤。

在统计信息方面,各家对tests的统计都非常完备,这也从一个侧面反应出test driven现在已深入人心。

在支持Test Driven方面,TeamCity是力拔头筹,得益于开发IntelliJ的经验,TeamCity不仅可以自动寻找出项目中的unit tests(你不用在Ant脚本里调用junit task,或者在Maven里调用surefire),而且对于上次运行失败的test cases,它可以在下次build中自动先运行,这样就可以避免一个build运行了很久才发现上次失败的test还没有被更正过来呢。

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

对于其它的CI Server则是亮点不多。其实也很强,只不过是对比而言,我觉得TeamCityQuickBuild更强,更好。

与第三方工具的集成

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

价格

考虑一下价格的因素,记得有人说过,Price is nothing, but price is everything,尤其在这个金融危机的年代里。OpenSource永远是最好的。而在商用的这几个里QuickBuild最便宜,它使用的是Site License,一个Site$2999AntHill最贵,随便搞搞就要$10000了,TeamCity的入门也很便宜,$19993agents,它是按agent收费的,Bamboo也很贵,按照它的功能而言,性价比不是很好。

总结

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

posted @ 2011-10-31 12:14  天空行马  阅读(784)  评论(0编辑  收藏  举报