持续集成也需要重构持续集成实践在cru

《持续集成也需要重构持续集成实践在cru》由会员上传分享，免费在线阅读，更多相关内容在应用文档-天天文库。

1、持续集成也需要重构持续集成实践在Cruise阅读：87评论：0作者：iTech发表于2010-05-2816：04原文链接转自：1前言持续集成是极限编程十二实践之一(1999年KentBeck编写的《解析极限编程》)，最初被使用极限编程方法的开发人员所推捧，并在过去的几年中得到广泛应用，成为业界广为人知的软件开发实践。该实践用于解决软件开发过程中一个具体且重要的问题，即"确保当某个开发人员完成新的功能或修改代码后，整个软件仍旧能正常工作。"然而，持续集成并非像大多数人想像的那样，首次部署好持续集成环境后就大功告成，一劳永逸了。恰恰相反，它与你项目

2、中的其它产品代码一样，需要改进与重构，否则，就会使你进入一种"持续闹心"的状态，甚至可能让你觉得这件事根本不应该做，如何解决这一问题呢?对"持续集成"应用"Retrospective"和"重构"。本文将结合Cruise团队一年多的实际历程，讲述持续集成实践在软件开发过程中的演进。友情提示：请读者在阅读本文时，注重文中所述的思考过程与"持续集成"的重构方式，而非产品本身。2基本持续集成--万里长征第一步实际问题：我们需要一个持续集成环境为什么要做持续集成不在本文讨论之内。理论基础持续集成基于这样一个假设：如果两次代码集成的间隔时间越长，最终集成时痛

3、苦的经历就会越多。而其目标有两个：一是"频繁集成"，二是"反映代码质量"。为了做到"频繁集成"，就要求任何开发人员在每次向中央代码库提交代码时，就将所有代码进行编译，打包，部署，以确保能够产生交付物。然而，"频繁集成"仅仅证明了每次提交是否可以得到交付物，而我们真正需要知道的是"这个交付物的质量如何"。如果交付物有问题，引起问题的代码则要么被回滚，要么被修正。当然，这样的任务也可以通过手工来完成，但手工工作的特点就是易出错且耗时，所以需要将其自动化。为了做好"持续集成实践"，写一个自动化构建脚本来自动构建并运行一些自动化测试套件还是必要的。这种传

4、统的持续集成方式常被固化于开发环节，即：开发人员安装一个专门的持续集成服务器来自动化运行这些单元测试，然后通过各种各样自动生成的测试结果分析代码的质量，这也是CruiseControl诞生的原因。解决方案最初，我们的代码并不多，自动化脚本比较简单，在一台机器上运行所有的测试也仅需要几分钟，该构建套件的运行顺序是：CheckStyle-Compile-UnitTest-FunctionTest-Report。示意如下：projectname="Cruise"default="all"basedir="."targetname="all"depend

5、s="checkStyle,Compile,UnitTest,FunctionTest,Report"/targetname="checkStyle"./targettargetname="Compile"./targettargetname="UnitTest"depends="Compile"./targettargetname="FunctionTest"depends="Compile"./targettargetname="Report"depends="FunctionTest"./target/project这也是大部分软件团队进行

6、持续集成的起点。目前，有很多种持续集成工具，其中不乏开源产品，如CruiseControl家族。项目伊始，我们使用CruiseControl建立了自己的持续集成服务器，整个项目的持续集成基础结构如图所示：图1基础持续集成模式注：得到快速反馈是开发好产品的关键。因此，我们自己就做了Cruise的第一个用户，首先解决自己的持续集成需求。项目开始后仅几周，我们的产品Cruise已经基本满足自身团队持续集成的需求，因此，我们就将CruiseControl替换成Cruise，但持续集成基本结构并没有变化。3阶段化持续集成--平衡的艺术实际问题：测试越来越慢

7、，开发人员等得不耐烦。随着时间的推移，Cruise每次做持续集成的运行时间很快就超过了15分钟(开发人员能够忍受的最大限度)。然而，为了保证Cruise支持大多数浏览器，我们还打算增加Cruise运行于不同操作系统及不同浏览器的功能测试。理论基础一般来说，测试代码越多，越能够正确反映代码的质量[前提：你写的测试是有意义的：)]。所以在整个生命周期中，大家都试图增加更多的测试代码。然而，越多的测试代码也意味着更长的运行时间，更慢的反馈速度。因此，我们不得不在"反馈时间"与"判断质量准确性"两者之间找到一种平衡，而"阶段化持续集成"就有了用武之地。所

8、谓的"阶段化持续集成"是指为不同的构建测试套件(以下称构建计划)建立不同的持续集成循环周期，由于单元测试运行时间短，反馈较快，所以可以频