`
cristal
  • 浏览: 26964 次
  • 性别: Icon_minigender_1
  • 来自: 上海
文章分类
社区版块
存档分类
最新评论
阅读更多

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

 

分享到:
评论
45 楼 jelver 2010-05-15  
持续集成没有任何用处,如果你不去持续改进的话 这不是废话吗,

我想知道做什么东西不需要改进的?而是你通过什么方式来改进,这不就是本帖讨论的目的嘛

貌似zhuangbility的不少啊,废话一堆
44 楼 gol_zz 2010-02-26  
gigix 写道
daquan198163 写道
持续集成是最佳实践没错,但也得在完善自动化测试之后才能发挥作用,否则就变成持续编译了。
虽说也有那么点儿作用,但是这种放空枪的事儿很可能会让不熟悉敏捷的团队产生抵触情绪。

你恰恰搞反了
在你说的这种“自动化测试不完善”的情况里,项目经理的诉求是“完善的自动化测试”,持续集成是牵引团队达成这个目标的手段

很多同学没有搞明白一件事
持续集成没有任何用处,如果你不去持续改进的话
持续集成是项目体征可视化的手段。它让你知道项目有多健康(或者多不健康)。用这个信息作为牵引,你不断改进,然后你不断看到成果,成果再次增加你改进的动力,形成正向反馈。

如果仅仅做个持续集成就想让项目变好
你发现自己肝疼,于是你去医院体检,发现自己得了脂肪肝,然后你开始特别关注自己的健康状况,你每天都去医院体检,你对自己病情的发展了如指掌
你的病会因此而减轻吗?


视角不同,有人只看到了结果,有人在关注过程。但是,大家在实践中往往忽略了过程,而想要一蹴而就得到理想的结果。

如同gigix所述,持续集成推动了持续改进,有了过程才能得到理想的结果。
43 楼 chensss2008 2010-01-21  
不同的工具應該適用于不同的公司環境,開發團隊吧。
外包公司,公司有一個項目共計100+人,開發有60+人(基本都是剛畢業的),測試20+,分開發部測試,測試部測試,還有客戶測試版。每天都有人專人打包,部署,測試,三天或一周提交給客戶測試一次。天天都有狀況,少提交代碼了,打包沒有成功了,部署沒有成功了,集成那個亂呀,真是沒法說。還是人多呀,有人的地方,就有爭端。
像我們這里的情況,持續集成絕對是利大于弊的。
42 楼 曾经de迷茫 2010-01-18  
daquan198163 写道
zgsheng 写道
wsgwz_2000 写道
daquan198163 写道
aqingsao 写道

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

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


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

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

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

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

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


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


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

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


是啊,'提交前先update',不可能啊,尤其反感VSS,CC那种独占式的修改,提交时有冲突自行Merge就可以了啊
41 楼 ronghao 2009-12-09  
gigix 写道
daquan198163 写道
持续集成是最佳实践没错,但也得在完善自动化测试之后才能发挥作用,否则就变成持续编译了。
虽说也有那么点儿作用,但是这种放空枪的事儿很可能会让不熟悉敏捷的团队产生抵触情绪。

你恰恰搞反了
在你说的这种“自动化测试不完善”的情况里,项目经理的诉求是“完善的自动化测试”,持续集成是牵引团队达成这个目标的手段

很多同学没有搞明白一件事
持续集成没有任何用处,如果你不去持续改进的话
持续集成是项目体征可视化的手段。它让你知道项目有多健康(或者多不健康)。用这个信息作为牵引,你不断改进,然后你不断看到成果,成果再次增加你改进的动力,形成正向反馈。

如果仅仅做个持续集成就想让项目变好
你发现自己肝疼,于是你去医院体检,发现自己得了脂肪肝,然后你开始特别关注自己的健康状况,你每天都去医院体检,你对自己病情的发展了如指掌
你的病会因此而减轻吗?

我认为项目可视化是关键词,这其中包括了很多实践,比如说测试、比如说各种报表
40 楼 gigix 2009-12-08  
daquan198163 写道
持续集成是最佳实践没错,但也得在完善自动化测试之后才能发挥作用,否则就变成持续编译了。
虽说也有那么点儿作用,但是这种放空枪的事儿很可能会让不熟悉敏捷的团队产生抵触情绪。

你恰恰搞反了
在你说的这种“自动化测试不完善”的情况里,项目经理的诉求是“完善的自动化测试”,持续集成是牵引团队达成这个目标的手段

很多同学没有搞明白一件事
持续集成没有任何用处,如果你不去持续改进的话
持续集成是项目体征可视化的手段。它让你知道项目有多健康(或者多不健康)。用这个信息作为牵引,你不断改进,然后你不断看到成果,成果再次增加你改进的动力,形成正向反馈。

如果仅仅做个持续集成就想让项目变好
你发现自己肝疼,于是你去医院体检,发现自己得了脂肪肝,然后你开始特别关注自己的健康状况,你每天都去医院体检,你对自己病情的发展了如指掌
你的病会因此而减轻吗?
39 楼 一蓑烟雨任平生 2009-12-08  
楼上的在说废话
38 楼 rrsy23 2009-11-06  
工具不是一切 持续集成 不是万能

关键在于团队建设管理规范

人才是一切之本,万恶之源
37 楼 江南白衣 2009-10-30  
同意楼上,团队对CI的需求不可能脱离测试用例而存在。
36 楼 daquan198163 2009-10-21  
持续集成是最佳实践没错,但也得在完善自动化测试之后才能发挥作用,否则就变成持续编译了。
虽说也有那么点儿作用,但是这种放空枪的事儿很可能会让不熟悉敏捷的团队产生抵触情绪。
35 楼 sg552 2009-10-21  
.....认真了,我输了
34 楼 sg552 2009-10-21  
.....认真了,我输了
33 楼 andyyehoo 2009-10-19  
elvewyn 写道
jansel 写道
不知道大家真正的项目有没有把CI用好,看大家的评论好像自己的项目用的很好。

CI这个东东是要用,但是也应该添加一些惩罚措施,比如谁的COde编译不通过允许修改一次,第二次不过就要罚钱了。要是没有惩罚措施,CI这个东东就完全取决于个人意愿了。

有些程序员可能会想:编译不通过就不通过,反正又不是发布阶段。

要是碰到了外包项目,CI的价值就更加体现不出来了,代码都写不完了,谁还去管CI呢?

所以CI是不是best practise 这个还真的要看场景。


惩罚是很扯的一件事情。问题关键是工程师们内心是不是关心Build失败这件事情。惩罚也许表面会达到效果,但是如果你作为被惩罚对象或者可能被惩罚的对象, 心里会爽吗?这种管理是没有人性的。所以关键是让工程师真正的接受CI。这需要很多的工作, 例如宣传、知识分享等等。而且要做的好。那种干巴巴的培训效果不大。


这种还是要在公司形成一个气氛才行,敬业的气氛,如果有这样的氛围和素质,收到build失败的邮件,那个人都会很不好意思的了,不需要惩罚……

当然,对于不少人来说,还是没这样的习惯,小惩罚……例如,请大家全体吃雪糕之类的,嘻嘻哈哈中而过,我觉得是好团队的习惯,人都是会犯错误的,系统大了,跑全部的测试用例很耗时间的话,难保重构就算过了自己的单元测试,到了CI服务器就能全部通过的,如果说到罚钱扣工资,这个大家都不太舒服,请个小客,我觉得应该也是个Best Pratice。
32 楼 andyyehoo 2009-10-19  
引用

您做过开发么?
难道是我孤陋寡闻?"提交前先update" 这种事务性操作,据我所知计算机还不会做,你打算让计算机去提交什么?


提交前先update的事情是这样的,每个程序员每天把开发密切的项目,更新一次,作为上班前第一件事,是个好习惯,如果做个计划任务,上班到前就执行一次,那就更好。

至于这样做后,一天的开发中,代码冲突的事情,就让scm系统来提示好了,提交代码前先update一次这样的做法,无论如何不是best practice
31 楼 andyyehoo 2009-10-19  
badqiu 写道
gigix 写道
andyyehoo 写道
continuum为啥不提呢?上家公司用continuum+maven,基本上实现了所有需要的功能了,效果也不错,配置稍微复杂一点而已。CruiseControl就算了,3年前就那个样子,现在还是这个样子,UI太丑,实在下不了口

嗯,请访问你的cruisecontrol的 /dashboard


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

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


cruisecontrol,纵向比,比3年前是好点,不过横向比,还是差……配置烦琐方面我不太确定有没有提升,反正有Hadson和Continuum了,我没有兴趣去尝试一个旧的酸萝卜。

大部分人是知道构建结果就可以了,不过配置管理员还是需要经常访问这个界面的,例如查看更加详细的report,例如测试用例的执行结果历史,测试用例的单元覆盖率,等等…………好的CI,不仅仅是一个配置了,就整天发送邮件的系统而已。
30 楼 elvewyn 2009-10-18  
jansel 写道
不知道大家真正的项目有没有把CI用好,看大家的评论好像自己的项目用的很好。

CI这个东东是要用,但是也应该添加一些惩罚措施,比如谁的COde编译不通过允许修改一次,第二次不过就要罚钱了。要是没有惩罚措施,CI这个东东就完全取决于个人意愿了。

有些程序员可能会想:编译不通过就不通过,反正又不是发布阶段。

要是碰到了外包项目,CI的价值就更加体现不出来了,代码都写不完了,谁还去管CI呢?

所以CI是不是best practise 这个还真的要看场景。


惩罚是很扯的一件事情。问题关键是工程师们内心是不是关心Build失败这件事情。惩罚也许表面会达到效果,但是如果你作为被惩罚对象或者可能被惩罚的对象, 心里会爽吗?这种管理是没有人性的。所以关键是让工程师真正的接受CI。这需要很多的工作, 例如宣传、知识分享等等。而且要做的好。那种干巴巴的培训效果不大。
29 楼 jansel 2009-10-16  
不知道大家真正的项目有没有把CI用好,看大家的评论好像自己的项目用的很好。

CI这个东东是要用,但是也应该添加一些惩罚措施,比如谁的COde编译不通过允许修改一次,第二次不过就要罚钱了。要是没有惩罚措施,CI这个东东就完全取决于个人意愿了。

有些程序员可能会想:编译不通过就不通过,反正又不是发布阶段。

要是碰到了外包项目,CI的价值就更加体现不出来了,代码都写不完了,谁还去管CI呢?

所以CI是不是best practise 这个还真的要看场景。
28 楼 neodoxy 2009-10-15  
尝试了一下CC和Teamcity,最后选择了teamcity,应用于C++开发
27 楼 gigix 2009-10-14  
fight_bird 写道
CI不是绝对的best practise,要和团队规模、项目周期相匹配,2-3个人几个月搞定的小项目谈什么CI,一个svn加基本的协作开发制度即可,即便10人左右协作开发的项目,上述协作方式 + Ant扩展也够了,若是不管项目实际,上来就扣上CI大法,纯粹是技术强迫症。

你用的什么协作开发制度可以保证你提交的代码不破坏现有测试?这个我很感兴趣。
26 楼 fight_bird 2009-10-14  
CI不是绝对的best practise,要和团队规模、项目周期相匹配,2-3个人几个月搞定的小项目谈什么CI,一个svn加基本的协作开发制度即可,即便10人左右协作开发的项目,上述协作方式 + Ant扩展也够了,若是不管项目实际,上来就扣上CI大法,纯粹是技术强迫症。

相关推荐

Global site tag (gtag.js) - Google Analytics