基于Jenkins的持续集成自动部署研究

总第３１６期　

２０１６年第２期　

计算机与数字工程　

Ｃｏｍｐｕｔｅｒ＆Ｄｉｇｉｔａｌ　Ｅｎｇｉｎｅｅｒｉｎｇ　

Ｖｏ１．４４　Ｎｏ．２　

２６７　

基于Ｊｅｎｋｉｎｓ的持续集成自动部署研究　

周莹欧中红李

武汉

俊　

４３０２０５）　（武汉数字工程研究所

摘要在基于Ｊｅｎｋｉｎｓ的持续集成系统中，应用程序的组件管理和依赖管理是至管重要的。论文提出了一种方案，　

通过引入依赖管理工具Ｉｖｙ和制品管理工具Ａｒｔｉｆａｅｔｏｒｙ，以及设计相应的脚本程序，获取正确版本的制品组成部署安装包。　

确保在集成过程中，组成应用程序的模块的所有版本保持一致，避免依赖地狱的产生，为自动化部署提供基础。　

关键词持续集成；依赖关系；Ｊｅｎｋｉｎｓ；自动部署　

ＴＰ３１１．１　ＤＯＩ：１０．３９６９／ｊ．ｉｓｓｒＬ　１６７２—９７２２．２０１６．０２．０２１　中图分类号

Ａｕｔｏｍａｔｅｄ　Ｄｅｐｌｏｙｍｅｎｔ　ｏｆ　

Ｃｏｎｔｉｎｕｏｕｓ　Ｉｎｔｅｇｒａｔｉｏｎ　Ｂａｓｅｄ　ｏｎ　Ｊｅｎｋｉｎｓ　

ＺＨＯＵ　Ｙｉｎｇ　ＯＵ　Ｚｈｏｎｇｈｏｎｇ　ＬＩ　Ｊｕｎ　

（Ｗｕｈａｎ　Ｄｉｇｉｔａｌ　Ｅｎｇｉｎｅｅｒｉｎｇ　Ｉｎｓｔｉｔｕｔｅ，Ｗｕｈａｎ　４３０２０５）　

Ａｂｓｔｒａｃｔ　Ｉｎ　ｔｈｅ　ｃｏｎｔｉｎｕｏｕｓ　ｉｎｔｅｇｒａｔｉｏｎ　ｓｙｓｔｅｍ　ｂａｓｅｄ　ｏｎ　Ｊｅｎｋｉｎｓ，ｉｔ　ｉｓ　ｖｅｒｙ　ｉｍｐｏｒｔａｎｔ　ｔｏ　ｍａｎａｇｅ　ｔｈｅ　ｃｏｍｐｏｎｅｎｔｓ　ｏｆ　ａｐ—　

ｐｌｉｃａｔｉｏｎ　ａｎｄ　ｔｈｅ　ｄｅｐｅｎｄｅｎｃｉｅｓ　ｂｅｔｗｅｅｎ　ｃｏｍｐｏｎｅｎｔｓ．Ａ　ｓｃｈｅｍｅ　ｉｓ　ｇｉｖｅｎ　ｉｎ　ｔｈｉｓ　ｐａｐｅｒ，ｉｎ　ｗｈｉｃｈ　ｔｈｅ　ｃｏｒｒｅｃｔ　ｖｅｒｓｉｏｎ　ｏｆ　ａｒｔｉｆａｃｔｓ　

ｆｏｒ　ｄｅｐｌｏｙｍｅｎｔ　ｐａｃｋａｇｅ　ｉｓ　ｇｏｔｔｅｎ　ｂｙ　ｅｎｈａｎｃｉｎｇ　Ｉｖｙ　ｔｈｅ　ｄｅｐｅｎｄｅｎｃｙ　ｍａｎａｇｅｍｅｎｔ　ｔｏｏｌ　ａｎｄ　Ａｒｔｉｆａｃｔｏｒｙ　ａｒｔｉｆａｃｔｓ　ｍａｎａｇｅｍｅｎｔ　

ｔｏｏｌ，ａｓ　ｗｅｌ１　ａｓ　ｃｏｎｓｔｒｕｃｔｉｎｇ　ｒｅｌａｔｅｄ　ｓｃｒｉｐｔ．Ｔｈｉｓ　ｉｓ　ｔｈｅ　ｂａｓｉｓ　ｆｏｒ　ａｕｔｏｍａｔｅｄ　ｄｅｐｌｏｙｍｅｎｔ，ｅｎｓｕｒｉｎｇ　ａｌｌ　ｖｅｒｓｉｏｎｓ　ｏｆ　ｔｈｅ　ｍｏｄｕｌｅｓ　

ｉｎ　ｔｈｅ　ａｐｐｌｉｃａｔｉｏｎ　ｂｅ　ｃｏｎｓｉｓｔｅｎｔ　ａｎｄ　ｄｅｐｅｎｄｅｎｃｅ　ｈｅｌｌ　ｂｅ　ａｖｏｉｄｅｄ　ｉｎ　ｔｈｅ　ｐｒｏｃｅｓｓ　ｏｆ　ｉｎｔｅｇｒａｔｉｏｎ．　

Ｋｅｙ　Ｗｏｒｄｓ　ｃｏｎｔｉｎｕｏｕｓ　ｉｎｔｅｇｒａｔｉｏｎ，ｄｅｐｅｎｄｅｎｃｙ　ｒｅｌａｔｉｏｎｓｈｉｐ，Ｊｅｎｋｉｎｓ，ａｕｔｏｍａｔｅｄ　ｄｅｐｌｏｙｍｅｎｔ　

Ｃｌａｓｓ　Ｎｕｍｂｏｒ　ＴＰ３１　１．１　

１　引言　

持续集成是软件开发的一个重要实践。持续　

集成的引入，降低了软件开发的风险，提高软件开　

发效率，提高代码质量，使项目管理人员更好地了　

解项目的开发进度¨ｌｑ］。每次集成过程包括编译，　

与第三方库或模块与模块之间存在依赖关系时，为　

集成测试提供正确版本的模块及第三方库是集成　

测试成功的基础。模块之间的依赖是二进制文件　

的依赖，在为应用程序组装部署安装包时，必须保　

证各个模块在构建过程中依赖的二进制文件版本　

与其在部署安装包中的版本保持一致，并且不同模　

块不能对同一模块的不同版本存在依赖关系，防止　

形成依赖地狱（ｄｅｐｅｎｄｅｎｃｅ　ｈｅｌ１）。　

构件、部署、测试、发布，并且这个过程是自动化实　

现的［３］。实现自动化部署是实现自动化测试的基　

础［　。　

在基于Ｊｅｎｋｉｎｓ［ａ］的持续集成系统中，使用已　

有的插件只能部署当前ｊｏｂ生成的ｗａｒ／ｅａｒ文件到　

远程Ｗｅｂ容器中，如Ｔｏｍｃａｔ，不能实现Ｃ＋＋应　

用的多个且有依赖关系的文件地部署。本文通过　

在软件开发过程中，不同的功能模块一般由不　

同的开发团队负责，相同模块也由团队程序员共同　

实现。在这种情况下，代码的集成显得尤为重要。　

当各模块通过单元测试后，需要将模块组合在一　

起，进行集成测试，测试模块之间的接口。当模块　

在持续集成系统中，引入依赖管理工具Ｉｖｙ和制品　

管理工具Ａｒｔｉｆａｃｔｏｒｙ，旨在对Ｃ＋＋项目的模块间　

收稿日期：２０１５年８月１２日，修回日期：２０１５年９月２５日　

作者简介：周莹，女，硕士研究生，研究方向：计算机系统结构。欧中红，男，研究员，研究方向：计算机系统结构。　

李俊，女，博士，高级工程师，研究方向：计算机软件与理论。　

２６８　周莹等：基于Ｊｅｎｋｉｎｓ的持续集成自动部署研究　第４４卷　

依赖关系和模块的制品进行有效的管理。当所有　测试阶段主要是将部署安装包部署到相应的测　

试环境进行测试，通过自动化测试来验证集成是否　

模块通过单元测试并将制品上传到制品库中后，可　

通过执行脚本文件获取指定版本、指定平台的部署　

安装包，并保证各模块为正确版本，为自动化部署　

提供基础。　

成功ｌ８］，验证模块接口及软件是否符合用户的需求。　

从提交阶段进人测试阶段，最主要的就是组装　

部署安装包。部署安装包是由所有组件的二进制　

本文通过一个多模块应用程序的实例，说明如　

文件及其依赖文件组成，设计组件依赖关系的管　

弹　

何根据模块之间的关系在持续集成服务器中配置　

模块的工程，如何通过Ｉｖｙ管理组件之间的依赖关　

系，同时说明如何从制品库中获取指定版本的应用　

３获取部署安装包　

程序的模块。　

２持续集成的实现过程　

在对软件实施持续集成之前，需要在持续集成　

服务器上为每个模块创建一个构建流水线。在每　

个模块的ｊｏｂ配置中，需指定该模块源代码在ｓｖｎ　

中的存放地址，使系统能够检测到ｓｖｎ上代码的更　

新，并立即触发新的构建过程；指定构建过程执行　

的脚本，以及指定上传制品的制品库地址；根据组　

件之间的依赖关系，配置需要触发的下游项目，以　

此达到持续集成的目的。　

持续集成的实现可分为提交阶段和测试阶段。　

图１为持续集成系统的基本实现过程　］。　

＝＝＝　＝＝＝　＝＝＝　、　

ｌ　ｌ　ｌ环境配Ｉ　ｌ环境配　

ｌ源代码Ｉ　ｌ置和应ｌ　版本控制　Ｉ置和应　

、

Ｌ—　阜　Ｌ用配到，　

一匿　Ｊｌ　蔷　败原因厂Ｌ—］ｌＴＬ　－＿］Ｊ　Ｈｌ　ｌ　～部署　嚣制一包Ｉ’一　　

（　制品仓库　：　

图１　持续集成系统基本实现过程　

提交阶段主要包含以下过程：　

１）开发人员向版本控制库提交Ａ模块的代码；　

２）持续集成服务器Ａ模块的ｊｏｂ检测到代码　

变更，触发Ａ模块构建过程，编译代码、运行单元　

测试、执行代码分析，创建模块的二进制包。当构　

建通过单元测试并且代码符合编码标准，便将生成　

的二进制文件存放在制品库中；　

３）若Ｂ模块依赖与Ａ模块，当Ａ模块通过构　

建之后会触发Ｂ模块流水线的构建过程；　

４）当由代码更新触发的所有模块的构建过程　

完成之后，将该软件所有模块的制品组装成部署安　

装包，触发自动化验收测试阶段。　

３．１持续集成系统基本组成　

本文主要采用Ｊｅｎｋｉｎｓ＋ｓｖｎ＋ａｎｔ　＋Ｉｖｙ＋　

Ａｒｔｉｆａｃｔｏｒｙ组成基本的持续集成系统。其中Ｊｅｎ—　

ｋｉｎｓ为持续集成服务器，ｓｖｎ为版本控制工具，ａｎｔ　

为脚本构建工具，Ｉｖｙ是一个用来管理（记录、跟踪、　

解决和报告）项目依赖项的工具，Ａｒｔｉｆａｃｔｏｒｙ是一　

个制品库管理工具，用于存放第三方库文件和系统　

构建产生的制品。Ｉｖｙ具有灵活性和可配置性，适　

应广泛的依赖管理和构建过程，支持通过查找Ｉｖｙ　

文件中的元数据来解决传递依赖这一普遍问题。　

Ｉｖｙ与ｍａｖｅｎＥ　］比较而言，在冲突管理及灵活性方　

面做的更好。使用专业的制品管理工具，是为了确　

保构件的可重复性，通过在整个组件范围内控制应　

用程序对应的库的版本来避免依赖地狱。　

本文实例应用程序的模块包括Ｃｏｎｓｏｌｅ、Ｆｉｎｄ、　

Ｓｉｚｅｗｈｅｒｅ、Ｌｉｓｔ、Ｓｉｚｅ、Ｖｅｒｓｉｏｎ以及第三方依赖库　

Ｃｏｍｍｏｎｓ—ｃｏｌｉ１　Ｃｏｍｍｏｎ－ｌｏｇｇｉｎｇ　Ｃｏｍｍｏｎｓ—ｌａｎｇ　

和Ｃｏｍｍｏｎｓ—ｃｏｌｌｅｃｔｉｏｎｓ。它们之间的依赖关系如　

下图２所示。图中箭头终点处模块对箭头起点处　

组件依赖。　

图２模块依赖关系图　

３．２模块的相关配置　

根据模块依赖关系图可知，模块间有直接依赖　

和间接依赖的关系。在Ｊｅｎｋｉｎｓ中对模块进行配置　

时，需对模块之间的上下游关系进行分析。图３模　

块问触发关系图。　

图３模块间触发关系图　

２０１６年第２期　计算机与数字工程　２６９　

从图３可以看出模块Ｓｉｚｅ对模块Ｖｅｒｓｉｏｎ直　

接依赖，同时模块Ｓｉｚｅ因为依赖模块Ｌｉｓｔ而对模　

块Ｖｅｒｓｉｏｎ间接依赖。当模块Ｖｅｒｓｉｏｎ代码更新　

时，若同时触发模块Ｌｉｓｔ和模块Ｓｉｚｅ，可能导致模　

块Ｓｉｚｅ依赖的是新版本的模块Ｖｅｒｓｉｏｎ和对旧版　

本模块Ｖｅｒｓｉｏｎ依赖的模块Ｉ　ｉｓｔ。这样就导致了　

模块Ｓｉｚｅ同时对Ｖｅｒｓｉｏｎ的新版本和旧版本同时　

依赖，这种情况在持续集成过程中是应该避免的。　

为了防止Ｓｉｚｅ对不同版本的Ｖｅｒｓｉｏｎ有依赖关系，　

模块Ｖｅｒｓｉｏｎ不能直接触发模块Ｓｉｚｅ。同理分析，　

对各模块上下游触发关系进行如下配置：　

１）Ｖｅｒｓｉｏｎ模块触发下游Ｌｉｓｔ模块；　

２）Ｌｉｓｔ模块触发下游模块Ｆｉｎｄ模块和Ｓｉｚｅ　

模块，并且使用Ｊｏｉｎ插件实现在Ｆｉｎｄ和Ｓｉｚｅ都构　

件完成之后再触发下游模块Ｓｉｚｅｗｈｅｒｅ；　

３）Ｆｉｎｄ模块触发下游组模块Ｓｉｚｅｗｈｅｒｅ；　

４）Ｓｉｚｅ模块触发下游模块Ｓｉｚｅｗｈｅｒｅ；　

５）Ｓｉｚｅｗｈｅｒｅ模块触发下游模块Ｃｏｎｓｏｌｅ；　

６）Ｃｏｎｓｏｌｅ模块不触发下游模块。　

３．３　Ｉｖｙ管理模块的依赖关系　

在软件中常见的依赖关系有模块依赖和第三　

方库文件依赖。根据图中模块的依赖关系，可为每　

个模块定义Ｉｖｙ文件，用于在模块构建时从制品库　

中下载依赖文件。如模块Ｌｉｓｔ对Ｖｅｒｓｉｏｎ、和第三　

房库Ｃｏｍｍｏｎｓ—ｃｌｉ有依赖关系，模块Ｌｉｓｔ的ｉｖｙ．　

ｘｍｌ为　

（ｉｖｙ－ｍｏｄｕｌｅ　ｖｅｒｓｉｏｎ＝”１．０”）　

ｉｎｆｏ　ｓｔａｔｕｓ＝”ｉｎｔｅｇｒａｔｉｏｎ’　ｍｏｄｕｌｅ＝’’ｌｉｓｔ”　

ｏｒｇａｎｉｓａｔｉｏｎ＝”ｏｒｇ．ａｐａｃｈｅ．ｉｖｙ．ｅｘａｍｐｌｅ”／）　

ｃｏｎｆｉｇｕｒａｔｉｏｎｓ）　

＜ｃｏｎｆ　ｎａｍｅ一”ｃｏｒｅ”／＞　

（ｃｏｎｆ　ｎａｍｅ＝”ｓｔａｎｄａｌｏｎｅ”ｅｘｔｅｎｄｓ＝”ｃｏｒｅ”／）　

＜／ｃｏｎｆｉｇｕｒａｔｉｏｎｓ＞　

（ｐｕｂｌｉｃａｔｉｏｎｓ｝　

（ａｒｔｉｆａｃｔ　ｎａｍｅ＝”ｌｉｓｔ”ｃｏｎｆ一”ｃｏｒｅ”　

ｔｙｐｅ＝”ｊａｒ”／＞　

（／ｐｕｂｌｉｃａｔｉｏｎｓ｝　

（ｄｅｐｅｎｄｅｎｃｉｅｓ）　

（ｄｅｐｅｎｄｅｎｃｙ　ｎａｍｅ＝”ｖｅｒｓｉｏｎ”　

ｒｅｖ＝”ｌａｔｅｓｔ．ｉｎｔｅｇｒａｔｉｏｎ”　

ｅｏｎｆ＝”ｃｏｒｅ一＞ｄｅｆａｕｌｔ”／）　

ｄｅｐｅｎｄｅｎｃｙ　ｏｒｇ＝”ｃｏｍｍｏｎｓ—ｃｌｉ”　

ｎａｍｅ＝”ｃｏｍｍｏｎｓ—ｃｌｉ”ｒｅｖ＝”１．Ｏ”　

ｃｏｎｆ＝”ｓｔａｎｄａｌｏｎｅ－－＞ｄｅｆａｕｌｔ”／＞　

（／ｄｅｐｅｎｄｅｎｃｉｅｓ＞　

（／ｉｖｙ－ｍｏｄｕｌｅ）　

其中＜ｃｏｎｆｉｇｕｒａｔｉｏｎｓ＞定义了组件Ｌｉｓｔ发布制　

品的集合ｃｏｒｅ和ｓｔａｎｄａｌｏｎｅ。（ｐｕｂｌｉｃａｔｉｏｎｓ）定义　

了将该组件生成的制品ｌｉｓｔ．ｊａｒ发布到ｃｏｒｅ配置项　

中。若开发多平台的应用程序，可指定不同平台的　

配置项，并指定发布到该配置项中的制品实现制品　

与平台的映射关系。＜ｄｅｐｅｎｄｅｎｃｉｅｓ＞中配置的是　

Ｌｉｓｔ与其他组件的依赖关系。指定依赖于组件　

Ｖｅｒｓｉｏｎ的版本为最新版本ｌａｔｅｓｔ．ｉｎｔｅｇｒａｔｉｏｎ。在　

Ｉｖｙ中有三种默认的状态ｒｅｌｅａｓｅ、ｍｉｌｅｓｔｏｎｅ和ｉｎ—　

ｔｅｇｒａｔｉｏｎ，此外还可以通过ｓｔａｔｕｅｓ来定义更多可　

用的状态，状态定义的顺序即为解析依赖时匹配的　

优先级。Ｃｏｎｆ为配置依赖项之间的映射关系，如　

Ｌｉｓｔ对Ｖｅｒｓｉｏｎ的依赖映射关系ｃｏｒｅ一＞ｄｅｆａｕｌｔ　

表明模块Ｌｉｓｔ的ｃｏｒｅ配置项依赖Ｖｅｒｓｉｏｎ的默认　

配置项。由于第三方库文件也是以二进制文件的　

格式存储在制品管理库中，并且版本不会经常更　

新，因此可以指定ｒｅｖ为固定版本。　

对于存在传递依赖关系的模块，在Ｉｖｙ文件中　

只需要定义模块的直接依赖项，在解析依赖过程中　

Ｉｖｙ会同时解析间接依赖项。为了在某版本的应用　

程序中保持模块版本的一致性，Ｉｖｙ通过在解析过　

程中创建一个文件，使在同一个ｒｅｓｏｌｖｅｌｄ和同一　

个解析缓冲区中不能对同一个模块有不同的解析　

版本。　

通过在Ｉｖｙ文件中指定依赖项的版本号和配　

置映射关系，在模块构建的过程中便可以正确解析　

模块的依赖项。同时对模块之间的依赖关系进行　

分析，对模块进行正确的配置，当模块代码更新时，　

可以触发相关模块的构建以及测试过程。　

３．４组装部署安装包　

对所有模块的ｉｖｙ．ｘｍｌ进行正确配置是模块　

进行正确构建的基础。所有模块通过单元测试，将　

生成的二进制制品上传到制品库后，就需要将所有　

模块组装在一起。当当前流水线组装安装包或组　

装指定版本的应用程序安装包时，本文也通过采取　

解析Ｉｖｙ文件的方式获得相关模块的正确版本。　

该Ｉｖｙ文件是在每个模块上传制品的同时上传的　

构建过程的产生的依赖解析报告ｉｖｙ．ｘｍｌ。依赖解　

析报告ｉｖｙ．ｘｍｌ内容为　

＜ｉｖｙ－ｍｏｄｕｌｅ　ｖｅｒｓｉｏｎ一”１．０”＞　

（ｉｎｆｏ　ｏｒｇａｎｉｓａｔｉｏｎ＝”ｏｒｇ．ａｐａｃｈｅ．ｉｖｙ．ｅｘａｍｐｌｅ”　

ｍｏｄｕｌｅ＝”ｃｏｎｓｏｌｅ”ｒｅｖｉｓｉｏｎ＝”１．０一ｄｅｖ－ｂｌ”　

ｓｔａｔｕｓ一”ｒｅｌｅａｓｅ”ｐｕｂｌｉｃａｔｉｏｎ＝”２０１５０７０５”／＞　

（ｄｅｐｅｎｄｅｎｃｉｅｓ）　

（ｄｅｐｅｎｄｅｎｃｙ　ｎａｍｅ一”ｖｅｒｓｉｏｎ”　

ｒｅｖ一”］．０一ｄｅｖ－ｂｌ”　

ｒｅｖＣｏｎｓｔｒａｉｎｔ＝”ｌａｔｅｓｔ．ｉｎｔｅｇｒａｔｉｏｎ”　

２７０　周莹等：基于Ｊｅｎｋｉｎｓ的持续集成自动部署研究　第４４卷　

ｃｏｎｆ一”ｄｅｆａｕｌｔ”／、　

（ｄｅｐｅｎｄｅｎｃｙ　ｎａｍｅ一”ｆｉｎｄ”ｒｅｖ＝“１．０－ｄｅｖ－ｂｌ”　

ｒｅｖＣｏｎｓｔｒａｉｎｔ＝”ｌａｔｅｓｔ．ｉｎｔｅｇｒａｔｉｏｎ”　

ｃｏｎｆ＝”ｄｅｆａｕｌｔ－－＞ｓｔａｎｄａｌｏｎｅ”／）　

（ｄｅｐｅｎｄｅｎｃｙ　ｎａｍｅ”ｓｌｚｅｗｈｅｒｅ”　

ｒｅｖ＝”ｌ＿０一ｄｅｖ－ｂｌ”　

ｒｅｖＣｏｎｓｔｒａｉｎｔ＝”ｌａｔｅｓｔ．ｉｎｔｅｇｒａｔｉｏｎ”　

ｃｏｎｆ￣”ｄｅｆａｕｌｔ一＞ｓｔａｎｄａｌｏｎｅ”／）　

（／ｄｅｐｅｎｄｅｎｃｉｅｓ）　

（／ｉｖｙ－ｍｏｄｕｌｅ）　

该ｉｖｙ．ｘｍｌ文件描述的是模块Ｃｏｎｓｏｌｅ版本　

为１．０－ｄｅｖ－ｂｌ的依赖解析报告。与之前定义的　

Ｉｖｙ文件的区别是，依赖项的版本是准确版本，依赖　

模块Ｖｅｒｓｉｏｎ的１．０－ｄｅｖ－ｂｌ版本，模块Ｆｉｎｄ的１．　

０－ｄｅｖ—ｂｌ版本，及模块Ｓｉｚｅｗｈｅｒｅ的１．０－ｄｅｖ－ｂｌ版　

本。若指定获取Ｃｏｎｓｏｌｅ的１．０－ｄｅｖ—ｂｌ版本，可通　

过解析该Ｉｖｙ文件及迭代解析模块Ｖｅｒｓｉｏｎ、Ｆｉｎｄ、　

Ｓｉｚｅｗｈｅｒｅ的Ｉｖｙ文件，获取相关模块的版本。根　

据制品在Ａｒｔｉｆａｃｔｏｒｙ中存放的规律，通过在脚本　

中使用Ａｒｔｉｆａｃｔｏｒｙ　ＲＥＳＴ　ＡＰＩ便可从制品库中获　

取与指定版本相关的所有二进制文件，这些制品文　

件便组成了部署安装包。　

过程的实现依赖于对模块Ｉｖｙ文件定义的正　

确性，通过Ｉｖｙ的使用，通过执行脚本可以从制品　

库中获取组成该版本应用程序的模块及依赖库的　

二进制制品，并组装成部署安装包，用于后续的测　

试过程。　

４　结语　

通过在持续集成服务器中对应用程序的模块　

的配置，正确指定模块的上下游触发关系，并结合　

ｉｖｙ文件对模块之间依赖关系的管理，能够避免应　

用程序产生对统一模块的不同版本的依赖。同时　

根据产生的依赖解析报告，可以从制品库中下载制　

定版本应用程序的部署安装包，为集成测试提供基　

础。　

参考文献　

［１］陈刚，羌玲玲．软件项目开发中的持续集成研究［Ｊ］．项　

目管理技术，２０１１，１２（１２）：１．　

ＣＨＥＮＧ　Ｇａｎｇ，ＱＩＡＮＧ　Ｌｉｎｇｌｉｎｇ．Ｒｅｓｅａｒｃｈ　ｏｎ　Ｃｏｎｔｉｎ—　

ＵＯＵＳ　Ｉｎｔｅｇｒａｔｉｏｎ　ｉｎ　Ｓｏｆｔｗａｒｅ　Ｄｅｖｅｌｏｐｍｅｎｔ［Ｊ］．Ｐｒｏｊｅｃｔ　

Ｍａｎａｇｅｍｅｎｔ　Ｔｅｃｈｎｏｌｏｇｙ，２０１１，１２（１２）：１．　

［２］王英．持续集成在软件项目管理中的作用［Ｊ］．福建电　

脑，２００９，１２：６６—６７．　

ＷＡＮＧ　Ｙｉｎｇ．Ｔｈｅ　Ｒｏｌｅ　ｏｆ　Ｃｏｎｔｉｎｕｏｕｓ　Ｉｎｔｅｇｒａｔｉｏｎ　ｉｎ　

ｏＳｆｔｗａｒｅ　Ｐｒｏｊｅｃｔ　Ｍａｎａｇｅｍｅｎｔ［Ｊ］．Ｆｕｊｉａｎ　Ｃｏｍｐｕｔｅｒ，　

２００９，１２：６６—６７．　

［３］刘巧玲，范冰冰，黄兴平．基于Ｈｕｓｄｏｎ的持续集成研究　

和应用口］．计算机系统应用，２０１０，１２：１．　

ＬＩＵ　Ｑｉａｏｌｉｎｇ，ＦＡＮ　Ｂｉｎｇｂｉｎｇ，ＨＵＡＮＧ　Ｘｉｎｇｐｉｎｇ．　

Ｒｅｓｅａｒｃｈ　ａｎｄ　Ａｐｐｌｉｃａｔｉｏｎ　ｏｆ　Ｃｏｎｔｉｎｕｏｕｓ　Ｉｎｔｅｇｒａｔｉｏｎ　

Ｂａｓｅｄ　ｏｎ　Ｈｕｄｓｏｎ［Ｊ］．Ｔｈｅ　ｏＣｍｐｕｔｅｒ　Ｓｙｓｔｅｍ　Ａｐｐｌｉｃａ　

ｔｉｏｎ，２０１０，１２：１．　

［４］李进．某公司软件持续集成改进的分析设计及实施　

［Ｄ］．北京：北京邮电大学，２０１２，５．　

ＬＩ　Ｊｉｎ．Ａｎａｌｙｓｉｓ，Ｄｅｓｉｇｎ　Ａｎｄ　Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ　ｏｆ　Ｓｏｆｔ—　

ｗａｒｅ　Ｃｏｎｔｉｎｕｏｕｓ　Ｉｎｔｅｇｒａｔｉｏｎ　Ｉｍｐｒｏｖｅｍｅｎｔ　ｉｎ　ａ　Ｃｏｍｐａ—　

ｎｙ［Ｄ］．Ｂｅｉｊｉｎｇ：Ｂｅｉｊｉｎｇ　Ｕｎｉｖｅｒｓｉｔｙ　ｏｆ　Ｐｏｓｔｓ　ａｎｄ　Ｔｅｌｅ—　

ｃｏｍｍｕｎｉｃａｔｉｏｎｓ，２０１２，５．　

［５］ＪｅｎｋｉｎｓＭ．［２０１５—６—２］．ｈｔｔｐ：／／ｗｉｋｉ．ｊｅｎｋｉｎｓ－ｃｉ．ｏｒｇ／ｄｉｓ—　

ｐｌａｙ／ＪＥＮＫＩＮＳ／Ｍｅｅｔ＋Ｊｅｎｋｉｎｓ．　

［６］林新党，穆加艳．基于Ｊｅｎｋｉｎｓ的持续集成系统研究　

［Ｊ］．雷达与对抗，２０１４，３（３４）：５８—６１．　

ＬＩＮ　Ｘｉｎｄａｎｇ，ＭＵ　Ｊｉａｕａｎ．Ｃｏｎｔｉｎｕｏｕｓ　ｉｎｔｅｇｒａｔｉｏｎ　ｓｙｓ—　

ｔｅｒｎ　ｂａｓｅｄ　ｏｎ　Ｊｅｎｋｉｎｓ［Ｊ］．Ｒａｄａｒ＆ＥＣＭ，２０１４，３（３４）：　

５８—６１．　

［７］Ｊｅｚ　Ｈｕｍｂｌｅ，Ｄａｖｉｄ　Ｆａｒｌｅｙ，乔梁．持续交付发布可靠软　

件的系统方法［Ｍ］．北京：人民邮电出版社，２０１１，１０：　

８９．　

Ｊｅｚ　Ｈｕｍｂｌｅ，Ｄａｖｉｄ　Ｆａｒｌｅｙ，ＱＩＡＮＧ　Ｌｉａｎｇ．Ｃｏｎｔｉｎｕｏｕｓ　

Ｄｅｌｉｖｅｒｙ　Ｒｅｌｉａｂｌｅ　Ｓｏｆｔｗａｒｅ　Ｒｅｌｅａｓｅｓ　Ｔｈｒｏｕｇｈ　Ｂｕｉｌｄ，　

Ｔｅｓｔ，ａｎｄ　Ｄｅｖｅｌｏｐｍｅｎｔ　Ａｕｔｏｍａｔｉｏｎ［Ｍ］．Ｂｅｉｊｉｎｇ；　

Ｐｏｓｔｓ　ａｎｄ　Ｔｅｌｅｃｏｍ　Ｐｒｅｓｓ，２０１１，１Ｏ：８９．　

Ｃ８］马建辉．持续集成的概念与应用分析［Ｊ］．福建电脑，　

２０１０（５）：５８—５９．　

ＭＡ　Ｊｉａｎｈｕｉ．Ｔｈｅ　Ｃｏｎｃｅｐｔ　ａｎｄ　Ａｐｐｌｉｃａｔｉｏｎ　Ａｎａｌｙｓｉｓ　ｏｆ　

Ｃｏｎｔｉｎｕｏｕｓ　Ｉｎｔｅｇｒａｔｉｏｎ［Ｊ］．Ｆｕｊｉａｎ　Ｃｏｍｐｕｔｅｒ，２０１０（５）：　

５８—５９．　

［９２徐仕成，杨邦荣．基于Ｃｒｕｉｓｅ　Ｃｏｎｔｒｏｌ的持续集成实现　

方案［Ｊ］．计算机与数字工程，２００７，３５（４）：１６９—１７５．　

ＸＵ　Ｓｈｉｃｈｅｎｇ，ＹＡＮＧ　Ｂａｎｇｒｏｎｇ．Ｃｏｎｔｉｎｕｏｕｓ　Ｉｎｔｅｇｒａ—　

ｔｉｏｎ　Ｒｅａｌｉｚａｔｉｏｎ　Ｓｃｈｅｍｅ　Ｂａｓｅｄ　ｏｎ　Ｃｒｕｉｓｅ　Ｃｏｎｔｒｏｌ　ＥＪ］．　

Ｃｏｍｐｕｔｅｒ　ａｎｄ　Ｄｉｇｉｔａｌ　Ｅｎｇｉｎｅｅｒｉｎｇ，２００７，３５（４）：１６９—　

１７５．　

［－１０］李俊杰．Ｍａｖｅｎ在企业Ｊａｖａ软件产品中的应用［Ｊ］．电　

脑知识与技术，２０１１（７）：１５６２—１５６３．　

ＬＩ　Ｊｕｎｊｉｅ．Ａｐｐｌｙｉｎｇ　Ｍａｖｅｎ　Ｄｅｖｅｌｏｐｉｎｇ　ＥｎｔｅｒｐｒｉｓｅＪａｖａ　

Ａｐｐｌｉｃａｔｉｏｎ［Ｊ］．Ｃｏｍｐｕｔｅｒ　Ｋｎｏｗｅｄｇｅ　ａｎｄ　Ｔｅｃｈｎｏｌｏ—　

ｇＹ，２０１１（７）：１５６２—１５６３．