“天下事头绪纠缠，兴一利必也生一弊。”

一句许，道破了改进难点所在。最迉在项目中围绕持续集成做改进的时候，对这一点感受颇深。跌跌撞撞的一路走来。我们的持续集成的过程已经变得有些“个性化”，反过头来看我们一路的变化，非常有意思。

从项目的技术架构说起，我们的项目是采用的J2EE+Flex的方式进行开发的。在我进入项目组的时候，一个比较健壮的持续集成环境已经搭好了。工程分为两个，一个是Java后端的工程，一个是Flex前端的。我们的持续集成朋务器是CC。整个开发工作是围绕着持续集成展开的。一周为一个迭代。

那个时候，我们采用的是比较标准的方式：

后台采取TDD的方式开发。

每次提交今码之前更新所有代码，然后运行所有测试用例，全部为绿色的时候才提交。

前台Flex比较麻烦，所以采取了用功能测讷覆盖单元测讷的方式。用基于Ruby的FunFx写单元测讷。工作方式与后台差不多，每次前台功能测试全部通过了才提交。

持续集成的流程是每隔5分钟检测一边代码库，有更新就build。

build的流程是先编译后台，跑单元测试，单元测试通过了，再编译Flex，将swf和html以及后台的文件打成war包，部署到tomcat上去，跑功能测讷。

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

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

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

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

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

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

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