一、目前的情况
目前我们要进行持续集成的对象是一个有着100人左右的开发团队，他们开发着一套很庞大的系统。整个开发团队划分为多个开发小组进行协同开发，每个开发小组负责2-3个模块的开发，实际这里的模块已经相当于一个中小型系统。各模块所有的类都通过eclipse整体编译在一起，直接放置在WEB-INF/classes下。本地是无法启动整个系统的，需要耗费大量的资源。

二、碰到的问题
在了解具体情况之前，我们最初的想法是为整个产品做一个持续集成，但是很快就发现这一想法存在很多的问题：
1、整个产品每次构建的时间会很长，这个时间包括代码的编译、启动Weblogic，完成自动化测试，同时对服务器的硬件要求非常高
2、因为构建时间长，所以如果本地构建通过后再提交会严重影响开发效率，况且本地的硬件条件很可能启动不了
3、如果本地不构建提交，则由于开发人数众多，构建会非常不稳定，会经常处于失败状态。而构建失败会导致后续提交的阻塞。
4、作为一个100人的开发团队，代码提交会引发频繁的服务器构建，服务器无法负担。

同时作为客户，他们有这样一种想法：敏捷开发是好的，但是不适合于大的项目和大的团队。

最重要的问题集中在两个方面：
1、启动整个产品过于重量级（不包括自动化测试的情况下已经如此）
2、如何不影响开发人员的频繁提交

三、我们的想法
我们现在的想法是做多阶段的持续集成（multi-stage CI）

可以参考这里http://www.ddj.com/development-tools/212201506

具体而言：
1、各个开发小组内做小组内的持续集成
2、开发小组间集成做整个产品的持续集成


大概：
1、每个开发小组一个分支，整个产品一条主线
2、在小组分支上搭建持续集成环境，小组内的开发向该分支上提交，各个小组可以并发开发，互不影响
3、小组完成一个完整的功能后，从主线更新合并代码，本地构建通过，提交，触发整个产品的持续集成

为使小组内持续集成构建加快，小组内尽量划分清楚对其他模块的依赖，不必要的模块（这里的模块包括基础模块，例如工作流模块）不必加载。
同时推荐轻量级的web服务器例如Tomcat来完成小组内的测试环境。需要启动weblogic的情况或功能依赖过多的情况下，建议在产品持续集成时进行测试。
同时保留原有的启动单独测试服务器进行手工测试的习惯。


http://www.blogjava.net/ronghao 荣浩原创，转载请注明出处：）