一种软件持续集成平台的技术方案
一种软件持续集成平台的技术方案
陈挺，阮波，林加旗
浙江中控技术股份有限公司，浙江杭州，310053
摘要：本文介绍了浙江中控技术股份有限公司在敏捷软件开发过程中使用的一种软件持续集成平台的技术方案。该方案利用开源软件Huds on和SVN构建平台，在改进软件质量和降低风险，缩短缺陷引入、发现和修复之间的时间间隔方面取得了显著效果。
关键词：持续集成，软件项目，浙江中控，敏捷
A Technical Proposal for Continuous Integration Platform
Chen Ting, Ruan Bo, Lin Jiaqi
Zhejiang SUPCON Co., Ltd., Hangzhou, Zhejiang, 310053
Abstract: The paper introduces a technical proposal for continuous integration platform used in the agile software development of Zhejiang Supcon Technology Co.,Ltd. This proposal, which creats the platform with Hudson and SVN software, improves software quality, reduces development risk, and shortens the time interval for bug introducing, finding and repair. Keywords: Continuous Integration, Software Project, SUPCON, Agile
.
1.引言
持续集成（Continuous Integration，简称CI）是敏捷软件开发中的一种非常重要的实践。持续集成对软件质量改进和风险降低有着非常重要的作用，因此，它也是所有敏捷实践中推行最为成功和广泛的一种。持续集成的核心价值是缩短缺陷的引入、发现和修复之间的时间间隔。本文介绍一种搭建持续集成平台的技术方案，并以在浙江中控技术股份有限公司的软件研发活动实际运行的情况为例介绍其效果。
2.持续集成概述
所谓“集成”，是软件行业的一个专门术语，是指把一些能够单独工作的模块组装在一起构成一个系统的过程。这个过程往往是软件项目中非常棘手的工作，集成后的系统往往不
可用，并且很难找到失败的原因。为有效解决这个问题，很多学者提出应该更早且更频繁地进行集成，于是一种叫做持续集成的技术应运而生。
持续集成的关键是快速和不断重复。一个持续集成平台应具备如下四种基本特征：①与版本控制系统的连接；②构建脚本；③某种类型的反馈机制；④集成源代码变更的过程。持续集成是一个不断循环的过程，一个循环的内部流程描述如下：首先是开发人员编写代码，经过适当的审查后，向版本控制库提交代码变更；持续集成服务器周期性地对版本控制库进行轮询，一旦发现有新的变更提交，就从版本控制库获取更新，进行代码审查和产品集成构建，并把构建好的内容进行发布、部署以及自动化测试；代码审查和测试的结果通过某种形式向开发人员反馈，开发人员可以查看自己之前的工作成果是否存在问题，以便快速解决。下图显示了持续集成系统的基本构成。 版本控制库
CI 服务器集成构建计算机开发者提交变更
轮询生成
查看反馈机制
构建脚本：编译源代码集成数据库执行测试执行审查部署软件
图 1 持续集成系统的基本构成
作者在浙江中控技术股份有限公司从事软件研发工作期间，与团队一起经过反复地论证和设计，并通过多个项目的实践，最终完成了适合中控软件研发实际的持续集成平台的技术方案，并取得了不错的效果。后续章节将根据持续集成系统的基本结构展开对这个方案的论述。
3. 技术路线选择
持续集成平台的方案，我们选择开源的Hudson 作为基础平台软件。Hudson 是一个可扩展的持续集成引擎，能够持续、自动地构建和测试软件项目，并监控一些定时执行的任务；具有易用性高、易配置、WEB 化、支持多种插件、分布式管理等特点。版本控制库是持续集成平台中的重要一环，我们采用SVN 软件作为版本控制库的平台软件。SVN 提供命令行管理接口以及Web 管理接口Submin ，可以非常方便地与Hudson 进行对接。通过Hudson 的轮询机制调用SVN 的管理接口，可以实现对代码变更提交的周期性监控。Hudson 平台支持Ant
脚本语言，Ant脚本可以用于实现灵活的构建过程。
4.构建过程设计
持续集成的一个完整过程，称为一次构建，在实践中用Ant脚本语言实现。一个完整的构建过程，是一个非常复杂的过程。在我们的实践中，对于一个大型复杂软件而言，如果要执行完一个完整的构建过程，需要大约4小时左右的时间。4小时的周期，对于日常的开发而言太长，对问题的反馈效率明显不足，因此，我们需要根据实际的情况对构建的过程进行分类。构建类型分为三种，分别为：私有构建、集成构建和发布构建。其中集成构建又分为提交构建和次级构建。提交构建是最快速的构建，只应包含编译和单元测试，日常开发过程中，主要依靠“提交构建”来实现快速反馈的机制。次级构建，与提交构建相比执行较多的测试，包含组件集成测试、系统测试、性能测试等，并且还需要执行自动代码审查，其运行的周期也比较长。发布构建比次级构建执行更多的内容，包括：创建安装媒质，部署软件，执行全面的测试（性能测试、负载测试、验收测试等等，包括手工测试）。
构建触发机制分为四种：①用户驱动；②定期执行；③轮询变更；④事件驱动。用户驱动是指，用户根据实际需要手工启动一次构建，一般发布构建会由用户驱动；定期执行是指设定固定的周期来执行构建，一般用于进行“日构建”；轮询变更方式则是由代码提交变更驱动的构建，代码没有变化就不会执行。表1中显示了每种构建类型与触发机制的关系。
表1 构建类型及触发机制设计
构建类型构建触发机制
私有构建*用户驱动
集成构建之提交构建用户驱动、*轮询变更
集成构建之次级构建用户驱动、*定期执行（一般为每天）、事件驱动
*用户驱动、*定期执行（根据项目周期，一般可每发布构建
周或半月）
注：标“*”符号的为主要采用的触发机制。
构建脚本的基本行为包括如下过程：
①编译源代码：从版本控制库获取代码副本，进行编译。这个步骤还应该包括安装脚本的编译，也就是说持续集成平台可以帮助开发团队自动生成安装包，而不仅仅是编译出二进制文件而已。需要注意的是，在编译之前需要先进行环境清理，以消除上一次构建对本次构建产生的影响。
②执行测试：这里的测试指的是自动化的测试，包含单元测试、组件（集成）测试、系统测试、功能（验收）测试。真正意义上的单元测试是不涉及数据和其他依赖关系的快速测试，一般是“提交构建”时唯一执行的测试。而其他类型的测试，相比单元测试会更多地依赖环境，需要完整地部署软件才能确保自动执行测试。测试执行过程中发现的问题应录入缺陷库，中控使用HP Quality Center平台，该平台提供缺陷录入的API接口，可以方便地实现自动缺陷录入。
③执行代码审查：代码动静态测试，代码规范审查，可利用C++Test等工具进行，通过收集和分析数据得到代码质量的评估结果。例如：可利用SourceMoniter等工具进行代码复杂度评估。一般而言，复杂度大于10的函数属于高风险。复杂度与测试用例数之间有一个经验公式，就是一个函数的测试用例数（检查点）应该至少与复杂度相等，这是检验测试充分性的一个视角。配合SVN版本管理库，我们可以使用StatSVN工具来实现代码修改量的自动统计。
④部署软件：把软件部署到测试所用的计算机上，持续集成的平台应该具备为多台计算机自动部署软件的能力。对于大型C/S模式的软件而言，在软件部署环节会需要以来大量的计算机构成的计算机平台，这个平台必须被持续集成环境长期占用，不能挪作其他用途。但是其实单纯的在持续集成环境，计算机本身的计算能力大部分时候是闲置的，因此，我们建议在这个环节采用虚拟化方案以节约固定资产投入。
5.结束语
持续集成作为敏捷软件开发的典型实践之一，应用已经非常广泛，但是具体的技术方案并没有统一的标准，各个企业可以根据自身的实际情况进行设计和实施。本文介绍了一种构建持续集成平台的设计方案，该方案经济实用，实施简便，应用效果良好。在中控ECS-700系统监控软件开发的过程，依靠持续集成平台，使开发过程中重大缺陷从产生到消除的平均时间，从原来的23天缩短到了8天时间，主要原因在于缺陷从产生到被发现的过程时间大大缩短了。持续集成平台对中控提升软件开发效率，及早发现产品问题，保障软件产品质量起到了重要作用。
参考文献
[1]Paul M. Duvall. 持续集成——软件质量改进和风险降低之道. 机械工业出版社, 2007
[2]吴志福. 基于持续集成环境的软件过程管理: 福建电脑, 2011,27(5):85-86
[3]刘巧玲,范冰冰,黄兴平. 基于Hudson的持续集成研究和应用: 计算机系统应用. 2010,12:151-154