信息系统项目管理：跌撞的持续系统集成之路(2)2

 另一个方案是从细节处调优，把WEB应用部署到另外一台机器上去，或许就会稳定一些了。但是反对的声音认为，以测试用例的这个增长速度，他早晚会不稳定的，而且可能撑不过两周。作为修正，想考虑分布式，但是我们所有人的知识储备中，并没有一个人清楚CC有没有分布式能力。所以想的是购买Cruise，但是价格的障碍就摆在眼前了，在项目前景还不是很明郎的情况下，估计很难申请到资金，但也不是不可能，只要我们敢于冒这个风险。

　　第三，便是更为高级的分支式开发，将版本库划分一下分支，以分支来搭配持续集成，以分支合并来触发自动构建。这样做，开发的过程就更加有板有眼，粒度可以划分的更细。可是分支的划分，一时想不清楚。但是假设想清楚了，似乎这也使得我们的工作流程更加复杂了，做如此之大的改变，风险有多大?效果有多大?成本有多大?到底是值不值得?一时也想不清楚。

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

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

　　JeffXiong觉得可义将测试分级，并将build分为两个环节，一个跑基本的用例，一个跑全部的用例。这跟我们的第一套方案的思路吻合。但是这种行为是不是失去了持续集成的意义呢?他也不是很确定，他说：我也不确定……不过，不全面的持续集成至少比不能用的持续集成要好。哪怕一个quickbuild(只?)能抓到80%(70%?60%?50%?)的defect，如果它只要很少的时间就能跑一遍，似乎值得这样做。

　　不过同时就需要(可能是与门的)人来关注slowbuild的健康状况，不然brokenfunctionaltests可能被忽视并累积。