跌跌撞撞的持续集成之路

作者 仝键 发布于 2008年9月18日 上午12时38分

社区

Agile

主题

敏捷技术,

质量交付

标签

持续集成

“天下事头绪纠缠，兴一利必也生一弊。”

一句话，道破了改进难点所在。最近在项目中围绕持续集成做改进的时候，对这一点感受颇深。跌跌撞撞的一路走来。我们的持续集成的过程已经变得有些“个性化”，反过头来看我们一路的变化，非常有意思。

从项目的技术架构说起，我们的项目是采用的J2EE+Flex的方式进行开发的。在我进入项目组的时候，一个比较健壮的持续集成环境已经搭好了。工程分为两个，一个是Java后端的工程，一个是Flex前端的。我们的持续集成服务器是CC。整个开发工作是围绕着持续集成展开的。一周为一个迭代。

那个时候，我们采用的是比较标准的方式：

• 后台采取TDD的方式开发。
• 每次提交代码之前更新所有代码，然后运行所有测试用例，全部为绿色的时候才提交。
• 前台Flex比较麻烦，所以采取了用功能测试覆盖单元测试的方式。用基于Ruby的FunFx写单元测试。工作方式与后台差不多，每次前台功能测试全部通过了才提交。
• 持续集成的流程是每隔5分钟检测一边代码库，有更新就build。
• build的流程是先编译后台，跑单元测试，单元测试通过了，再编译Flex，将swf和html以及后台的文件打成war包，部署到tomcat上去，跑功能测试。
• build成功之后发布到特定的目录，形成发布列表。有war包供人下载。

那个时候，build一次大概是15分钟，因为Check In Gate环节是按照标准流程走的，所以build出错的几率也小。CC大多数时候是绿的。哪怕偶尔出问题红了，也很快被修正了。

随着项目的开发，代码规模越来越庞大。功能测试越来越慢，比起自动执行脚本那种速度，开发人员更乐意手动点两下，加之上面对工作进度的压力。更改了一些工作方式：

• 后台的工作方式不变。
• 前台，将功能测试脚本的工作交给几个测试人员编写。几个测试人员也坐在附近，基本可以看作团队成员（到后来编制也是我们团队的成员了）。 开发人员人肉测试一下保证没有问题了再提交。
• 测试人员写脚本的流程是拿到上一次build成功的war包，在本地写脚本，本地测通过了再提交。
• 持续集成服务器上功能测试不通过的时候，由测试人员提交BUG，开发人员修改。
• 持续集成的流程依旧。

这样，从后来收集的数据看，工作效率是提升了，因为参照以前的统计，开发人员的工作一下减轻了1/3。以进度来衡量的速度自然很轻易就可以让上级满意了。

新的解决方案总会产生新的问题，测试人员在测试方面的专业性，使得他们写出来的脚本测的更细。功能测试的时间占耗，增长的更快了，短短半个月，就增长到了1个小时。每当出现问题，作出反应之后，要在1个多小时以后才能知道结果。而且，持续集成方面并没有做到，一旦出错，谁也不能提交代码这么严格。模块化的设计所带来的假想的安全感和进度的压力，使得开发人员修正问题的激励不高。于是修正问题的速度不如产生问题的速度快。持续集成服务器在那两个个礼拜里只有两头是绿的，周一早晨和周五下午。

最早，我们发觉，由开发人员重构造成的脚本失败占大多数，而测试人员每次拿到的上一个版本是没有错误的。所以会出现自动化脚本本地跑得过，服务器上跑不过的情况发生。于是我们修改了发布的逻辑，在后台单元测试通过、flash编译完成的情况下打的那个war包，复制一份，放到某特定目录指定为current build。供测试人员写测脚本使用。

过程改进之后，测试人员可以快速的修正脚本了，虽然对于开发人员重构造成测试人员工作的返工无疑是一种浪费，但是毕竟自动化的测试省了回归测试的不少时间，还是可以接受。

脚本的修正速度解决之后，工作似乎有了些起色，但很快，问题的本质就暴露了出来--build的时间太长了，修得速度还是跟不上问题产生的速度。尤其是中间缺少当build失败时强制阻止代码提交的环节。这之后依然是周一和周五两头绿，中间都是红的。于是，我们觉得问题还是出在build速度上。我们人工的将功能测试脚本分到四个suite里去，然后以多线程的方式运行。速度被提高了4倍。于是又消停了两天。

好景不长，多线程的测试似乎不太稳定。很多本地可以跑通的测试用例，到了服务器上就失败。险些一个礼拜都没有build出一个版本。最后不得不改回单线程。这时，build一次已经占到了100分钟。第一期的产品Backlog还没有完成1/3。

持续集成走到这里已经进入一个困境，有必要做一些更深一步的改进。经过多次讨论，归纳出了几套方案：

• 分冒烟测试和all test两套测试用例集是我们当中呼声最高的一种方案，当我的代码提交之后在跑完所有单元测试和基本的冒烟测试之后就发布beta版，由测试人员接到beta版，进行更细致的自动化测试并带一些人肉测试。但是反对的声音认为，不跑完全部的测试用例就失去了持续集成的意义。而且会更降低开发人员修正 Bug的积极性。于是作为修正，支持的声音则提出，在Check-In Gate处把关，恢复每个人提交代码之前跑测试用例的实践。可这明显会给开发人员带来更大的工作负担，估计以此时的进度压力，开发人员的安全感肯定会大幅下降。很可能会推行不下去。
• 另一个方案是从细节处调优，把WEB应用部署到另外一台机器上去，或许就会稳定一些了。但是反对的声音认为，以测试用例的这个增长速度，他早晚会不稳定的，而且可能撑不过两周。作为修正，想考虑分布式，但是我们所有人的知识储备中，并没有一个人清楚CC有没有分布式能力。所以想的是购买Cruise，但是价格的障碍就摆在眼前了，在项目前景还不是很明朗的情况下，估计很难申请到资金，但也不是不可能，只要我们敢于冒这个风险。
• 第三，便是更为高级的分支式开发，将版本库划分一下分支，以分支来搭配持续集成，以分支合并来触发自动构建。这样做，开发的过程就更加有板有眼，粒度可以划分的更细。可是分支的划分，一时想不清楚。但是假设想清楚了，似乎这也使得我们的工作流程更加复杂了，做如此之大的改变，风险有多大？效果有多大？成本有多大？到底是值不值得？一时也想不清楚。

方案有了，听起来都很有道理，也都有问题。该如何做出决策，是个问题。现在大家众说纷纭，都有理，就变得难以抉择。而且到现在了是不能随便尝试的，这种尝试也是一种风险，一旦出问题造成的成本上升都会加大我们身上的压力。

迷茫之下到AgileChina上跟大家讨论了一下。非常高兴的收集到了几方面的建议：

Jeff Xiong觉得可以将测试分级，并将build分为两个环节，一个跑基本的用例，一个跑全部的用例。这跟我们的第一套方案的思路吻合。但是这种行为是不是失去了持续集成的意义呢？他也不是很确定，他说：

我也不确定……不过，不全面的持续集成至少比不能用的持续集成要好。哪怕一个quick build（只？）能抓到80%（70%？60%？50%？）的defect，如果它只要很少的时间就能跑一遍，似乎值得这样做。

不过同时就需要（可能是专门的）人来关注slow build的健康状况，不然broken functional tests可能被忽视并累积。

因为是在论坛上，互相之间的交流容易造成理解上的偏差，我便阐述了一下我的理解：

嗯。。。也就是说分一个fast build和一个slow build然后有专人关注slow build。

那我的理解，这个fast build应该是反映了后台的健康和前台与后台的基本集成的健康。主要用来完成保障集成的角色。

而slow build则是反映了从用户接口来看的软件的健康状况，定期回归，防止发生过的错误再次发生。

这样逻辑上看着很清晰，但是两者之间的同步。。。会不会有什么问题呢？

Jeff Xiong认可了我的理解，并提出了更进一步的解释和建议：

slow build实际上是运行完整的回归测试套件。当然理想的情况是slow build基本上不出错，因为*逻辑*用单元测试都覆盖到了，功能测试只是在描述*表现形式*。那么因为slow build基本上不出错，就没有价值每次都去运行它，让它在后台慢慢的跑着，过一段时间（半天或者两小时）去关注它一下，没问题就好，偶尔出了问题就马上解决并且加上对应的单元测试。这样你既节约了时间又不会严重降低对质量的保障力度。

实际上的情况可能比较难这样理想，但是和所有好的环境一样，这个环境不是说一下子规划好就万事大吉的。你可能大概的分一分，然后不断的维护，在两组build之间交换测试案例，一些覆盖到大量功能的、经常出错的案例也许要换到fast build的冒烟套件里面，一些看起来永远不会出错的案例也许可以换到slow build去。一直琢磨这个事，它才会变得越来越好。

（题外话：最近我觉得稍微大一点的项目应该有比较专注的build master，developers往往并不是特别认真的考虑build和CI的持续改进。）

而胡凯则提出了一些基于CC采用分布式的解决思路：

CruiseControl是支持一个叫做Distribute的Contrib，它的Idea是：因为CruisControl支持叫做Composite的build方式，那么你可以起多个build server一起来build同一个项目，当且仅当所有的子build通过，整个build才算成功。

对于每个build server，你是在单线程测试，对于整个项目，你却是并发测试，因为有多个server同时在跑测试。

但是他也说到CC毕竟是开源的东西，配置起来十分麻烦，于是最后也提出了采用Cruise的方案^_^:

或者你也可以尝试一下ThoughtWorks新发布的Cruise, 基本的理念很相似， 都是把测试分布到不同的机器上执行。

在试用期内可以同时跑6个Agent.你可以在每个Agent上执行不同的Target比如

Agent1 : ant ft.suite.1
Agent2 : ant ft.suite.2
Agent3 : ant ft.suite.3

你可以拿来玩儿下，根Open Source的那个比起来，应该容易设置很多。

缺点是：

• 你必须使用 hg或者svn 作为 SCM
• 试用期过后，你只有2个免费的Agent

另外，糖醋鼻子还提到了分支式开发，大家围绕这个还展开了激烈的讨论，不过我考虑到分支式开发对我们的利可能要远小于弊，最终还是放弃了这个方案。

在吸取了两方面的建议之后，经过一番思考，决定开始两方面的准备，一方面，对测试用例的分级方面做了一些工作，重构了一部分用例的结构。另一方面我去调研分布式构建的实现手法。CC的配置果然非常麻烦，调研期间发现了有RemoteAnt这个东西，试了一下基本满足我们的需求，考虑到一个Agent不用做的太过重型，于是就采用了这个方法。在分布式的技术调研已经完成的情况下，测试分级要不要做成了一个问题，但考虑到目前需求只作了1/3，如果这个都抗不住要分级的话，后面的工作就没法做了，所以分级的事情，虽然做了，但是也暂缓实行。

现在实践已经采用，会不会产生新的问题呢？前文说过“兴一利必也生一弊”，这个事情是肯定的。那么问题就来了，既然弊端肯定会滋生，我们怎么知道作出的决策是正确的呢？

其实，倒回去看这一路走来的过程，除了一个可以运行的过程以外，还有一个很重要的收获，那就是：如何进行决策。而所谓决策，并不是在黑白分明的事情之间做出选择，而是在都有理的事情中做出选择。就像我们都知道做软件设计的时候，设计是没有好坏之分的，只有适不适应你的具体情况之别。所以当我们面临几套解决方案的时候，就好象面对几套设计方案一样，真的是很难选择。如何做？各自就有各自的思路了。像我们就吸收了敏捷开发的思想中所强调得不做过度设计。选择立杆见影的改进去做。同时，像前文所说，抱着拥抱变化的态度，相信兴一利必生一弊并不是坏事。相反，他可以从一定程度上，带领我们找到真正的问题。

作者简介：仝键，网名咖啡屋的鼠标，06年大学毕业，普通程序员，专注于Java、Flex方面的开发、Agile等软件开发方法论的学习。爱好参加社区活动。

---

志愿参与InfoQ中文站内容建设，请邮件至editors@cn.infoq.com。也欢迎大家到InfoQ中文站用户讨论组参与我们的线上讨论。

1. 返回顶部

   InfoQ能否加一个功能

   2008年9月18日 上午1时55分 发表人 R Lee

   就是统计每篇文章的阅读次数，然后根据阅读次数做每周推荐，或者是每月推荐，现在很多网站都有的

   回复

2. 返回顶部

   学习微软经验：超大规模的 SQL Server build 系统

   2008年9月18日 上午3时40分 发表人 Charlie Zhang（张恂）

   微软中国研发集团服务器与开发工具事业部SQL中国研发中心博客：
   
   
   
   
   SQL Server Build 系统（刘春雨 SQL Server中国build团队，2008-7-28）
   
   
   
   
   先提两个问题：
   
   
   
   1）如此成功的超大规模 build，微软是如何做到的？有什么杀手锏吗？
   
   
   
   2）微软这么做，是不是敏捷？是敏捷，还是卓越？敏捷好，还是卓越好？
   
   
   
   
   中西合璧的敏捷 OO 教练 张恂
   
   
   www.zhangxun.com

   回复

3. 返回顶部

   CC 2.7.x 支持比它的DistributedContrib更建单的分布式

   2008年9月18日 下午8时1分 发表人 Chelsea Ajax

   cruisecontrol.sourceforge.net/buildgrid.html
   
   一句话总结就是在多台机器上构建, 而把结果汇总到一个页面

   回复

4. 返回顶部

   想省钱的话何必死抱着CC

   2008年9月18日 下午8时2分 发表人 Chelsea Ajax

   Hudson不也不错

   回复

5. 返回顶部

   Re: InfoQ能否加一个功能

   2008年9月18日 下午9时19分 发表人 申 刘

   谢谢您给我们提的建议！这些功能已经在开发当众，将会在我们的下一个版本中实现:)
   
   而我们现在的做法是，每周通过我们的Newsletter（我们管他叫“每周精要”）向大家推荐本周的妙文；每个月，通过我们的电子期刊（将于下个月发布）向大家推荐这个月的精彩文章:)

   回复

6. 返回顶部

   同感，InfoQ 的 useability 有待改进

   2008年9月18日 下午10时30分 发表人 Charlie Zhang（张恂）

   一年之前我也曾经提出过许多类似的建议。可是遗憾，至今好像没什么动静。
   
   
   
   个人觉得，尽管英文版的内容很好，但 InfoQ 离真正的 2.0 社区还距离很远，现在顶多 1.5。

   回复

7. 返回顶部

   Re: 同感，InfoQ 的 useability 有待改进

   2008年9月19日 上午1时17分 发表人 霍 泰稳

   不要着急，这个功能已经指日可待了:) 而且还会增加评论邮件提醒功能，即你参与评论的内容，如果其他人有回复，会通过邮件给你发送通知。我们的开发团队人员稀少，backlog上的功能一大堆要实现，所以动作慢了一些，大家多担待。

   回复

8. 返回顶部

   Re: 学习微软经验：超大规模的 SQL Server build 系统

   2008年9月19日 上午1时23分 发表人 yi wang

   偶不是ms的人也知道，SQL Server 这种规模的项目怎么可能用敏捷，找死吗。

   回复

9. 返回顶部

   Re: 学习微软经验：超大规模的 SQL Server build 系统

   2008年9月19日 下午8时1分 发表人 isaac han

   大规模的项目用敏捷就是“找死”？怪哉～

   回复

10. 返回顶部

    仝键，你们为什么不用 Branch-Merge？

    2008年9月21日 上午8时23分 发表人 Charlie Zhang（张恂）

    
    仝键：另外，糖醋鼻子还提到了分支式开发，大家围绕这个还展开了激烈的讨论，不过我考虑到分支式开发对我们的利可能要远小于弊，最终还是放弃了这个方案。
    

    
    
    为什么 Branch-Merge 对你们会弊大于利，你没有说明。问题可能恰恰出在这里。
    
    
    
    
    

    
    刘春雨介绍了微软是如何解决这个问题的：
    
    
    
    
    我们每天做这么多的build正体现了我们如何支持整个SQL Server工程体系和构架：
    
    
    
    
    在SQL Server 2008的工程体系和构架中，我们将每个需要增加或增强的功能特性做成一个单独的分支，在这个功能特性开发和测试完成后，其代码才会合并到SQL Server的主线代码中 ... 每个分支都需要build来进行及时的测试，因此有了这个我们当前每周需要的build个数——130。当build结束后，Test Execution team和其分支团队会执行自动测试来确保其代码的质量符合严格的要求和标准。最后当这个功能特性开发和测试完成后，其代码将会融入到SQL Server的主线代码中，然后其它各个分支团队将重新获取主线代码并融合其分支的当前代码，来保证和主线代码的同步。
    
    
    
    
    相关数据：
    
    
    
    
    每个build 的大小在300GB左右。
    
    
    每个完整的build需要几十台高端的服务器运行2.5天。
    
    
    每个完整的build由几千个job、10000多个参数组成。
    
    
    我们每天同时做20个左右的build，每周130个。
    
    
    位于美国微软总部雷蒙德和北京的build团队能够保证build全天24小时不间断的顺利进行。
    
    
    从去年至今，我们build team已经成功而准时地完成了数以千计的build。
    

    
    
    
    
    很高兴看到刘春雨的这段介绍，它们和十年前张恂从《微软的秘密》中所学到的方法是一致的。这说明过去十多年来微软一直在沿用这套成熟的方法，它们当然是软件工程中的 Best Practice。正是受到微软经验的启发，张恂带领的研发团队早在 2000 年和 CMM 热之前就做到了软件配置管理和 Branch-Merge，领先于当时国内软件同行业的水平。
    
    
    
    
    你们的系统规模不可能比 SQL Server 更大吧？对于如此庞大系统的功能开发和质量保证，微软运用 Branch-Merge 显然是非常成功的。我觉得你们应该跳出“极限敏捷”和 CI 的圈子，试一试其他成熟的“敏捷”方法。
    
    
    
    
    中西合璧的敏捷 OO 教练
    
    
    www.zhangxun.com

    回复

11. 返回顶部

    系统过大，该考虑分解为几个应用了

    2008年9月21日 下午10时20分 发表人 Yongshi He

    可以把系统分解开，变成几个子工程，分别构建，只要协调好引用关系，分配好时间片，应该能把速度提高。

    回复

12. 返回顶部

    Re: 仝键，你们为什么不用 Branch-Merge？

    2008年9月22日 上午1时41分 发表人 jasson zou

    张敏捷又来做广告了！！！

    回复

13. 返回顶部

    怪了，这也算广告？？？

    2008年9月22日 上午5时9分 发表人 Charlie Zhang（张恂）

    2008年9月22日 上午1时41分 发表人 jasson zou：
    
    
    
    张敏捷又来做广告了！！！

    
    
    
    
    契合主题，张恂分享了自己的一些经验和成果，这也算广告？
    
    
    
    就算是广告（广而告之），张恂的每一篇文章、每一次评论都可以算广告，这有什么不对吗？InfoQ 英文版、中文版的每个页面上到处是广告，你没看见？
    
    
    
    没必要大惊小怪的。

    回复

14. 返回顶部

    Re: 怪了，这也算广告？？？

    2008年9月23日 上午7时49分 发表人 Jason Lai

    怎么不算广告？你这是隐性软广告，InfoQ 最不做的就是这类。没错这个页面是有广告，数量也不少，但也是别人掏钱或者合作做的。这样吧，你给 InfoQ 掏点广告费，价格合理的话，肯定会给你一个好的 package，如何？

    回复

15. 返回顶部

    Re: 怪了，这也算广告？？？

    2008年9月23日 下午8时42分 发表人 凉粉 小刀

    赞

    回复

16. 返回顶部

    选择更加适合自己团队的运作方式

    2008年9月23日 下午8时51分 发表人 Kent wei

    看了文章，感觉该作者最初犯了点教条主义的错误：无论现实如何，既然持续集成要集成，一定要每时每刻都集成。其实包括后来作者的理解和Jeff Xiong的认可，都是在错误认识的基础上做的错误判断。
    
    持续集成的基本的本意很简单，就是减少集成的成本，基本本质无非就是控制项目成本。所以采用什么集成方式，判断的唯一标准是成本（当然是指在某个质量底限下的成本）。
    手段无非有三，通过如下手段综合考虑：
    一、增加持续集成服务器投入;
    二、增加build 人手投入，大的team甚至可以由一个build master带领一个“分布式"的team;
    三、选定合理的集成周期,是real-time build 还是daily build;
    如果你的项目很大,销售额也大，build的时间长，意味着你要选择一和二是比较合理的,因为客户得罪不得。
    如果你的项目很大，build的时间长，销售额一般，则调整一和三比较合理，这些投入成本较好控制。
    如果你的项目大，build的时间长，销售额很少，那么唯一的选择恐怕就是daily build.（实质是牺牲一定的质量)。
    
    你的team情况看来，测试人员到位，build master也比较成熟，那么剩下就是看看项目销售额了：
    销售额大，客户比较重要，那么选择增加集成服务器投入；反之，则可以让unit test 实现real-time build， 验收测试实现daily build（每天晚上跑一次或者两次，根据你要支持的浏览器来定）.
    如果unit test都难以实现real-time build，说明结构设计上有些可以改进的,比如才用内存数据库服务器等等。
    如果依然无法实现real-time unit test build，那么都采用daily build吧。但是强制要求team提交代码之前一定要跑单个unit test和单个功能测试脚本。

    回复

17. 返回顶部

    Re: 选择更加适合自己团队的运作方式

    2008年9月23日 下午8时56分 发表人 Kent wei

    看了文章，感觉该作者最初犯了点教条主义的错误：无论现实如何，既然持续集成要集成，一定要每时每刻都集成。其实包括后来作者的理解和Jeff Xiong的认可，都是在错误认识的基础上做的错误判断。
    
    
    
    持续集成的基本的本意很简单，就是减少集成的成本，基本本质无非就是控制项目成本。所以采用什么集成方式，判断的唯一标准是成本（当然是指在某个质量底限下的成本）。
    
    
    
    手段无非有三，综合考虑：
    
    

18. 一、增加持续集成服务器投入;


19. 二、增加build 人手投入，大的team甚至可以由一个build master带领一个“分布式"的team;


20. 三、选定合理的集成周期,是real-time build 还是daily build;



如果你的项目很大,销售额也大，build的时间长，意味着你要选择一和二是比较合理的,因为客户得罪不得。


如果你的项目很大，build的时间长，销售额一般，则调整一和三比较合理，这些投入成本较好控制。


如果你的项目大，build的时间长，销售额很少，那么唯一的选择恐怕就是daily build.（实质是牺牲一定的质量)。



你的team情况看来，测试人员到位，build master也比较成熟，那么剩下就是看看项目销售额了：



21. 销售额大，客户比较重要，那么选择增加集成服务器投入；


22. 反之，则可以让unit test 实现real-time build， 验收测试实现daily build（每天晚上跑一次或者两次，根据你要支持的浏览器来定）.


23. 如果unit test都难以实现real-time build，说明结构设计上有些可以改进的,比如才用内存数据库服务器等等。


24. 如果依然无法实现real-time unit test build，那么都采用daily build吧。但是强制要求team提交代码之前一定要跑单个unit test和单个功能测试脚本。