黃 嵩，豐大軍，胡 戎

(華北計(jì)算機(jī)系統(tǒng)工程研究所，北京 100083)

0 引言

近年來，由于軟件行業(yè)的迅猛發(fā)展，軟件變得越來越復(fù)雜，單靠個(gè)人根本無法完成中大型的項(xiàng)目開發(fā)。而中大型軟件為了解耦，往往還需要分成好幾個(gè)模塊，各個(gè)模塊既需要各自獨(dú)立的功能，也需要合并成一個(gè)整體應(yīng)用，這樣集成就成了軟件開發(fā)中不可或缺的一部分。持續(xù)集成(Continuous Integration，CI)就是讓開發(fā)人員經(jīng)常整合各自的工作結(jié)果，這個(gè)頻率可以自己決定，但是通常是一天一次，以免影響成員的正常開發(fā)。每一次集成都會完成一次自動(dòng)構(gòu)建，用以盡早地發(fā)現(xiàn)開發(fā)過程中的錯(cuò)誤[1-2]。

術(shù)語持續(xù)集成來源于極限編程，它是極限編程的12個(gè)基本原則之一。在開發(fā)實(shí)踐中，經(jīng)常進(jìn)行項(xiàng)目的集成工作有利于使項(xiàng)目保持良好狀態(tài)，增強(qiáng)開發(fā)人員的信心，因此集成工具應(yīng)該繼續(xù)推行[3-4]。

同時(shí)，隨著前端新技術(shù)的不斷推行，持續(xù)集成已經(jīng)不再是僅限于后端開發(fā)過程?，F(xiàn)代前端開發(fā)中的前后端分離、工程化、自動(dòng)化等開發(fā)模式正在變得越來越流行，前端項(xiàng)目還引入了現(xiàn)代軟件工程化的標(biāo)準(zhǔn)環(huán)節(jié)，包括編譯、構(gòu)建和單元測試等，大大提高了前端的開發(fā)效率和業(yè)務(wù)交付能力[5-6]。作為前端工程化中的一環(huán)，持續(xù)集成也漸漸開始在前端項(xiàng)目中使用。

本文拋棄傳統(tǒng)的前端開發(fā)部署方式，使用持續(xù)集成工具Jenkins、構(gòu)建工具Webpack以及Docker容器等工具完成了一個(gè)前端持續(xù)集成系統(tǒng)的自動(dòng)化流水線。

1 傳統(tǒng)軟件開發(fā)

以傳統(tǒng)的瀑布開發(fā)模型為例，一般情況下將軟件開發(fā)過程分為設(shè)計(jì)階段(包括需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì))、開發(fā)階段(代碼編寫)、測試階段(單元測試、端到端測試、功能測試)和運(yùn)維階段。瀑布開發(fā)流程圖如圖1所示，在瀑布模型中，項(xiàng)目開發(fā)的早期階段是無法檢測到無論是需求還是設(shè)計(jì)中的問題的，這樣會導(dǎo)致開發(fā)人員一次次地重復(fù)進(jìn)行上述四個(gè)階段，使得項(xiàng)目不斷地推遲交付，甚至最后無法完成。而且，這些問題只是一部分，最重要的問題是每一步都需要不同的開發(fā)人員手動(dòng)執(zhí)行[7]，導(dǎo)致整個(gè)開發(fā)流程過于冗長，開發(fā)周期很難理想控制。

圖1 瀑布開發(fā)流程圖

其他軟件開發(fā)模型包括螺旋模型、噴泉模型甚至智能模型等近現(xiàn)代的開發(fā)模型雖然對這種原始的瀑布模型做出了各種角度的優(yōu)化，但都只能一定程度解決某個(gè)過程的問題，整個(gè)開發(fā)過程依舊步驟繁多，開發(fā)、測試、運(yùn)維人員需要依次手動(dòng)執(zhí)行流程，不能滿足現(xiàn)代軟件開發(fā)對敏捷化、智能化、自動(dòng)化的需求[8]。

2 持續(xù)集成系統(tǒng)

2.1 系統(tǒng)結(jié)構(gòu)

CI是一個(gè)持續(xù)提交、不斷構(gòu)建的過程。當(dāng)以團(tuán)隊(duì)形式開發(fā)產(chǎn)品時(shí)，首先成員需要各自開發(fā)自己分配到的模塊，在完成各自的工作后，需要將這些代碼集成到統(tǒng)一的代碼庫，這里使用的代碼庫是Gitlab代碼庫。代碼提交后，需要通過使用CI工具Jenkins，配合構(gòu)建工具Webpack一起作為自動(dòng)化構(gòu)建工作的核心。

當(dāng)代碼庫的代碼發(fā)生更改，CI服務(wù)器被觸發(fā)，服務(wù)器會自動(dòng)下載代碼庫的新代碼，并配合構(gòu)建工具在約定好的工程目錄下執(zhí)行自動(dòng)化的代碼打包。這個(gè)過程中只要出現(xiàn)任何問題，CI工具都會通過電子郵件等方式通知訂閱CI服務(wù)器狀況的相關(guān)人員。

基于以上分析，并結(jié)合本項(xiàng)目選用的工具，圖2給出持續(xù)集成系統(tǒng)結(jié)構(gòu)。

圖2 系統(tǒng)結(jié)構(gòu)

2.2 系統(tǒng)組成

持續(xù)集成系統(tǒng)一般需要包含版本庫、構(gòu)建工具、持續(xù)集成平臺等，該系統(tǒng)由以下幾個(gè)模塊組成：

(1)具有版本控制功能的代碼庫

版本控制代碼倉庫是持續(xù)集成系統(tǒng)的基礎(chǔ)，現(xiàn)在通用的代碼庫包括SVN、Gitlab等,本文選用Gitlab作為代碼庫。

(2)構(gòu)建工具

在持續(xù)集成的過程中，構(gòu)建工具的作用是將那些需要手動(dòng)執(zhí)行的操作全部變成自動(dòng)化操作。只要源碼變動(dòng)，構(gòu)建工具就能自動(dòng)將Gitlab庫中的源碼編譯，并打包成可交付的代碼。本文選用Webpack作為構(gòu)建工具。

(3)持續(xù)集成平臺

持續(xù)集成平臺的作用是對整個(gè)持續(xù)集成流程進(jìn)行管理，并實(shí)現(xiàn)流程的自動(dòng)化以及產(chǎn)出結(jié)果的可視化。Jenkins是目前受眾最多的持續(xù)集成平臺，擁有相當(dāng)豐富的插件，方便滿足用戶的各種需求，是持續(xù)集成和持續(xù)交付的核心。本文采用Jenkins作為持續(xù)集成平臺。

(4)Docker

Docker是一個(gè)應(yīng)用容器引擎，可以為應(yīng)用打造一個(gè)輕量級、可移植的容器[9-10]，包括鏡像、倉庫、容器等核心概念。集成工具與構(gòu)建工具打包出來的鏡像文件最終需要推送到Docker的鏡像倉庫中。

(5)前端包管理工具

前端開發(fā)者在項(xiàng)目構(gòu)建時(shí)經(jīng)常會遇到項(xiàng)目配置文件中的依賴包問題，有了包管理工具就可以解決依賴包的各種問題，讓開發(fā)者只需要關(guān)心自己的業(yè)務(wù)代碼。本項(xiàng)目選用yarn和npm這兩個(gè)前端最通用的管理包作為包管理工具。

3 系統(tǒng)流程

本系統(tǒng)是一個(gè)以Jenkins為核心配合構(gòu)建工具生成鏡像，并推送到Docker鏡像倉庫中的保存持續(xù)集成系統(tǒng)。持續(xù)集成的完整流水線包括4個(gè)步驟：檢出代碼、構(gòu)建代碼、鏡像構(gòu)建以及發(fā)布倉庫，流水線如圖3所示。

圖3 流水線

3.1 檢出代碼

當(dāng)開發(fā)人員完成自己的開發(fā)工作后，需要提交代碼到約定好的Gitlab代碼庫，但是在提交之前，至少需要在本地進(jìn)行一次單元測試，完成本地的測試后，才能將本地的新代碼提交到Gitlab代碼庫，完成代碼的檢出。

3.2 構(gòu)建代碼

構(gòu)建代碼是持續(xù)集成的核心，構(gòu)建代碼的過程其實(shí)是Jenkins配合構(gòu)建工具Webpack的打包過程，當(dāng)開發(fā)人員將代碼提交到Gitlab代碼庫，Jenkins平臺檢測到Gitlab庫變化，此時(shí)調(diào)用Gitlab插件，從Gitlab庫上下載開發(fā)者最新提交的代碼，下載完成后通過包管理工具yarn下載項(xiàng)目配置文件package.json中規(guī)定項(xiàng)目所需的依賴包，然后調(diào)用Webpack插件通過build構(gòu)建操作對新代碼進(jìn)行打包,并集成到指定的鏡像地址。

Webpack打包的具體流程由Webpack的配置文件webpack.config.js決定，該文件配置了入口(entry)、出口(output)、loader轉(zhuǎn)換工具以及插件(plugins)，出口文件即Webpack打包出來的文件。打包完成后只需要將出口設(shè)定的output文件上傳到服務(wù)器即可，不需要上傳整個(gè)項(xiàng)目文件。Webpack完成打包后，生成的dist文件就是用于構(gòu)建鏡像的打包文件。

如圖4所示，在本項(xiàng)目執(zhí)行構(gòu)建代碼時(shí)首先給出鏡像倉庫的地址，表示使用該鏡像地址來作為dist文件的運(yùn)行環(huán)境。進(jìn)行編譯時(shí)，首先配置npm淘寶源，設(shè)定鏡像的環(huán)境變量，然后用yarn指令安裝項(xiàng)目所需的所有依賴包，并進(jìn)行build構(gòu)建將整個(gè)項(xiàng)目打包生成dist文件，最終選定node:9-alpine環(huán)境下的dist作為鏡像構(gòu)建的基礎(chǔ)鏡像。

圖4 構(gòu)建代碼

3.3 鏡像構(gòu)建

將代碼構(gòu)建成基礎(chǔ)鏡像后，需要通過配置Dockerfile文件將基礎(chǔ)鏡像產(chǎn)出為一個(gè)可移植使用的完整鏡像。

如圖5所示，本項(xiàng)目中Dockerfile執(zhí)行了如下操作：

(1)FROM命令是Dockerfile的第一個(gè)命令,它的參數(shù)是一個(gè)鏡像地址，表示使用該鏡像地址下的基礎(chǔ)鏡像來啟動(dòng)構(gòu)建鏡像的流程。本環(huán)節(jié)的基礎(chǔ)鏡像就是上一步存放到node:9-alpine環(huán)境中的dist文件，二者一起構(gòu)成基礎(chǔ)鏡像。

(2)RUN命令是Dockerfile執(zhí)行命令的核心部分，顯而易見，其功能就是運(yùn)行其參數(shù)的shell命令，這里表示新建級聯(lián)目錄/usr/src/app。

(3)WORKDIR命令用于設(shè)置運(yùn)行目錄，在執(zhí)行RUN參數(shù)的shell命令前會先進(jìn)入WORKDIR后面的目錄，這一步選定usr/src/app作為運(yùn)行目錄。

(4)COPY命令用于復(fù)制文件，COPY./usr/src/app表示將本地文件從該目錄復(fù)制到鏡像中。

(5)ENTRYPOINT是容器啟動(dòng)時(shí)的執(zhí)行指令，由圖5可知，容器啟動(dòng)時(shí)，執(zhí)行了deploy操作，參照項(xiàng)目配置文件package.json可見：deploy:node build/scripts/start.js，即執(zhí)行打包后的啟動(dòng)文件，完成鏡像構(gòu)建，鏡像名稱為baseinfo。

圖5 鏡像構(gòu)建

3.4 發(fā)布倉庫

最后將Dockerfile構(gòu)建的鏡像baseinfo發(fā)布到Docker的倉庫，在使用時(shí)，可以直接用該Docker鏡像創(chuàng)建Docker容器，如圖6所示。至此完成構(gòu)建前端持續(xù)集成系統(tǒng)的所有流水線。

圖6 鏡像發(fā)布

4 成果檢驗(yàn)

在構(gòu)建完全部流水線流程后，運(yùn)行完整的持續(xù)集成流程來檢驗(yàn)成果。如圖7所示的新版本狀態(tài)，從開發(fā)人員在Gitlab庫提交代碼到發(fā)布新版本成功只需要短短3 min，大大簡化了傳統(tǒng)的開發(fā)、部署、維護(hù)這些繁瑣的過程，提高了項(xiàng)目版本發(fā)布的效率。

圖7 版本狀態(tài)

5 結(jié)束語

持續(xù)集成技術(shù)發(fā)展勢頭迅猛，其作用包括使開發(fā)者能避免重復(fù)操作，讓流程自動(dòng)化，降低開發(fā)風(fēng)險(xiǎn)，保持隨時(shí)部署以及簡化發(fā)布流程等，對于前端開發(fā)者而言，持續(xù)集成可以作為前端工程化、自動(dòng)化、敏捷化的重要戰(zhàn)力，為前端開發(fā)的流程優(yōu)化提供了新的思路。