大型复杂软件产品持续集成的实践与反思权衡

持续集成作为一种敏捷软件开发实践，已经被越来越多的开发者所接受。持续集成倡导开发团队频繁地进行系统集成通常一天一次到数次，每次集成都能被自动编译和测试验证，从而能在最短的时间内发现问题，缩短开发周期，提高软件质量。

笔者面对的是具有十多年开发维护历史，的5个相互依赖产品，每个产品均超过百万行代码的复杂系统。集成本身涉及很多烦琐的手工操作，很难实现过程自动化。在实施过程中，受困于软件系统的历史遗留问题，而通常市面上的持续集成工具又不能满足系统的需求，让我们不得不着手开发自己的集成系统。经过近一年的持续努力，终于完成了系统集成的自动化，将集成频度从数周甚至数月集成提高到日集成，大大提高了生产效率。

集成的困境

OSS系统是我们一个具有十多年生命历程的复杂系统，多年来一直处于不断的开发和维护中，子产品的数目和系统的代码量也随着时间日益增长，集成的周期、发布周期也随之逐渐增长。OSS系统包含有5个需要集成的产品：ComLIB 、DB-Com、Data Broker、DataGen、DataAgent，每个产品均有上百万行源代码和庞大的测试用例，产品可以单独构建，但运行时有相互依赖关系。OSS产品栈如图1所示，上层产品对下层产品具有依赖，部分产品栈亦可以组成一个应用系统，如DataGen+CommonLib可以组成一个应用系统，DataBroker+ DBCom+CommonLib也可以组成一个应用系统。

为进一步开展好环境保护的全民教育工作起到了积极的促进作用。同时 图1 OSS产品栈

同时，OSS的每个产品又包含不同的发布单元，用于运行于不同功能服务器上：Control Server、SITE、PAP、Workstation、Application Server和不同的操作系统环境中，产品在不同的服务器上安装单元如表1所示。

表1 OSS产品在不同服务器上的安装单元

传统手工集成需要完成如下事情：

1．从代码库取出产品栈中每个产品需要集成的代码；

2．在Build server上对每个产品进行编译，单元测试（每个产品编译需要2~3小时，单元测试需要4~5小时）；

3．在Package server上对编译好的产品进行打包（每个产品打包需要约1小时）；

4．在Lab中卸载旧的产品；

5．在不同的服务器上（Control Server、Site、Workstation、APP Server）安装产品中相应的产品的相应部件，需要按照产品依赖关系进行安装 （2~3小时）；

6．检查每个产品的每个部件在Lab环境中的安装情况，确认安装成功；

7．运行功能测试脚本做回归测试（10~12小时）；

8．检查测试结果（3小时）；

9．对系统进行卸载测试，检查卸载结果 （1~2小时）。

如果在此过程中，一旦遇到问题，则需要花费更长的时间。如此昂贵的集成代价使得OSS系统通常数周甚至更长的时间才艰难地进行一次集成。而自动化还要解决多产品、多平台、多种安装和运行环境、多个操作需要人工干预的难题。

集成目标

持续集成需与自动化结合才能发挥其威力，为给OSS系统瘦身，我们设定了如下自动化持续集成目标：

1．在集成服务器上配置cron job，每天晚上进行集成，第二天早上发布结果；

2．在集成服务器上配置集成方案，指定所需要的产品栈或子栈，指定所需产品的版本或分支，指定需要进行卸载、安装测试，功能测试的Lab以及Lab里的服务器；

3．只需修改少量参数配置，即可以实现不同的持续集成方案。