持续集成工具的选择

持续集成(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这个领域现在还处于高速发展阶段，本文纯属探讨，欢迎大家拍砖。由于时间有限，对每个产品了解的不是很深入，错误在所难免，如果我有什么地方不是很准确，也欢迎告诉我。

 

评论

25 楼 whaosoft 2009-10-14  

daquan198163 写道

zgsheng 写道

daquan198163 写道

您做过开发么？
难道是我孤陋寡闻？"提交前先update" 这种事务性操作，据我所知计算机还不会做，你打算让计算机去提交什么？
"谁出错谁恢复"  这个"谁"只要看一眼svn日志就可以找到。

抱歉,可能是两种情况，一是大家说岔了，说的不是一回事.再有一种可能就是您还在长身体，理解不了大人说的话.回家多吃点排骨牛肉啥的，长好身体再来吧.

如果是第一种情况，那就请你解释一下你说的是哪一回事儿吧：

引用

"规定提交前先update" 这种事务性操作我更倾向于相信机器,而不是相信人.

你相信的机器如何提交前先update？ 
也别拿提交proof build说事儿，这个工作也得靠人，按照你的观点，这种事务性操作也应该交给机器来做的。

至于第二种情况，你确信其他人都能理解你这个所谓大人说的话？

别吵了 呵呵 不过我也没理解 不过别鄙视我的智商啊 第二种情况真的看不明白

24 楼 badqiu 2009-10-14  

gigix 写道

andyyehoo 写道

continuum为啥不提呢？上家公司用continuum+maven，基本上实现了所有需要的功能了，效果也不错，配置稍微复杂一点而已。CruiseControl就算了，3年前就那个样子，现在还是这个样子，UI太丑，实在下不了口

嗯，请访问你的cruisecontrol的 /dashboard

一直用cruisecontrol,只注重功能实用,谁也不会整天叮着持续集成看,能够邮件通知构建结果就行了,不管美丑，所以还是比较喜欢看/cruisecontrol视图。

/dashboard就界面好看点，根本没有多少功能提升，瞎整。

23 楼 wsgwz_2000 2009-10-14  

对于编译不通过，跑回归测试，跑冒烟测试，代码质量检查
这些日构建就够了
甚至一个ant task就够了（俺们项目小，不用要多台机器编译个一天一夜的  ）

对于联调，模块集成，业务集成
首先的疑问是，这里的"集成"是持续集成的集成吗？
而且，用俺之前提过的俺们的解决方法也就够了

搭个测试环境？俺们有脚本
老板客户要感受项目的健康状况？俺们老板客户只对进度表感兴趣
成就感？感觉还是小里程碑更有成就感，老是持续着，敏感度会不会变低呀

项目健康度的更快反馈？俺还没有所谓的"健康度"这种体会 

要是有个现场客户？
为了他老人家能持续地及时地感受到项目"健康度"，能持续地及时地感受到项目的"呼吸"与"心跳"....
那俺暂时同意持续集成。总不能扔个eclipse给他，或者让他来跑ant task 

可因为持续集成是"best practice"
俺不做的话，心中彷徨不安的很

22 楼 daquan198163 2009-10-14  

zgsheng 写道

daquan198163 写道

您做过开发么？
难道是我孤陋寡闻？"提交前先update" 这种事务性操作，据我所知计算机还不会做，你打算让计算机去提交什么？
"谁出错谁恢复"  这个"谁"只要看一眼svn日志就可以找到。

抱歉,可能是两种情况，一是大家说岔了，说的不是一回事.再有一种可能就是您还在长身体，理解不了大人说的话.回家多吃点排骨牛肉啥的，长好身体再来吧.

如果是第一种情况，那就请你解释一下你说的是哪一回事儿吧：

引用

"规定提交前先update" 这种事务性操作我更倾向于相信机器,而不是相信人.

你相信的机器如何提交前先update？ 
也别拿提交proof build说事儿，这个工作也得靠人，按照你的观点，这种事务性操作也应该交给机器来做的。

至于第二种情况，你确信其他人都能理解你这个所谓大人说的话？

21 楼 wsgwz_2000 2009-10-14  

cristal 写道

看了很多回帖讨论有关持续集成是否必要，我有点无语，持续集成作为best practice已经是毋庸置疑

不懂才问的啊
很多人描述了持续集成多么多么好，可我却体会不到这个best practice到底"好"在哪
可能是没有没有体验过之前的"不好"
再有个上下文环境的描述，俺就好明白多了

cristal 写道

也不会被该死的经理追在屁股后面骂：XXX，快点回公司，你还有N多bug没有fix！

这个就是没有上下文

zgsheng 写道

如果从低层开始或者模块互调频繁......数据强耦合,不做持续集成,简直就是噩梦

这个算是有一点上下文，可俺们项目不做持续集成也没做过这个噩梦呀

20 楼 yjshen 2009-10-14  

cristal 写道

非常赞同！我们正在尝试这个proof build，但是好像现在缺少IDE支持，显得还不是很方便，不知道是不是这样？以后你们会有IDE的集成吧？

感谢您选择我们的产品。对于proof build，我们选择基于agent的方式实现，好处是可以不依赖特定的IDE。同基于IDE plugin实现的方式相比，方便性是有所不如。不过我们在以后的版本中也会陆续增加对主流IDE的支持。

19 楼 wfeixiuw 2009-10-13  

我们在实践中，持续集成和冒烟测试相结合，有专门的自动化测试环境用于验证每日构建的最新版本是否可以通过所有的自动化测试用例。
我们鼓励更早的checkin代码，这样便于最快的发现问题。
这样也节省了开发人员搭建环境来验证代码改动是否影响其他功能。
现实中，验证bug是否修改最难的一点是很难确定是否对其他功能造成影响，而冒烟测试可以改善这点。
持续构建和冒烟测试越早使用，产生的效益越大。
自动化测试用例数目越多，产生的效益越大。

18 楼 cristal 2009-10-13  

yjshen 写道

非常感谢楼主提到我们开发的QuickBuild。

致敬！想不到你是中国的？我发了MSN给你，有空请你到我们公司来聊聊吧。目前我们已经购买了你们的Service，非常喜欢你们写的这个系统！也祝你们好运！

yjshen 写道

1. 开发人员向持续集成工具提交一个proof build。
2. 持续集成工具负责update你的工作拷贝（通过IDE的plugin，或者是开发人员机器上安装的agent）
3. 持续集成工具收集当前要checkin的内容发送到服务器与最新的代码集成，并运行测试用例。
4. 如果集成成功，你的代码将会被自动checkin。

非常赞同！我们正在尝试这个proof build，但是好像现在缺少IDE支持，显得还不是很方便，不知道是不是这样？以后你们会有IDE的集成吧？

看了很多回帖讨论有关持续集成是否必要，我有点无语，持续集成作为best practice已经是毋庸置疑，就像SCM工具，Bug Tracking工具，现在应该是每个开发团队所必备的吧。如果说有人和你讨论你公司用没用Bug Tracking，用没用SCM，你是不是会觉得有点搞笑？诚然，如果没用Daily Build，我们可以工作的很欢乐（因为我们不会收到那些所谓的垃圾邮件）。其实，如果没有Bug Tracking，我们会工作的更欢乐，因为，我们不再为考核我们的efforts而烦恼，也不会被该死的经理追在屁股后面骂：XXX，快点回公司，你还有N多bug没有fix！

17 楼 yjshen 2009-10-13  

daquan198163 写道

您做过开发么？
难道是我孤陋寡闻？"提交前先update" 这种事务性操作，据我所知计算机还不会做，你打算让计算机去提交什么？
"谁出错谁恢复"  这个"谁"只要看一眼svn日志就可以找到。

非常感谢楼主提到我们开发的QuickBuild。现在的很多持续集成工具可以做到提交之前先update，流程是这样的：
1. 开发人员向持续集成工具提交一个proof build。
2. 持续集成工具负责update你的工作拷贝（通过IDE的plugin，或者是开发人员机器上安装的agent）
3. 持续集成工具收集当前要checkin的内容发送到服务器与最新的代码集成，并运行测试用例。
4. 如果集成成功，你的代码将会被自动checkin。

这样的好处是只要大家遵守这个约定，基本上可以防止明显有错误的代码checkin到版本控制系统中。

万一有错误代码checkin导致集成不成功，持续集成工具也可以自动运行iterative build，也就是一个revision一个revision的去运行build，直到找到“干坏事”的人，并通知他去改正。

对持续集成本身不感冒的团队，也可以利用持续集成工具做开发流程的更好整合。在软件开发中，build是一个比较核心的东西：开发团队的目的是向测试团队提交一个可供测试的QA build，而测试团队测试该build，并确认它是否达到要求的质量标准。测试通过的build会被提交给发布经理进行发布。最终客户拿到的就是一个release build。Issue实质上也都是针对特定的build而言，绑定到build上面的。持续集成工具可以让这个过程自动化起来：
1. 一个阶段的开发结束后，开发组长把开发人员粗略测试过的DEV build，提升为QA build。在提升的过程中，持续集成工具可以到issue track工具里去收集跟这个build相关联的issue，对版本控制系统打上合适的标签，并且把它自动deploy到测试机器上等待测试。
2. 持续集成工具告知测试组有一个新的QA build等待测试，并且显示相关联的等待验证的issue。测试组运行相关测试用例，通过后把这个QA build标记为golden build，并通知发布经理。
3. 发布经理把golden build提升为release build。在此过程中，持续集成工具可以去自动给版本控制系统打上release标签，更新公司网站显示最新版本的下载，并且通知客户有新版本fix了他们关心的bug等等。

在我们自己的实践中，每次发布版本之前，我们先通过http://build.pmease.com构建一个QA build，并自动deploy到测试网站(http://demo.pmease.com)运行测试用例，自动化测试通过后，我们做些手工测试，满意了就把这个QA build提升为release build，网站的下载链接（http://www.pmease.com/downloads）自动得到更新，客户也自动得到通知。

16 楼 daquan198163 2009-10-13  

zgsheng 写道

wsgwz_2000 写道

daquan198163 写道

aqingsao 写道

“任何稍微专业一点的团队都能保证代码编译通过吧？”
──未必，即使一个小团队，也会出现check out代码本地编译不过的情况，更别说大型团队和分布式团队了。没有持续集成，代码的集成会是噩梦。

简单，规定提交前先update，这好像是基本常识
这样的团队就是用了CI，也只是天天听到报警

这种现象：check out代码本地编译不过的情况
我们项目，不管大小，不管是我们这边单独开发还是和日方联合开发，也几乎不会出现这种现象

也是靠很简单的“规定提交前先update”和“谁出错谁恢复”

听过这样的说法：持续集成是项目的呼吸（还是心跳？）
也在项目里试用过CC，可始终没感受到这种呼吸（心跳？）的感觉，
因为项目组成员普遍反映体会不到什么好处，所以放弃了这项实践
（我们只用来跑跑测试，也许是方法不对吧）

对于集成，我们更看重的是关联业务间的集成，
接口的正常是必须的，更重要的是对关联数据和逻辑的集成，
因为在以往的项目里这一块出现的问题比较多，所以现在要求在单体测试阶段就提前加入对集成的考量

是否我们公司之前的持续集成实践完全走错了路？

"规定提交前先update" 这种事务性操作我更倾向于相信机器,而不是相信人.
"谁出错谁恢复"  这个"谁"是谁?你知道吗?

在已有稳定的底层开发框架,团队开发人员各自开发与其他人都无关联的模块的情况下，你的情况是可行的.
如果从低层开始或者模块互调频繁......数据强耦合,不做持续集成,简直就是噩梦

您做过开发么？
难道是我孤陋寡闻？"提交前先update" 这种事务性操作，据我所知计算机还不会做，你打算让计算机去提交什么？
"谁出错谁恢复"  这个"谁"只要看一眼svn日志就可以找到。

15 楼 rainv 2009-10-13  

1.有CI工具的话当完成一个功能的代码提交后测试可以及时取得版本测。
2.及时编译能及时反馈项目的可运行情况，健康度。
3.加上自动化单元测试，回归测试能保证项目再被改动重构后，项目正确性，完整性，可靠性能得到及时验证。

14 楼 wsgwz_2000 2009-10-13  

gigix 写道

daquan198163 写道

构建失败时会有什么现象发生，如果会亮起一盏红灯（真的灯）或播放一些恶心的声音，大家应该就能感受到了

嘿嘿，你还是对基层程序员的水平太乐观了～～
我最近在客户这遇到的情况：项目组里有个CruiseControl在跑，但是找几个程序员一问，都不知道地址在哪里，从来不看的。于是找台电脑打开，问，大家都知道这是什么吗？然后看见一片茫然的表情…第二天突然发现CruiseControl被关掉了，一问咋回事，有人说，哦，那玩意老是发邮件（build失败），烦人得很。

很多你认为理所应当的事，其实很多人不这么认为，这种事情，一定要有所觉悟才行亚～～

恩恩，跟俺们这差不多

13 楼 fallen_lord 2009-10-13  

顶楼上的
我们的CI现在主要职责是：
1. 从早期开始持续维护项目部署
2. 快速给客户/老板/自己查看项目效果与进度，让大家感受到项目健康状况和成就感
3. 为懒到不想在自己机器上起应用或是嫌自己机器内存不够的开发人员提供测试环境

我们实施的是Hudson，简单方便

ps. 我没觉得Hudson的分布式构建如楼主所说有啥不方便的

12 楼 抛出异常的爱 2009-10-12  

gigix 写道

daquan198163 写道

构建失败时会有什么现象发生，如果会亮起一盏红灯（真的灯）或播放一些恶心的声音，大家应该就能感受到了

嘿嘿，你还是对基层程序员的水平太乐观了～～
我最近在客户这遇到的情况：项目组里有个CruiseControl在跑，但是找几个程序员一问，都不知道地址在哪里，从来不看的。于是找台电脑打开，问，大家都知道这是什么吗？然后看见一片茫然的表情…第二天突然发现CruiseControl被关掉了，一问咋回事，有人说，哦，那玩意老是发邮件（build失败），烦人得很。

很多你认为理所应当的事，其实很多人不这么认为，这种事情，一定要有所觉悟才行亚～～

鸟的...outlook
配的乱七八糟
都是为了自动邮件.....

太多的无聊邮件了....
基本找不到有必要看的东西了...

有些人在BTS上聊天....讨论....想杀人


楼上有没有些可用的秘笈?
分享一下?

引用

你们用下来，觉得CI带来的最大价值是什么？
我目前的理解是它可以频繁的跑回归测试，因此对于国内程序员很少写测试的现状，CI基本就是鸡肋。

如果你不认为布署工程师也算是人的话.....最后一天给代码让他去布也是可以的.

11 楼 gigix 2009-10-12  

andyyehoo 写道

continuum为啥不提呢？上家公司用continuum+maven，基本上实现了所有需要的功能了，效果也不错，配置稍微复杂一点而已。CruiseControl就算了，3年前就那个样子，现在还是这个样子，UI太丑，实在下不了口

嗯，请访问你的cruisecontrol的 /dashboard

10 楼 gigix 2009-10-12  

daquan198163 写道

构建失败时会有什么现象发生，如果会亮起一盏红灯（真的灯）或播放一些恶心的声音，大家应该就能感受到了

嘿嘿，你还是对基层程序员的水平太乐观了～～
我最近在客户这遇到的情况：项目组里有个CruiseControl在跑，但是找几个程序员一问，都不知道地址在哪里，从来不看的。于是找台电脑打开，问，大家都知道这是什么吗？然后看见一片茫然的表情…第二天突然发现CruiseControl被关掉了，一问咋回事，有人说，哦，那玩意老是发邮件（build失败），烦人得很。

很多你认为理所应当的事，其实很多人不这么认为，这种事情，一定要有所觉悟才行亚～～

9 楼 daquan198163 2009-10-12  

wsgwz_2000 写道

这种现象：check out代码本地编译不过的情况
我们项目，不管大小，不管是我们这边单独开发还是和日方联合开发，也几乎不会出现这种现象

也是靠很简单的“规定提交前先update”和“谁出错谁恢复”

听过这样的说法：持续集成是项目的呼吸（还是心跳？）
也在项目里试用过CC，可始终没感受到这种呼吸（心跳？）的感觉，
因为项目组成员普遍反映体会不到什么好处，所以放弃了这项实践
（我们只用来跑跑测试，也许是方法不对吧）

对于集成，我们更看重的是关联业务间的集成，
接口的正常是必须的，更重要的是对关联数据和逻辑的集成，
因为在以往的项目里这一块出现的问题比较多，所以现在要求在单体测试阶段就提前加入对集成的考量

是否我们公司之前的持续集成实践完全走错了路？

构建失败时会有什么现象发生，如果会亮起一盏红灯（真的灯）或播放一些恶心的声音，大家应该就能感受到了

8 楼 andyyehoo 2009-10-12  

continuum为啥不提呢？上家公司用continuum+maven，基本上实现了所有需要的功能了，效果也不错，配置稍微复杂一点而已。CruiseControl就算了，3年前就那个样子，现在还是这个样子，UI太丑，实在下不了口

今时今日，虽然我不提倡言必谈敏捷和scrum，但是每日构建这种最基本的事情，如果都做不好的话，无论大小，这家公司的项目管理人员，我还是乐于鄙视一下。

完整的测试驱动开发，能不能彻底的实现，那是另外一回事，根据项目的水平和预算，多多少少实现一点，总比没有的好，但是这个不应该成为不进行CI的理由和借口。

7 楼 Element&lina 2009-10-12  

经历过两次持续集成的失败，总结了一下，如果团队中的大多数人没有深刻理解CI带来的好处，CI实施注定是要失败的。

6 楼 wsgwz_2000 2009-10-12  

daquan198163 写道

aqingsao 写道

“任何稍微专业一点的团队都能保证代码编译通过吧？”
──未必，即使一个小团队，也会出现check out代码本地编译不过的情况，更别说大型团队和分布式团队了。没有持续集成，代码的集成会是噩梦。

简单，规定提交前先update，这好像是基本常识
这样的团队就是用了CI，也只是天天听到报警

这种现象：check out代码本地编译不过的情况
我们项目，不管大小，不管是我们这边单独开发还是和日方联合开发，也几乎不会出现这种现象

也是靠很简单的“规定提交前先update”和“谁出错谁恢复”

听过这样的说法：持续集成是项目的呼吸（还是心跳？）
也在项目里试用过CC，可始终没感受到这种呼吸（心跳？）的感觉，
因为项目组成员普遍反映体会不到什么好处，所以放弃了这项实践
（我们只用来跑跑测试，也许是方法不对吧）

对于集成，我们更看重的是关联业务间的集成，
接口的正常是必须的，更重要的是对关联数据和逻辑的集成，
因为在以往的项目里这一块出现的问题比较多，所以现在要求在单体测试阶段就提前加入对集成的考量

是否我们公司之前的持续集成实践完全走错了路？