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

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

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

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

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

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

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