阶段化持续集成 —— 平衡的艺术

　　实际问题：测试越来越慢，开发人员等得不耐烦。

　　随着时间的推移，Cruise每次做持续集成的运行时间很快就超过了15分钟(开发人员能够忍受的最大限度)。然而，为了保证Cruise支持大多数浏览器，我们还打算增加Cruise运行于不同操作系统及不同浏览器的功能测试。

　　理论基础

　　一般来说，测试代码越多，越能够正确反映代码的质量[前提：你写的测试是有意义的:)]。所以在整个生命周期中，大家都试图增加更多的测试代码。然而，越多的测试代码也意味着更长的运行时间，更慢的反馈速度。因此，我们不得不在“反馈时间”与“判断质量准确性”两者之间找到一种平衡，而“阶段化持续集成” 就有了用武之地。

　　所谓的“阶段化持续集成”是指为不同的构建测试套件(以下称构建计划)建立不同的持续集成循环周期，由于单元测试运行时间短，反馈较快，所以可以频繁进行，而功能测试、性能测试的时间比较长，占用资源比较多，比较昂贵，所以适当减少集成次数，但一定要保证其周期性运行。因此，我们的持续集成方案很自然地分成了多个构建计划：快速构建计划让开发人员尽可能快地得到反馈，此时我们牺牲了准确性来换取时间。但当你得到了快速反馈以后，再花多一点儿时间从其它构建计划中得到更详细的反馈。这样一来，对于同一个项目，你有多个构建计划，每个对应一种构建类型(单元测试，功能测试、功能测试等)，越靠后的构建计划在运行时需要的时间就越长。如下图，

　　单元测试构建计划运行了多次， U1,U2...U7，其中U4失败了。功能测试构建计划时间较长，在该时间段内仅运行两次，F1和F2(失败)，而性能测试构建计划P1时间最长。整个持续集成系统由多个机器组成，包括一个中心服务器(Server)和多台工作站(Agent)，每个构建计划都在一台工作站(agent)独立执行，以便无相互影响。

　　图2 阶段式并行构建图解