解决方案
由于Cruise本身已经支持这种持续集成模式，所以我们的持续集成基本框架也演变成下图：
图3 阶段式持续集成模式图解
中心服务器(Server)的责任是(1)检查中央代码库的代码是否发生变化，(2)如果代码发生了变化，将相应的构建类型分配到各自的工作站(Agent)上运行;(3)中心仓库，保存所有信息。上图中，单元测试(Unit Test)构建类型运行于工作站Agent1上，每次执行需要15分钟左右，而功能测试(Function Test)构建类型分别运行于三个工作站(Agent2,Agent3和Agent4)上，每次执行约30分钟(其中Agent1为Debian操作系统，Agent2是Ubuntu8.04操作系统，安装有Firefox2.0，Agent3是WindowXP+IE6，而Agent4是 Windows 2003 + IE7)。
细心的读者会发现，中央代码库从Subversion变成了Mercurial，我的同事胡凯在《为什么我们要放弃Subversion》一文中讲述了缘由，其根本收益就是提高了Cruise生产效率。构建计划：是根据功能划分的自动构建循环周期，由一系列的步骤组成。下图为三种不同的构建计划：
图4 不同类型的构建计划
利弊分析
益处：暂时解决反馈时间长的问题。
缺点：仍存在浪费，提交频繁时，问题定位有时较困难。
在执行每个构建计划前，都需要从中央服务器上检出代码。不同的构建计划中，有很多步骤都是重复的，例如图4所示的编译与打包工作。当代码库比较小时，这并不是一个大问题。然而，对于此时的Cruise来说，就已经是“浪费”了。在图2中，单元测试U4已经以失败而告终，可功能测试还是在另外三台工作站(Agent)上运行着，一直占用着机器，直至结束。想像一下，如果构建计划的数量多于工作站(Agent)的个数时，这种资源的浪费又是多么严重呢?
另外，如图2所示，由于单元测试运行较快，所以功能测试F2中包含多个单元测试(U2,U3,U4)所覆盖的代码变化。如果F2失败，很难判断是哪次Checkin使F2失败的，因为前面已经成功结束的U2和U3也可能使F2失败。
