一种Jenkins的增量部署应用持续交付方法

董志超

（上海浦东发展银行总行信息科技部，上海 200000）

0 引言

持续交付是 DevOps中的一个重要方法，主要研究如何通过自动化方法使得软件部署与交付变得更加便利，其强调通过自动化“软件交付”流程，使构建、发布软件更加快捷、频繁及可靠[1]。持续交付对于满足业务部门的快速迭代诉求、运维人员的应用可靠性诉求以及开发人员集中精力进行开发的诉求都具有十分现实的意义[2-6]。

在企业中，存在大量基于WEBLOGIC、采用传统增量方式部署的 Java EJB应用或者 Java WEB应用，此类应用往往上线时间较久，且由于用户习惯、成本等方面的因素，短时间内无法进行重构，本文称此类应用为增量部署应用。增量部署应用往往在开发、测试、投产环节中需要频繁的手工操作，如，代码编译、版本核对、应用部署等工作。频繁的手工操作对应用的可靠性、交付的时效性都带来了挑战。

在持续交付中的研究与实践中，相关学者与从业人员给出多种解决方案，如周振兴通过GitHub 以及IBM UrbanCode Deploy（UCD）实现了持续交付，并通过Docker技术对系统进行水平扩展[7]；郭健基于 DevOps的 D公司软件项目管理改进研究[8]；陈博,周亦敏对基于 Kubernetes的CI/CD平台的研究[9]。

本文基于 Jenkins持续集成工具，通过整合Subversion版本控制系统、Apache Ant软件编译工具，构建了一个针对增量部署应用的持续交付方案，该方案可以自动化地实现项目全量源代码的下载，增量源代码的编译，交付介质的生成以及部署的功能，可以大幅降低开发人员的不必要的运维工作，提升交付速度和交付介质的质量。Jenkins是一款流行的持续集成平台，在 DevOps理念被普遍接受的背景下，Jenkins在软件交付中已得到广泛应用[10-16]。

1 增量部署应用的持续交付方案

增量部署应用持续交付的目标是打通增量源代码的下载、编译，交付介质的生成以及部署的各个环节，降低人员的参与程度。

本文将增量部署应用的持续交付过程拆解成8个步骤：

Step.1下载项目全量代码；

Step.2获取增量源代码列表；

Step.3对增量源代码文件进行编译；

Step.4对编译结果文件打包，生成交付介质；

Step.5将交付介质分发到应用服务器；

Step.6程序备份；

Step.7交付介质部署；

Step.8应用重启。

为了实现增量部署应用持续交付的目标，本文采用的依赖工具有Jenkins、Subversion、Apache Ant、tar、scp以及 shell，其中，Jenkins用于持续交付流水线上shell脚本的串接；Subversion用于对源代码文件进行管理；Apache Ant用于增量源代码编译；tar作为交付介质的文件格式；scp用于将交付介质分发到应用服务器；shell用于执行中间过程并在应用服务器上完成程序备份、应用部署、以及应用重启的工作。

基于以上分析，增量部署应用持续交付的整体流程如图1所示。

图1 增量部署应用持续交付的整体流程Fig.1 Overall process of incremental deployment application continuous delivery

整体流程分为两部分，其中，源代码的编译、交付介质生成工作是在Jenkins执行机上完成的，程序备份、交付介质部署以及应用重启都是在应用服务器上完成的，而要完成介质分发的工作需要应用服务器和Jenkins执行机打通scp的访问，即允许Jenkins远程调用应用服务器上的shell脚本。

2 增量部署应用的持续交付实现

对于增量部署应用持续交付整体流程的实现，本文在工程层面将持续交付过程的8个步骤进行了整合：将全量源代码的下载工作交由Jenkins上的Subversion插件；将增量源代码的编译工作、生成交付介质的工作整合到Jenkins执行机上一个shell脚本实现；将交付介质分发、程序备份、交付介质部署以及应用重启的工作整合到应用服务器上的一个shell脚本实现，并由Jenkins远程调用该脚本。

2.1 build.sh

build.sh脚本在Jenkins下载全量源代码完成后执行，主要参数有Subversion源代码分支地址、增量源代码起始日期、增量源代码所在的Jenkins工作区、源代码编译后的结果文件目录以及Apache Ant编译时使用的build.xml配置文件所在目录，其主要作用为对增量源代码进行编译并生成交付介质。

该脚本主要逻辑如下：

（1）通过输入参数“Subversion源代码分支地址”和“增量源代码起始日期”获取特定文件类型的源代码列表，并将源代码列表中修改类型的文件生成modifiedFiles.txt；

（2）将该列表生成Apache Ant的ChangeLog文件；

（3）根据Apache Ant编译结果，将编译结果文件生成交付介质patch.tar。

build.sh脚本内容如下（脚本代码中使用“SVN用户”代表Subversion账户信息）：

2.2 delivery.sh

delivery.sh脚本由Jenkins远程调用执行，其部署在应用服务器上，主要职责是交付介质的分发、程序备份、交付介质部署以及应用重启的工作，其主要参数为交付介质所在主机的远程目录、应用程序部署目录、应用启停脚本目录。

该脚本主要逻辑如下：

（1）通过输入参数“交付介质所在主机的远程目录”获取交付介质patch.tar；

（2）根据交付介质中的文件列表生成备份列表文件backupFiles.txt，并根据backupFiles.txt生成程序备份文件backupFiles.tar；

（3）将交付介质拷贝到输入参数“应用程序部署目录”所对应的目录，对交付介质进行解tar操作，实现程序部署；

（4）根据输入参数“应用启停脚本目录”，进行应用的重启。

delivery.sh脚本内容如下（脚本代码中隐去涉及账户以及主机的信息）：

3 案例测试

通过执行Jenkins任务，以验证该方案是否达到预期。验证点主要包括：交付介质的完整性以及备份文件的完整性。

本次测试涉及Subversion中修改的文件1个，新增文件2个以及新增目录1个，其中，修改文件涉及内部类的调整。

对于交付介质的完整性，可以通过表1至表4进行观察、比较，表 1为交付介质中包含目录的条目数，共5个；表2为交付介质中仅文件条目数，共4个；表3为增量源代码列表文件数，共3个；表4为Subversion中修改文件数，共1个，同方案测试预期一致。

表1 交付介质（包含目录）条目数Tab.1 Number of delivery media(including catalog) entries

表2 交付介质（仅文件）条目数Tab.2 Number of delivery media(documents only) entries

表3 增量源代码列表文件数Tab.3 Number of incremental source list files

表4 修改文件数Tab.4 Number of modified files

对于备份文件的完整性，可以通过表 5至 6进行观察、比较，表5为应用服务器备份条目数，共2两个，包含一个内部类的备份；表6为备份文件内部类个数为1个，同方案测试预期一致。

表5 应用服务器备份文件条目数Tab.5 Number of backup file entries of application server

表6 备份文件内部类个数Tab.6 Number of internal classes in backup file

4 结语

本文基于 Jenkins持续集成工具，通过整合Subversion版本控制系统、Apache Ant软件编译工具，构建了一个针对增量部署应用的持续交付方案。但本文仍存在不足之处，如本文只针对Java语言的应用进行了增量部署应用的持续交付方案研究与实践，而在实际生产环境中有多种开发语言和技术架构，还需进一步研究基于其它语言与技术架构的构建工具，以应对更加复杂的应用场景。