黃 嵩，豐大軍，胡 戎

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

0 引言

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

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

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

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

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

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

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

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

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

2.1 系統(tǒng)結構

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

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

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

圖2 系統(tǒng)結構

2.2 系統(tǒng)組成

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

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

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

(2)構建工具

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

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

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

(4)Docker

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

(5)前端包管理工具

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

3 系統(tǒng)流程

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

圖3 流水線

3.1 檢出代碼

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

3.2 構建代碼

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

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

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

圖4 構建代碼

3.3 鏡像構建

將代碼構建成基礎鏡像后，需要通過配置Dockerfile文件將基礎鏡像產出為一個可移植使用的完整鏡像。

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

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

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

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

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

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

圖5 鏡像構建

3.4 發(fā)布倉庫

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

圖6 鏡像發(fā)布

4 成果檢驗

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

圖7 版本狀態(tài)

5 結束語

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