最早，我们发觉，由开发人员重构造成的脚本失败占大多数，而测试人员每次拿到的上一个版本是没有错误的。所以会出现自动化脚本本地跑得过，服务器上跑不开的情况发生。二是我们修改了发布的逻辑，在后台单元测试通过、flash编译完成的情况下打的那个war包，复制一份，放到某待定目录指定为currentbuild。供测试人员写测脚本使用。

过程改进之后，测试人员可以快速的修正脚本了，虽然对于开发人员重构造成测试人员工作的返工无疑是一种浪费，但是毕竟自动化的测试省了回归测试的不少时间，还是可以接受。

脚本的修正速度解决之后，工作似乎有了些起色，但很快，问题的本质就暴露了出来build的时间太长了，修得速度还是跟不上问题产生的速度。尤其是中间缺少当build失败时强制阻止代码提交的环节。这之后依然是周一和周五两头绿，中间都是红的。于是，我们觉得问题还是出在build速度上。我们人工的将功能测试脚本分到四个suite里去，然后以多线程的方式进行。速度被提高了4倍。于是又消停了两天。

好景不长，多线程的测试似乎不太稳定。很多本地可以跑通的测试用例，到了服务器上就失败。险些一个礼拜都没有build出一个版本。最后不得不改回单线程。这时，build一次已经占到了100分钟。第一期的产品Backlog还没有完成1/3。

持续集成走到这里已经进入一个困境，有必要做一些更深一步的改进。经过多次讨论，归纳出了几套方案：

分冒烟测试和all test两套测试用例集是我们当中呼声最高的一种方案，当我的代码提交之后在跑完所有单元测试和基本的冒烟测试之后就发布beta版，由测试人员接到beta版，进行更细致的自动化测试并带一些人肉测试。但是反对的声音认为，不跑完全部的测试用例就失去了持续集成的意义。而且会更降低开发人员修正Bug的积极性。于是作为修正，支持的声音则提出，在Check-InGate处把关，恢复每个人提交代码之前跑测试用例的实践。可这明显会给开发人员带来更大的工作负担，估计以此时的进度压力，开发人员的安全感肯定会大幅下降。很可能会推行不下去。

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

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

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

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

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