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

 　那个时候，build一次大概是15分钟，因为Check In Gate环节是按照标准流程走的，所以build出错的几率也小。CC大多数时候是绿的。哪怕偶尔出问题红了，也很快被修正了。

　　随着项目的开发，代码规模越来越庞大。功能测试越来越慢，比起自动执行脚本那种速度，开发人员更乐意手动点两下，加之上面对工作进度的压力。更改了一些工作方式：后台的工作方式不变。

　　前台，将功能测试脚本的工作交给几个测试人员编写。几个测试人员也坐在附近，基本可以看作团队成员(到后来编制也是我们团队的成员了)。开发人员人肉测试一下保证没有问题了再提交。

　　测试人员写脚本的流程是拿到上一次build成功的war包，在本地写脚本，本地测通过了再提交。

　　持续集成服务器上功能测试不通过的时候，由测试人员提交BUG，开发人员修改。持续集成的流程依旧。

　　这样，从后来收集的数据看，工作效率是提升了，因为参照以前的统计，开发人员的工作一下减轻了1/3。以进度来衡量的速度自然很轻易就可以让上级满意了。

　　新的解决方案总会产生新的问题，测试人员在测试方面的专业性，使得他们写出来的脚本测的更细。功能测试的时间占耗，增长的更快了，短短半个月，就增长到了1个小时。每当出现问题，作出反应之后，要在1个多小时以后才能知道结果。而且，持续集成方面并没有做到，一旦出错，谁也不能提交代码这么严格。模块化的设计所带来的假想的安全感和进度的压力，使得开发人员修正问题的激励不高。于是修正问题的速度不如产生问题的速度快。持续集成服务器在那两个个礼拜里只有两头是绿的，周一早晨和周五下午。