基于Jenkins的持续集成系统研究
2014-09-08林新党穆加艳
林新党,穆加艳
(1. 海军驻南京地区雷达系统军事代表室,南京 210003;2.中国船舶重工集团公司第七二四研究所,南京 211153)
基于Jenkins的持续集成系统研究
林新党1,穆加艳2
(1. 海军驻南京地区雷达系统军事代表室,南京 210003;2.中国船舶重工集团公司第七二四研究所,南京 211153)
针对敏捷开发实践的特点,研究了基于Jenkins的持续集成系统。综合考虑了软件开发的项目组织形式,采用了支持分布式工作流的代码存储库,利用测试驱动开发的测试方法。实现了自动化软件单元测试及持续集成,并与传统的人工测试在时间开销方面作了比较分析。
持续集成系统;自动化测试;单元测试
0 引 言
在保证高质、高效完成项目的前提下,需要提炼项目中重复且无需人工干预的任务交给计算机来完成。可重复完成的任务是可回归的。可回归性和敏捷性相辅相成,可回归性是基础,而敏捷性是提升可回归能力的重要方面。为了使软件研发过程的可回归性和敏捷性达到最优,必须实施持续集成。持续集成可以最大化地体现可回归性和敏捷性。本文是持续集成的一个具体实践,主要包括持续集成工具、代码存储库和自动化单元测试工具以及若干脚本文件。持续集成包括读取源代码、编译、连接、测试等过程,整个创建过程都是自动完成。成功的构建都须通过测试才能完成。通过查看构建趋势和测试结果趋势,可以看出程序历史版本的构建情况。
对于持续集成的工具,本文选择的是Jenkins。它为开源项目,可免费获得,并提供较多的插件支持,可方便使用第三方的应用功能。
本系统以最小的人机交互来完成软件的自动化测试和持续构建,可以提高软件测试的速度和效率,缩短软件开发时间,降低测试成本。
1 系统设计
1.1 系统组成
本系统主要基于VC的项目使用,构建并完成代码的自动化单元测试。考虑项目人员不集中等情况,持续集成系统的方案有如下两种:
•第一种方案:Jenkins + Mercurial + MSBuild + CppUnit + sourceMonitor + Cpplint;
•第二种方案:Jenkins + Mercurial + MSBuild + LDRA_Testbed(商业测试软件)。
两种方案比较:
(1) 第一种方案采用开源和免费的软件,较易获得,使用方便,便于普及;
(2) 第二种方案中的测试软件为商业测试软件LDRA_Testbed,在普及上有一定局限性;优点是代码的规则检查时可以定制规则,并且该软件集代码规则检查、代码度量和代码覆盖率测试功能于一体。
本文的持续集成系统采用第一种方案,代码存储库使用Mercurial,持续集成工具为Jenkins,测试工具使用CppUnit测试框架,静态分析软件为Cpplint,代码度量工具为sourceMonitor。本系统组成如图1。
图1 持续集成系统组成
代码存储库有两种控制流,一种为分布式,另一种为集中式的。开发人员平时可以把代码存储库视为分布式的,在本地管理自己的代码,须将代码上传到持续集成服务器时再使用集中式控制流。
开发人员须在计算机上配置代码存储库、开发工具以及测试工具。当开发人员在本地开发代码时,编写测试用例作单元测试,测试通过后上传到持续集成服务器。
持续集成服务器需安装代码存储库、持续集成工具、MSBuild以及测试工具等,环境配置为持续集成环境。当项目组上传代码时,持续集成系统按照预先设置的环境参数完成自动集成并测试。
1.2 持续集成的流程
持续集成的流程图如图2所示,持续集成模块的使用场景如下:
(1) 开发人员A负责开发工程模块A,开发人员B负责开发该工程模块B。开发人员分别在自己的电脑上开发完相应模块并且通过单元测试;
(2) 项目负责人集成模块A和模块B,建立project,编译并经过单元测试后将project上传代码存储库;
(3) 项目负责人在本平台新建job,并对该job的project源代码位置以及自动化测试进行相关配置,设置构建时机(可以设置为源代码库里相关代码变动了即开始构建);
(4) 开发人员修改代码后上传到代码存储库,上传成功后持续集成平台自动执行构建和测试的工作;
(5) 持续集成平台将测试结果反馈给开发人员,开发人员修改代码后再上传到代码存储库,即触发新一次构建。
图2 持续集成的流程图
2 系统使用
2.1 安装和配置
持续集成软件Jenkins选择默认安装,代码存储库软件选择windows图形界面tortoiseHg版本。持续集成系统需要安装相应的若干插件,具体如下:
•Mercurial插件:使Jenkins能使用代码存储库Mercurial;
•MSBuild插件:使Jenkins能使用MSBuild,这样才能构建基于VC的项目;
•xUnit插件和CppUnit插件:使Jenkins能查看CppUnit测试结果,并作测试结果的趋势统计。
Jenkins在正常工作前需要作如下的配置:
•代码存储库的配置:设置代码仓库的路径;
•MSBuild的配置:设置MSBuild的路径;
•单元测试的配置:设置要查看的测试结果的路径。
整个系统的使用部署情况如图3所示。
图3 持续集成系统的部署图
2.2 持续构建
持续集成软件基于web服务,访问端口为8080。持续集成工具安装配置成功后,在本地访问的地址是http://localhost:8080/。首先须建立一个新任务,并完成该任务的设置,包括需要编译的工程文件的路径以及触发构建的时机等。设置成功后系统就能自动地完成持续集成工作。
用户可修改JENKINS_HOME的位置:在Jenkins的Jenkins.xml中找到JENKINS_HOME,默认value为%BASE%。用户可根据实际需要更改路径,并重启Jenkins,使其生效。
Jenkins无须登陆即可直接使用。如果出于安全考虑而需进行登录设置的,可在“系统管理”-“系统设置”中进行配置,也可以下载插件Role Strategy Plugin来进行用户管理。
持续集成工具提供4种方式的构建时机,用户可以根据需要自行设定。
如果项目有构建依赖,即A任务完成后B任务才可以运行,那么就需要配置两个任务间的依赖关系,在设置持续集成任务时配置完成。
持续集成系统可以查看持续构建的趋势,如图4右下角的曲线图,横轴表示构建次数,纵轴表示每次构建的时间。
查看测试结果趋势如图5所示,横轴表示构建次数,纵轴表示用例数,两条曲线分别表示用例总数和失败用例数。可以查看不成功构建的原因以及失败的测试用例等,如图6所示。
图4 持续集成工具的界面图
图5 测试结果趋势图
图6 查看测试结果
2.3 单元测试
没有测试是不完整的构建,只有通过测试的构建才算构建成功的版本。在本系统中采用xUnit测试框架CppUnit来作单元测试。该框架能够辅助单元测试编写测试用例、运行测试以及产生报告,是测试驱动开发测试方法的一个工具。利用该测试方法可先写测试用例,再为测试代码添加产品代码。在进行自动化测试时,将数据、配置和功能分开,有利于提高测试的时间和维护测试脚本及测试用例。
单元测试包括静态分析和覆盖率分析。静态分析包括代码审查。自动化的代码审查能解决80%的问题,让开发者来处理20%的重要问题[1]。本系统采用Cpplint来作代码规则检查。该工具针对google c++ style规则,持续集成系统可查看代码审查结果。Cpplint对审查结果给出一个置信度评分,分值在[1,5]之间,分数越高表示问题越肯定。
代码审查还包括代码度量,主要针对代码的圈复杂度。可以根据复杂度随时间的变化趋势来决定测试的工作量。如果存在复杂度增加的趋势,就需要增加测试用例来减少风险,或通过重构来降低复杂度从而解决潜在的风险。
持续集成系统也可作其他类型的测试,如单元测试、系统测试、负载/性能测试和安全测试等。
2.4 信息反馈
持续集成系统主要优点是能快速向开发者和项目风险承担者提供反馈信息。
使用持续集成系统,可以随时了解项目的状态。该过程为无须人工干预的过程,机器自动执行,确保随时有可运行的版本。持续集成系统每次构建都会产生一个控制台记录文件,记录构建过程。
反馈机制有三种:Email/IM/RSS(Really Simple Syndication)。每次构建结束后持续集成系统会通过用户选择的方式将结果通知相关人员。
3 结束语
持续集成系统可以帮助项目组成员将时间用在更重要、更有挑战性的问题上,从而缩短项目的开发时间、提高软件质量。开发者可以将时间更多地用在软件设计上,而把繁琐、可重复的集成工作交给机器来完成。因持续集成快速反馈的信息,测试人员能更频繁地进行测试,而每次测试范围比较小,且是持续在测试,不必等到软件全部完成后再测试。对于项目的管理者,通过持续集成,每次构建都能得到可执行的软件产品和真实的测试数据。这些决策信息能让项目管理者集中精力来管理项目时间、费用和品质。
[1] Paul M.Duvall,等. 持续集成软件质量改进和风险降低之道[M].王海鹏,等译.北京:电子工业出版社,2012.6:126.
[2] 尹平,等.软件测试与软件质量评价[M].北京:国防工业出版社,2008:184.
Continuous integration system based on Jenkins
LIN Xin-dang1, MU Jia-yan2
(1.Military Representatives Office of Radar System of the Chinese PLA Navy in Nanjing, Nanjing 210003; 2.No. 724 Research Institute of CSIC, Nanjing 211153)
According to the characteristics of agile development practices, the continuous integration system based on Jenkins is studied. With the project organization forms of the software development taken into consideration and the code repository that supports distributed workflow adopted, a test-driven development test method is used. The automated software unit test and continuous integration system are realized, and the conventional manual test is compared with the new test in time spending.
continuous integration system; automated test; unit test
2013-12-20
林新党(1970-),男,工程师,硕士,研究方向:雷达总体技术;穆加艳(1980-),女,高级工程师,工程硕士,研究方向: 雷达总体及终端技术。
TP311.1
A
1009-0401(2014)01-0058-04