前端持續集成技術的研究與應用

黃 嵩，豐大軍，胡 戎

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

0 引言

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

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

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

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

1 傳統軟件開發

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

圖1 瀑布開發流程圖

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

2 持續集成系統

2.1 系統結構

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

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

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

圖2 系統結構

2.2 系統組成

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

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

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

(2)構建工具

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

(3)持續集成平臺

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

(4)Docker

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

(5)前端包管理工具

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

3 系統流程

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

圖3 流水線

3.1 檢出代碼

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

3.2 構建代碼

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

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

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

圖4 構建代碼

3.3 鏡像構建

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

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

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

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

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

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

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

圖5 鏡像構建

3.4 發布倉庫

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

圖6 鏡像發布

4 成果檢驗

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

圖7 版本狀態

5 結束語

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