基于SVN的应用软件持续集成
2016-11-17刘立康
姜 文，刘立康
(西安电子科技大学 通信工程学院，西安 710071)
基于SVN的应用软件持续集成
姜 文，刘立康
(西安电子科技大学 通信工程学院，西安 710071)
随着软件开发技术的发展，软件配置管理和持续集成已经成为软件开发过程中的一个重要组成部分；为了在软件开发过程中正确应用这些新技术，需要开展这方面的研究工作；结合工作实践，以SVN作为配置管理工具，分析了持续集成工具ICP-CI的特点、部署方式和运行机制；详细叙述了ICP-CI持续集成构建工程的搭建过程，搭建过程包括配置管理工具SVN客户端安装、基于SVN的代码更新、静态检查、编译、打包，版本包的自动化测试；构建工程的各个阶段都可能出现错误，导致构建失败，通过对构建失败原因的分析，将构建失败分为3类并给出相应的解决方案；最后介绍了一个典型工作案例；工作实践表明在软件的开发过程中采用基于SVN的持续集成，可以提高软件质量和软件开发效率，降低软件开发成本。
持续集成；ICP-CI；ICP-CI服务器；构建；SVN
0 引言
随着软件开发技术的不断发展，软件持续集成[1-5](continuous integration)和配置管理[6-8]已经成为软件开发过程中的一个重要组成部分。目前国内比较常用的软件配置管理的工具有ClearCase、SVN、 Git等。ClearCase适合大型软件团队使用。SVN是开源软件，适合中小型软件团队使用。Git是一种新的分布式开源软件，具有很好的应用前景。持续集成技术已经由最初实现简单的软件编译验证，发展到目前可以进行软件源代码代码质量监控与管理、软件版本出包、软件版本集成验证等各个方面。
本文以SVN作为配置管理工具，持续集成工具ICP-CI为例介绍持续集成技术。分析了持续集成工具ICP-CI的特点，部署方式和运行机制。详细叙述了ICP-CI持续集成构建工程的搭建过程。最后介绍了一个典型工作案例。
1 持续集成系统架构
持续集成包括以下基本要素：开发人员、配置库、集成构建系统(ICP-CI服务器)和反馈机制。ICP-CI服务器提供了针对SVN的接口。持续集成步骤如下：
1)开发人员向SVN配置库提交代码。
2)锁库后，下载代码到ICP-CI服务器完成构建工作。若构建成功，提供新的代码版本。
3)ICP-CI服务器通过电子邮件向项目经理和开发人员反馈构建信息。
4)ICP-CI服务器轮询配置库中的变更。
2 ICP-CI服务器部署与运行原理
2.1 ICP-CI服务器的部署
根据开发项目的代码规模、编译环境、编译工具来选择ICP-CI服务器的CPU、内存等硬件配置和操作系统。一套ICP-CI服务器很可能同时承担多个软件产品版本的持续集成工作。
ICP-CI服务器系统有两种常见的部署形式[9-11]单机式和主控式。
单机式是指整套ICP-CI服务器系统由一台服务器组成，该服务器自主完成持续集成任务，这种系统适用于代码量小于一百万行的开发团队。
主控式是指整套ICP-CI服务器系统由一台主控服务器和多台代理服务器组成，主控服务器根据代理服务器的工作标签，将持续集成任务下发到各个代理服务器上，任务完成之后将任务结果和日志文件发回到主控服务器。
根据编译环境的不同持续集成工具ICP-CI分为不同的版本。在Windows环境下，主控服务器部署工具为ICP-CI-Windows-Master，代理服务器部署ICP-CI-Windows-Agent。在Linux环境下主控服务器部署工具为ICP-CI-Linux-Master，代理服务器部署ICP-CI-Linux-Agent。持续集成工具ICP-CI是跨平台的，主控服务器和代理服务器可以选择不同的操作系统。多数情况主控服务器选择安装Windows操作系统的环境。
ICP-CI工具需要解压安装包之后安装。主控服务器安装ICP-CI-Windows-Master之后，需要进入ICP-CI-Windows-Master下的master目录，执行批处理启动MYSQL数据库后，启动ICP-CI的网页版页面。对于ICP-CI-Windows-Agent和ICP-CI-Linux-Agent将安装包解压之后，需要将安装ICP-CI-Windows-Master的服务器IP地址配置到agent文件夹下conf文件夹对应的配置文件中，再执行批处理脚本启动代理服务器的CI进程。
2.2 ICP-CI运行原理
2.2.1 单机式运行机制
单机式运行比较简单，当构建工程运行时构建任务在本机运行，运行完成后，将构建任务的日志收集到ICP-CI-Windows-Master软件的日志路径下。
2.2.2 主控式运行机制
目前主控式的构建环境用的比较多。在主控式的构建环境中，主控服务器与代理服务器的运行机制如下图1所示。
图1 主控式持续集成环境的运行机制
在主控式持续集成系统中，主控服务器下发构建任务给代理服务器，监控与管理代理服务器的构建任务运行情况，在ICP-CI工具的页面上显示任务运行情况，同时发送邮件给特定邮件群组。
代理服务器接受主控服务器下发的构建任务，完成构建任务之后将构建日志与运行结果反馈回主控服务器。
3 ICP-CI构建工程搭建
3.1 从SVN客户端下载代码
ICP-CI服务器通常需要安装SVN命令行工具和图形SVN客户端工具。对于Windows操作系统在安装完成命令行工具和图形客户端工具之后，可以选择安装支持中文操作的软件包，以便支持中文操作。
完成SVN工具的安装之后，根据配置管理工程师提供的产品代码配置库路径，使用SVN客户端工具的“SVN检出(check out)”功能从配置库下载代码到代理服务器的指定路径下。
3.2 搭建构建工程
打开ICP-CI的网页页面，持续集成工程师在ICP-CI的页面上创建以“软件产品名称+版本号”为名称的构建工程。构建工程创建成功之后，编写各类任务脚本，分别配置代码更新、静态检查、进程编译、出包、自动化用例测试等步骤。
3.2.1 基于SNV的代码更新
每天在配置库开库到锁库的时间段开发工程师提交代码到配置库中。SVN配置库锁库后，持续集成工程师在搭建持续集成构建工程时，调用SVN的“update”命令实现将软件产品配置库的代码更新代理服务器上的代码视图。
使用ICP-CI创建代码视图的创建更新任务时，需要撰写代码更新的批处理脚本(Linux环境需要撰写Shell脚本)，把代码更新的脚本配置在任务中。更新代码的批处理脚本内容如下所示：
::配置需要更新代码的视图路径
SET CODE_PATH=D:/CodeView /Code
::解除代码视图中的文件锁定
svn cleanup %CODE_PATH%
::更新代码到视图路径
svn update %CODE_PATH% --accept postpone
3.2.2 静态检查
静态检查[12]方法包括两类，一种是通过常规的人工代码检视来发现问题，另外一种是使用静态检查软件进行代码静态检查。
常规的人工代码检视，能发现少量的内存越界和资源泄漏问题，依赖于参与检查人员的技术水平和当时的精神状态。人工检查方法进行内存越界和泄漏检查效率比较低，成本较高，虽然可能发现一些深层次的代码缺陷，往往不如静态检查软件检查发现代码缺陷的效率高。
静态检查是指使用自动化工具对程序源代码进行检查，以分析产品源代码行为的技术，应用于源代码的正确性检查、安全缺陷检测、代码优化等。它的特点是不需要执行程序。
软件产品使用C/C++来编码时，采用的静态检查工具为Pclint；Pclint是C/C++代码静态检查工具，支持几乎所有流行的编辑环境和编译器。当软件产品代码使用java语言，通常采用Findbugs和Checkstyle作为静态检查工具。本文以由Pclint工具为例描述静态检查的配置过程。Pclint工具主要由以下这些文件组成，如下表1所示。
ICP-CI工具运行Pclint时，需要持续集成工程师根据产品各编译模块名称来命名几类*.lnt文件。需要配置的*.lnt文件类型如表2所示。
表1 Pclint工具的文件组成
表2 产品模块需要配置的*.lnt文件类型
产品各模块进行pclin检查t时，需要在include_模块名.lnt文件中包含各模块需要被编译的源代码的路径。include_模块名.lnt文件配置内容如下所示：
-ID:INCWIN32
-ID:INCLINUX
-ID:INCLINUX
-I%PROJECT_PATH%host
持续集成工程师在构建工程的ICP-CI的任务页面上，创建产品代码的pclint任务时把调用“std_模块名.lnt”配置在任务中。构建工程在执行时，参于运行pclint任务的代理服务器使用pclint工具检查软件产品C/C++代码的各种缺陷。
3.2.3 编译
产品代码在编译过程中为出包步骤生成进程文件，也可以查找各种编译错误与编译告警。各模块的编译脚本路径、编译脚本与编译器需要在构建工程的ICP-CI的任务页面上完成配置。
当产品的进程文件需要在Linux操作系统下完成编译链接，需要在ICP-CI-Linux-Agent代理服务器上安装编译器gcc-4.3.4，安装步骤如下所示：
a.将gcc的安装包拷贝到代理服务器opt目录下，执行tar xzvf gcc_install.tar.gz
b.进入解压之后的gcc_install目录
c.执行rpm -ivh *.rpm
d.将/opt/gcc_install/make拷贝到/usr/bin下
e.执行./ipsec.sh，开始安装gcc-4.3.4。
gcc编译器安装完成之后，在代理服务器上执行：“gcc -v”，如果可以查看到gcc版本的版本号则表明gcc编译器安装成功了。
以dbg模块为例，在构建工程的ICP-CI的任务管理页面配置编译模块名称dbg，分别配置dbg模块的编译任务，并将dbg模块的编译脚本make_std_dbg.sh以及dbg模块编译脚本路径配置到编译任务中。make_std_dbg.sh编译脚本内容如下所示：
CUR_SH_PATH=’pwd’
CODE_ROOT_PATH={CUR_SH_PATH}/../
echo “change attribute=CODE_ROOT_PATH”
chmod -R 775 CODE_ROOT_PATH
./ims_make.sh std9000 dbg mcca
3.2.4 出包
编译任务完成后，将编译生成的所有模块的进程文件和一些产品的配置文件通过在ICP-CI工具的软件构建工程运行出包步骤，生成可以直接安装产品的软件包。出包脚本是用Ant编写，为了能方便调用Ant脚本，需要将ICP-CI工具tool目录下的Ant工具的路径添加到环境变量的path路径下。ICP-CI工具需要在构建工程的ICP-CI的任务页面配置出包任务package，将出包脚本task_custom_package.xml配置到任务中。出包脚本内容如下所示：
3.2.5 自动化用例测试
在构建工程的ICP-CI的任务页面上完成测试用例任务的配置。在测试用例环境下对版本包进行自动化测试，完成版本包的初步测试。
持续集成采用的HLT(HIGH LEVEL TEST)自动化测试。HLT通常指SDV(系统设计验证)/SIT(系统集成测试)/SVT(系统验证测试)等测试活动。HLT是站在系统的角度对整个版本进行测试，测试的对象是一个完整的产品而不是产品内部的模块，常见的HLT测试包括系统测试和验收测试。
使用ICP-CI工具执行自动化测试，需要将自动化用例的执行工具集成到ICP-CI工具中。自动化执行工具可以自动完成测试用例管理、测试环境配置、测试版本自动安装与卸载、自动化测试用例执行等任务。
如果出包阶段生成的版本包能够完成HLT自动化测试则证明版本包的基本功能没有问题。版本包可以合入代码配置库的特性与问题单，作为进行验证性测试的版本；也可以作为测试人员回归问题单的版本。
使用ICP-CI工具完成HLT任务，需要在构建工程的ICP-CI任务管理页面配置HLT任务。配置HLT任务需要配置产品的自动化测试用例库名称、自动化测试服务管理系统名称、自动化测试端口号(通常为8080)、控制HLT任务下发的配置文件的路径和VersionReleaseInfo.ini文件。VersionReleaseInfo.ini文件的配置内容如下所示：
[Summary_Info]
IssueTime=2015-01-23_02.00.11
cVersion=产品名称 版本号_CI
bVersion=产品名称 版本号_CIB000 //持续集成自动化测试用例库
IssueStatus=0
VerDescription=版本号
CmsType=DailyTest
Priority=0
[STD_LEM_SRV]
Version=版本号
Directory=出包任务完成之后，需要将版本包拷贝的路径
Filename=版本包名称
ICP-CI工具通过执行相应的ANT脚本将出包步骤生成的版本包拷贝到Directory参数配置的路径下，通过以下步骤来完成HLT任务：
(1)更新VersionReleaseInfo.ini配置文件的IssueTime，触发CIMonitor工具；
(2)根据bVersion参数配置，CIMonitor工具提交测试集中控制中心持续集成自动化测试任务；
(3)测试集中控制中心将任务下发至执行测试用例的执行机，承担测试任务的执行机，需要卸载前一次的测试用例版本库，卸载后安装本次测试用例版本库。版本库安装完成后，开始执行测试用例；
(4)当所有测试用例执行完成之后将执行结果从用例执行机、测试集中控制中心、CIMonitor工具一层层反馈到ICP-CI页面的执行结果页面上。
4 持续集成失败的原因分析与处理方法
进行持续集成工作时，难免会出现持续集成失败的情况，对于整个软件项目团队而言，持续集成失败需要引起极大地重视。一旦出现持续集成失败，持续集成工程师需要第一时间发现持续集成构建工程已经失败，根据已经失败的构建工程失败的位置、构建工程页面上提示失败的错误信息以及构建工程的详细日志文件来确定本次持续集成失败的原因，来确定解决问题的方案。持续集成失败的原因通常有以下几类。
4.1 持续集成构建环境存在问题
由于构建环境存在问题导致构建失败，通常表现为：主控服务器与代理服务器之间失去联系、代理服务器断开连接、需要归档到固定路径下的结果文件归档失败以及磁盘或根分区的空间过满导致构建失败。对于这类问题，大部分可以在持续集成构建开始之前通过对构建环境的检查和构建环境的日常维护来解决。对于避免构建环境原因导致的持续集成构建失败需要做到以下几点：
1)在启动持续集成构建之前，检查所有构建环境是否能正常登陆；
2)检查构建环境中所有的ICP-CI相关的进程是否能正常启动；
3)每周重启一次所有的构建环境，保持构建环境性能稳定；
4)每三天清理一次构建环境上的日志文件以及各种中间文件存放的文件夹，确保所有构建环境内存的大于某个最小内存下限值。
4.2 持续集成脚本存在问题
持续集成脚本是完成持续集成构建的基础；将软件产品从单独的某个进程文件编译或者单个模块的静态检查过程串联起来，形成产品所有模块源代码的静态检查、编译、出包以及自动化测试过程为一体的源代码问题检测和产品版本包验证机制。持续集成脚本在这个机制中是串联各个环节的纽带。
1)通常持续集成脚本问题导致的失败比较多的情况，出现在构建环境刚刚搭建完成的工程调试阶段。常见的表现形式为各种中间文件拷贝失败等。为了避免这些失败需要仔细分析构建日志中的各种问题现象找到问题发生的原因并对构建脚本进行相应的修改来解决。
2)在软件产品开发过程中，不断会有因为产品在安全方面或者客户需求方面的变化导致的软件产品版本包内文件在出包过程中参于出包的文件发生变化，这需要产品的系统工程师和软件开发工程师及时知会持续集成工程师完成出包脚本的修改，以确保软件产品的版本包能符合安全方面或者客户需求。
4.3 软件源代码问题
软件源代码问题导致持续集成失败是持续集成失败中出现频率最高的情况。软件产品版本从原型系统阶段到转维护的在研开发阶段中解决了上千次的源代码问题导致的构建失败。这些问题主要包括编译错误、*.sql文件执行失败、Pclint静态检查错误和告警；编译完成的版本包加载到自动化测试环境上之后，由于源代码缺陷导致的模块进程文件故障。
为了保证每次持续集成都使用最新的代码，在持续集成之先需要更新代码。开发工程师将没有进行充分编译、静态检查以及功能验证的代码直接合入SVN配置库，就会导致在持续集成过程中出现编译失败、静态检查失败以及自动化测试用例失败等一系列构建失败。这类失败的原因是源代码开发完成之后验证不充分就合入了SVN配置库。开发工程师完成源代码编码之后，需要完成编译验证、静态检查，单元测试、代码评审，确认合入配置库的源代码没有问题后，才能将源代码合入SVN配置库，这样就可以最大限度的降低源代码问题导致持续集成失败。
5 典型案例
某公司的有一个软、硬件结合的中型软件开发项目，总的代码量超过两百万行。采用的SVN版本是1.6.16，客户端安装SVN命令行工具和SVN图形客户端工具Tortoise；数据库为PostgreSQL数据库；持续集成使用ICP-CI工具。1台主控服务器和7台代理服务器参与持续集成。主控服务器操作系统为WINDOWS 2003 Server，部署工具为ICP-CI-Windows-Master。5台代理服务器操作系统为Suse Linux 10 x86-64，部署工具ICP-CI-Linux-Agent。产品的编译和出包环境为Suse Linux 10 x86-64，采用Linux环境下的shell脚本和ANT脚本编程完成软件持续集成中的进程编译以及版本出包任务。剩余的2台代理服务器安装Windows 2003操作系统，部署工具ICP-CI-Windows-Agent，使用批处理脚本和ANT脚本编程完成持续集成过程中的静态检查和出包准备任务。工作实践表明持续集成有助于及早发现并解决软件源代码的问题和缺陷，便于产品主管了解工作进度和解决存在的问题。
6 结束语
长期的工作实践表明在软件的开发过程中采用基于SVN的持续集成，可以提高软件的质量和软件开发效率，降低软件的的成本。利用持续集成完成自动化构建，可以快速向开发工程师反馈软件源代码的缺陷，使开发工程师能够很快修复源代码的缺陷，大大减少了开发中埋藏代码缺陷，有效避免大量的源代码缺陷在软件开发的某个阶段集中爆发，同时也给项目的管理提供了很好的保证。
[1] 罗时飞.敏捷持续集成 : CruiseControl版：高效硏发之道[M]．北京：电子工业出版社，2008.
[2] Paul M．Duvall，Steve Matyas，Andrew Glover．持续集成软件质量改进和风险降低之道[M]．北京：电子工业出版社，2012.
[3] 董 越.软件集成策略—如何有效率地提升质量[M]．北京：电子工业出版社，2013.
[4] 周 念. 基于SVN的软件配置管理的应用研究[D]．武汉：武汉理工大学, 2013.
[5] 相玉娟.基于变更管理的持续集成研究与应用[D]．安徽：合肥工业大学,2009.
[6] Ben Collins—Sussman，Brian W．Fitzpatrick，C．Michael Pilato．Version Control with Subversion For Subversion 1.5[M]．Karl Fogel，2005：1-142.
[7] Ste fan Kung，Lubbe Onken，Simon Large．Tortoise SVN Versionl 1.5.2[M]．Karl Fogel，2005：102-132．
[8] David Bellagio，Tom Milligan．Software Configuration Management Strategies and IBM Rational ClearCase：A Practical Introduction．2ndEdition[M]．IBM Press．2005．
[9] 徐仕成，杨邦荣. 基于C ruiseControl的持续集成实现方案[J]． 计算机与数字工程，2007,35(4)：169-171.
[10] 李坤宁.单元测试和持续集成在企业级软件开发中的设计与实现[D]．成都：电子科技大学,2011.
[11] 陈婧欣.基于Hudson的持续集成方案的研究与实现[D]．长春：东北师范大学,2011.
[12] 李 进.某公司软件持续集成改进的分析设计及实施[D]．北京：北京邮电大学,2012.
Continuous Integration of Application Software Based on SVN
Jiang Wen，Liu Likang
(School of Telecommunication Engineering, Xidian University, Xi’an 710071,China)
With the development of the software development technology, software configuration management and continuous integration has become an important part in the process of software development. In order to correctly apply the new technology in the process of software development, needs to research work in this field, combines with working practice, uses SVN as configuration management tool, analyzes the characteristics of continuous integration tool ICP-CI, deployment mode and operation mechanism. Construction process of ICP-CI continuous integration building project , building process including the SCM tool SVN client installation, based on the static code SVN update, check and compilation, packaging, release package for automated tests is described in detail. In every stage of building project, possible errors causes the failure of building, through the analysis of the building failure reason, building failures can be divided into 3 groups, and gives the corresponding solutions. Finally introduces a typical case. Practice shows that the continuous integration based on SVN in the process of software development, reduces the cost of software development.
continuous Integration；ICP-CI； ICP-CI server；build；SVN
2015-08-23；
2015-10-30。
国防预研基金项目(A1120110007)。
姜 文(1986-)，女，陕西西安人，工程师，硕士研究生，CCF会员(E200032324M)，主要从事图像处理与分析，文字信息分析处理，数据库应用和软件工程方向的研究。
刘立康(1962-)，男，陕西西安人，副教授，主要从事数字通信、图像传输与处理、图像分析与图像识别等方向的研究。
1671-4598(2016)03-0109-05
10.16526/j.cnki.11-4762/tp.2016.03.030
TP311.5
A
