管道式持续集成——企业级持续集成的解决方案

　　实际问题

　　阶段化持续集成重复任务多，而过程化集成的管理复杂性太高了，任何过程化上的变化都要修改已经写好的脚本，而这些脚本维护比较困难。既然以上两种模式都不灵了，那就再想别的办法吧。

　　理论基础

　　管道式持续集成形式上与过程化持续集成相类似，但却在概念上有显著不同。在管道式持续集成中，所有的过程单元都运行在同一管道的上下文中，即各单元所使用的原材料都是完成相同的，即代码基线相同。当持续集成服务器发现有新的代码时，会创建新的一个管道，所有的过程单元都在这一个管道中运行。而每个单元产生的产物也在该管道中有效。如图所示：

　　图6 管道化持续集成

　　利弊分析

　　管道式持续集成综合了阶段化与过程化的优点，而带来的复杂性却不用你操心，因为Cruise为你管理这一切。

　　也就是说，你很容易就掌握，哪些产品代码是在哪个管道中生成的，是由哪些原材料(源代码)生成的，而与其它管道产生的产品代码有什么不同。在管道式中，每次构建都会试图从管道的一端走到另一端。因此，你不会遗漏任何一个版本的成功产品代码。

　　解决方案

　　Cruise持续集成类似于下面的持续集成构建管道：

　　<pipeline name="Cruise">
     <stage name="UnitTest">
         <job name = "windows">
 <artifacts>
               <artifact src="testreport"  dest="report"/>
               <artifact src="pkg"  dest="package"/>
            </artifacts>
            <tasks>
               <ant />
            </tasks>
         </job>
         <job name="linux"/>
     </stage>
     <stage name="FuncTest">
         <job name = "windows"/>
         <job name="linux"/>
     </stage>
     <stage name="TwistTest">
         <job name = "windows"/>
         <job name="linux"/>
     </stage>
     <stage name="Package">
         <job name = "Solaris"/>
         <job name="linux"/>
     </stage>
 </pipeline>

　　如图7所示，最后一次构建版本(1.2.128)从管道的一头成功走到了另一头，正在进行最后一步(部署到生产环境，黄色方块代表正在运行)，版本 1.2.127失败于打包交付物，虽然我们让版本1.2.126走到了管道的尽头，但您可能注意到这是一个有暇疵的版本(Package有点问题)，而且被很快在1.2.128中修复了。而其它版本都有问题而未能走到管道的尽头。

　　图7 构建管道图解