一種Jenkins的增量部署應(yīng)用持續(xù)交付方法

董志超

（上海浦東發(fā)展銀行總行信息科技部，上海 200000）

0 引言

持續(xù)交付是 DevOps中的一個(gè)重要方法，主要研究如何通過自動(dòng)化方法使得軟件部署與交付變得更加便利，其強(qiáng)調(diào)通過自動(dòng)化“軟件交付”流程，使構(gòu)建、發(fā)布軟件更加快捷、頻繁及可靠[1]。持續(xù)交付對于滿足業(yè)務(wù)部門的快速迭代訴求、運(yùn)維人員的應(yīng)用可靠性訴求以及開發(fā)人員集中精力進(jìn)行開發(fā)的訴求都具有十分現(xiàn)實(shí)的意義[2-6]。

在企業(yè)中，存在大量基于WEBLOGIC、采用傳統(tǒng)增量方式部署的 Java EJB應(yīng)用或者 Java WEB應(yīng)用，此類應(yīng)用往往上線時(shí)間較久，且由于用戶習(xí)慣、成本等方面的因素，短時(shí)間內(nèi)無法進(jìn)行重構(gòu)，本文稱此類應(yīng)用為增量部署應(yīng)用。增量部署應(yīng)用往往在開發(fā)、測試、投產(chǎn)環(huán)節(jié)中需要頻繁的手工操作，如，代碼編譯、版本核對、應(yīng)用部署等工作。頻繁的手工操作對應(yīng)用的可靠性、交付的時(shí)效性都帶來了挑戰(zhàn)。

在持續(xù)交付中的研究與實(shí)踐中，相關(guān)學(xué)者與從業(yè)人員給出多種解決方案，如周振興通過GitHub 以及IBM UrbanCode Deploy（UCD）實(shí)現(xiàn)了持續(xù)交付，并通過Docker技術(shù)對系統(tǒng)進(jìn)行水平擴(kuò)展[7]；郭健基于 DevOps的 D公司軟件項(xiàng)目管理改進(jìn)研究[8]；陳博,周亦敏對基于 Kubernetes的CI/CD平臺(tái)的研究[9]。

本文基于 Jenkins持續(xù)集成工具，通過整合Subversion版本控制系統(tǒng)、Apache Ant軟件編譯工具，構(gòu)建了一個(gè)針對增量部署應(yīng)用的持續(xù)交付方案，該方案可以自動(dòng)化地實(shí)現(xiàn)項(xiàng)目全量源代碼的下載，增量源代碼的編譯，交付介質(zhì)的生成以及部署的功能，可以大幅降低開發(fā)人員的不必要的運(yùn)維工作，提升交付速度和交付介質(zhì)的質(zhì)量。Jenkins是一款流行的持續(xù)集成平臺(tái)，在 DevOps理念被普遍接受的背景下，Jenkins在軟件交付中已得到廣泛應(yīng)用[10-16]。

1 增量部署應(yīng)用的持續(xù)交付方案

增量部署應(yīng)用持續(xù)交付的目標(biāo)是打通增量源代碼的下載、編譯，交付介質(zhì)的生成以及部署的各個(gè)環(huán)節(jié)，降低人員的參與程度。

本文將增量部署應(yīng)用的持續(xù)交付過程拆解成8個(gè)步驟：

Step.1下載項(xiàng)目全量代碼；

Step.2獲取增量源代碼列表；

Step.3對增量源代碼文件進(jìn)行編譯；

Step.4對編譯結(jié)果文件打包，生成交付介質(zhì)；

Step.5將交付介質(zhì)分發(fā)到應(yīng)用服務(wù)器；

Step.6程序備份；

Step.7交付介質(zhì)部署；

Step.8應(yīng)用重啟。

為了實(shí)現(xiàn)增量部署應(yīng)用持續(xù)交付的目標(biāo)，本文采用的依賴工具有Jenkins、Subversion、Apache Ant、tar、scp以及 shell，其中，Jenkins用于持續(xù)交付流水線上shell腳本的串接；Subversion用于對源代碼文件進(jìn)行管理；Apache Ant用于增量源代碼編譯；tar作為交付介質(zhì)的文件格式；scp用于將交付介質(zhì)分發(fā)到應(yīng)用服務(wù)器；shell用于執(zhí)行中間過程并在應(yīng)用服務(wù)器上完成程序備份、應(yīng)用部署、以及應(yīng)用重啟的工作。

基于以上分析，增量部署應(yīng)用持續(xù)交付的整體流程如圖1所示。

圖1 增量部署應(yīng)用持續(xù)交付的整體流程Fig.1 Overall process of incremental deployment application continuous delivery

整體流程分為兩部分，其中，源代碼的編譯、交付介質(zhì)生成工作是在Jenkins執(zhí)行機(jī)上完成的，程序備份、交付介質(zhì)部署以及應(yīng)用重啟都是在應(yīng)用服務(wù)器上完成的，而要完成介質(zhì)分發(fā)的工作需要應(yīng)用服務(wù)器和Jenkins執(zhí)行機(jī)打通scp的訪問，即允許Jenkins遠(yuǎn)程調(diào)用應(yīng)用服務(wù)器上的shell腳本。

2 增量部署應(yīng)用的持續(xù)交付實(shí)現(xiàn)

對于增量部署應(yīng)用持續(xù)交付整體流程的實(shí)現(xiàn)，本文在工程層面將持續(xù)交付過程的8個(gè)步驟進(jìn)行了整合：將全量源代碼的下載工作交由Jenkins上的Subversion插件；將增量源代碼的編譯工作、生成交付介質(zhì)的工作整合到Jenkins執(zhí)行機(jī)上一個(gè)shell腳本實(shí)現(xiàn)；將交付介質(zhì)分發(fā)、程序備份、交付介質(zhì)部署以及應(yīng)用重啟的工作整合到應(yīng)用服務(wù)器上的一個(gè)shell腳本實(shí)現(xiàn)，并由Jenkins遠(yuǎn)程調(diào)用該腳本。

2.1 build.sh

build.sh腳本在Jenkins下載全量源代碼完成后執(zhí)行，主要參數(shù)有Subversion源代碼分支地址、增量源代碼起始日期、增量源代碼所在的Jenkins工作區(qū)、源代碼編譯后的結(jié)果文件目錄以及Apache Ant編譯時(shí)使用的build.xml配置文件所在目錄，其主要作用為對增量源代碼進(jìn)行編譯并生成交付介質(zhì)。

該腳本主要邏輯如下：

（1）通過輸入?yún)?shù)“Subversion源代碼分支地址”和“增量源代碼起始日期”獲取特定文件類型的源代碼列表，并將源代碼列表中修改類型的文件生成modifiedFiles.txt；

（2）將該列表生成Apache Ant的ChangeLog文件；

（3）根據(jù)Apache Ant編譯結(jié)果，將編譯結(jié)果文件生成交付介質(zhì)patch.tar。

build.sh腳本內(nèi)容如下（腳本代碼中使用“SVN用戶”代表Subversion賬戶信息）：

2.2 delivery.sh

delivery.sh腳本由Jenkins遠(yuǎn)程調(diào)用執(zhí)行，其部署在應(yīng)用服務(wù)器上，主要職責(zé)是交付介質(zhì)的分發(fā)、程序備份、交付介質(zhì)部署以及應(yīng)用重啟的工作，其主要參數(shù)為交付介質(zhì)所在主機(jī)的遠(yuǎn)程目錄、應(yīng)用程序部署目錄、應(yīng)用啟停腳本目錄。

該腳本主要邏輯如下：

（1）通過輸入?yún)?shù)“交付介質(zhì)所在主機(jī)的遠(yuǎn)程目錄”獲取交付介質(zhì)patch.tar；

（2）根據(jù)交付介質(zhì)中的文件列表生成備份列表文件backupFiles.txt，并根據(jù)backupFiles.txt生成程序備份文件backupFiles.tar；

（3）將交付介質(zhì)拷貝到輸入?yún)?shù)“應(yīng)用程序部署目錄”所對應(yīng)的目錄，對交付介質(zhì)進(jìn)行解tar操作，實(shí)現(xiàn)程序部署；

（4）根據(jù)輸入?yún)?shù)“應(yīng)用啟停腳本目錄”，進(jìn)行應(yīng)用的重啟。

delivery.sh腳本內(nèi)容如下（腳本代碼中隱去涉及賬戶以及主機(jī)的信息）：

3 案例測試

通過執(zhí)行Jenkins任務(wù)，以驗(yàn)證該方案是否達(dá)到預(yù)期。驗(yàn)證點(diǎn)主要包括：交付介質(zhì)的完整性以及備份文件的完整性。

本次測試涉及Subversion中修改的文件1個(gè)，新增文件2個(gè)以及新增目錄1個(gè)，其中，修改文件涉及內(nèi)部類的調(diào)整。

對于交付介質(zhì)的完整性，可以通過表1至表4進(jìn)行觀察、比較，表 1為交付介質(zhì)中包含目錄的條目數(shù)，共5個(gè)；表2為交付介質(zhì)中僅文件條目數(shù)，共4個(gè)；表3為增量源代碼列表文件數(shù)，共3個(gè)；表4為Subversion中修改文件數(shù)，共1個(gè)，同方案測試預(yù)期一致。

表1 交付介質(zhì)（包含目錄）條目數(shù)Tab.1 Number of delivery media(including catalog) entries

表2 交付介質(zhì)（僅文件）條目數(shù)Tab.2 Number of delivery media(documents only) entries

表3 增量源代碼列表文件數(shù)Tab.3 Number of incremental source list files

表4 修改文件數(shù)Tab.4 Number of modified files

對于備份文件的完整性，可以通過表 5至 6進(jìn)行觀察、比較，表5為應(yīng)用服務(wù)器備份條目數(shù)，共2兩個(gè)，包含一個(gè)內(nèi)部類的備份；表6為備份文件內(nèi)部類個(gè)數(shù)為1個(gè)，同方案測試預(yù)期一致。

表5 應(yīng)用服務(wù)器備份文件條目數(shù)Tab.5 Number of backup file entries of application server

表6 備份文件內(nèi)部類個(gè)數(shù)Tab.6 Number of internal classes in backup file

4 結(jié)語

本文基于 Jenkins持續(xù)集成工具，通過整合Subversion版本控制系統(tǒng)、Apache Ant軟件編譯工具，構(gòu)建了一個(gè)針對增量部署應(yīng)用的持續(xù)交付方案。但本文仍存在不足之處，如本文只針對Java語言的應(yīng)用進(jìn)行了增量部署應(yīng)用的持續(xù)交付方案研究與實(shí)踐，而在實(shí)際生產(chǎn)環(huán)境中有多種開發(fā)語言和技術(shù)架構(gòu)，還需進(jìn)一步研究基于其它語言與技術(shù)架構(gòu)的構(gòu)建工具，以應(yīng)對更加復(fù)雜的應(yīng)用場景。