云計(jì)算的普及，不僅改變了目前的 IT 基礎(chǔ)設(shè)施與企業(yè)系統(tǒng)架構(gòu)，同時(shí)也改變了技術(shù)團(tuán)隊(duì)的組織架構(gòu)和企業(yè)內(nèi)部的研發(fā)流程。而持續(xù)集成（CI）和持續(xù)交付（CD）就是企業(yè)內(nèi)部研發(fā)流程提升交付效率的關(guān)鍵。

CI/CD 的核心價(jià)值是效能與質(zhì)量。效能提升的關(guān)鍵在于自動(dòng)化，它包含了兩個(gè)方面：一是整個(gè)軟件研發(fā)流程自動(dòng)化，降低人力成本；二是 CI/CD 平臺(tái)在業(yè)務(wù)接入、資源管理、線上支持、問(wèn)題排查等諸多方面實(shí)現(xiàn)自動(dòng)化，從而減少技術(shù)支撐方面的成本。而質(zhì)量保障，一方面是研發(fā)質(zhì)量，需要提供相應(yīng)的質(zhì)量檢查與測(cè)試工具；另一方面是過(guò)程質(zhì)量，CI/CD 平臺(tái)需要能夠持續(xù)采集研發(fā)流程中的指標(biāo)數(shù)據(jù)（如交付頻率、交付周期、交付成功率），建立起一個(gè)完善的質(zhì)量度量體系。

目前各大公司的 CI/CD 平臺(tái)，在工具選型、落地實(shí)現(xiàn)等方面各有不同，此次 InfoQ 采訪到了網(wǎng)易杭州研究院高級(jí)產(chǎn)品開(kāi)發(fā)工程師汪燦豐和高級(jí)服務(wù)端開(kāi)發(fā)工程師梅光輝，他們分享了網(wǎng)易輕舟在 CI/CD 方面的實(shí)踐。由于干貨內(nèi)容太多，我們將這次實(shí)踐分為了上中下三篇內(nèi)容，分別介紹網(wǎng)易的 CI 實(shí)踐、CD 實(shí)踐、測(cè)試自動(dòng)化及 API 版本管理。

1. 網(wǎng)易 CI/CD 實(shí)踐的背景

據(jù)了解，網(wǎng)易的大部分互聯(lián)網(wǎng)產(chǎn)品業(yè)務(wù)團(tuán)隊(duì)都是使用統(tǒng)一的平臺(tái)來(lái)進(jìn)行 CI/CD 實(shí)踐，目前平臺(tái)上運(yùn)行著數(shù)萬(wàn)個(gè)倉(cāng)庫(kù)，活躍倉(cāng)庫(kù)近萬(wàn)個(gè)，同時(shí)平臺(tái)內(nèi)還有大量副本數(shù)超過(guò)數(shù)千個(gè)的服務(wù)，這些服務(wù)每天承載著業(yè)務(wù)方大量的訪問(wèn)。

為了適應(yīng)業(yè)務(wù)發(fā)展的節(jié)奏，網(wǎng)易內(nèi)部廣泛推行了敏捷開(kāi)發(fā)，每天通過(guò)平臺(tái)發(fā)布應(yīng)用的次數(shù)達(dá)到數(shù)萬(wàn)次，產(chǎn)品迭代節(jié)奏快，交付周期短。所有業(yè)務(wù)使用統(tǒng)一的平臺(tái)進(jìn)行 CI/CD，無(wú)需各自搭建，降低成本，使用統(tǒng)一的規(guī)范，避免了相同問(wèn)題的多次采坑。

網(wǎng)易公司內(nèi)部的 CI/CD 實(shí)踐主要是輕舟 CI/CD 平臺(tái)，該平臺(tái)提供了可視化的流水線編排界面，一次配置，多次運(yùn)行，支持團(tuán)隊(duì)成員共享配置。每次提交或者合并代碼都會(huì)自動(dòng)觸發(fā)流水線的執(zhí)行，自動(dòng)將代碼發(fā)布到環(huán)境上。數(shù)據(jù)顯示 CI/CD 流水線相比傳統(tǒng)的手工或腳本方式平均效率提升了 5 倍以上，發(fā)布效率提升了 8 倍以上。另外通過(guò)整合多種自動(dòng)化測(cè)試工具幫助業(yè)務(wù)方實(shí)現(xiàn)高質(zhì)量的集成。通過(guò)可視化度量平臺(tái)從多個(gè)維度了解構(gòu)建，部署的相關(guān)指標(biāo)數(shù)據(jù)，幫助產(chǎn)品提高發(fā)布效率。

之前，網(wǎng)易內(nèi)部有一套從主機(jī)部署時(shí)代發(fā)展過(guò)來(lái)的自動(dòng)化部署平臺(tái)，但是其對(duì)容器部署的支持不友好，部署之前需要先在服務(wù)器上部署 agent，注冊(cè)到內(nèi)部 CMDB，再下發(fā)指令執(zhí)行。這樣的執(zhí)行操作注定了這個(gè)平臺(tái)在大批量部署場(chǎng)景下會(huì)存在性能瓶頸。

基于原平臺(tái)存在的性能問(wèn)題，以及對(duì)業(yè)務(wù)容器化、微服務(wù)化演進(jìn)的判斷，網(wǎng)易研發(fā)了新的輕舟 CI/CD 平臺(tái)，成為了網(wǎng)易云原生技術(shù)棧的重要組成部分，滿足云原生環(huán)境下企業(yè)在能效、團(tuán)隊(duì)協(xié)作效率、產(chǎn)品迭代速度等多方面的需求。

在使用體驗(yàn)上，輕舟 CI/CD 是一體的，但是在系統(tǒng)架構(gòu)設(shè)計(jì)方面，其實(shí)是分開(kāi)的。下面，我們就分別來(lái)講講 CI 和 CD 的系統(tǒng)設(shè)計(jì)。

2. 網(wǎng)易 CI 實(shí)踐的整體架構(gòu)及工具選型

與絕大多數(shù)互聯(lián)網(wǎng)公司一樣，網(wǎng)易內(nèi)部各業(yè)務(wù)方的持續(xù)集成也大都是由研發(fā)團(tuán)隊(duì)的 QA 負(fù)責(zé)的，CI 工具選擇了比較常用的 Jenkins，同時(shí)在流水線的上下游整合了其它的主流 CI 工具。整個(gè)流水線平臺(tái)依托于 Kubernetes，基于 K8s 的 CRD（自定義資源）重新設(shè)計(jì)了流水線上層模型，并通過(guò) Operator 驅(qū)動(dòng)流水線執(zhí)行過(guò)程。

當(dāng)流水線觸發(fā)一次執(zhí)行時(shí)，將會(huì)產(chǎn)生一個(gè) PipelineRun 對(duì)象，Operator 將會(huì)根據(jù)對(duì)應(yīng)的流水線預(yù)先定義好的階段生成對(duì)應(yīng)的 Job，然后通過(guò) Jenkins 的 API 觸發(fā) Job 執(zhí)行。Job 執(zhí)行完成后，將會(huì)通過(guò) Webhook 回調(diào)上層服務(wù)接口，將狀態(tài)回寫(xiě)到 PipelineRun 中，然后觸發(fā)下一個(gè)階段的執(zhí)行。

CI 工具選型

傳統(tǒng)的持續(xù)集成實(shí)踐本身就很占資源，編譯構(gòu)建對(duì)磁盤(pán)、CPU，甚至是網(wǎng)絡(luò)都有一定的要求，如果在高峰期想要保證持續(xù)集成任務(wù)能夠及時(shí)運(yùn)行，通常需要預(yù)留大量的構(gòu)建機(jī)資源，這不僅會(huì)導(dǎo)致資源浪費(fèi)，同時(shí)也需要更多人力來(lái)維護(hù)管理，成本會(huì)很高。

所以，網(wǎng)易技術(shù)團(tuán)隊(duì)在進(jìn)行 CI 工具選型時(shí)，就直接圈定了 4 個(gè)當(dāng)前主流的工具，分別是 Travis CI、Circle CI、GitLab CI 和 Jenkins，并詳細(xì)對(duì)比了 4 個(gè)工具。

其中，Travis CI、CircleCI 在 Github 開(kāi)源項(xiàng)目中使用較多，但不支持私有化部署，不適合公司實(shí)踐；GitLab CI 可以與代碼倉(cāng)庫(kù)無(wú)縫集成，且天然支持 GitOps，但整體生態(tài)目前并不成熟，需要自己制作 builder 的鏡像，并與 Gitlab 深度綁定；Jenkins 作為傳統(tǒng)的 CI 工具，社區(qū)和生態(tài)都比較完善，Jenkins 2.0 版本提供了 Pipeline as code 的特性，可以將 CI 過(guò)程納入版本管理，支持 GitOps。此外，Jenkins 社區(qū)也誕生了 kubernetes-plugin 這樣的插件，可以將流水線的執(zhí)行從傳統(tǒng)的物理機(jī)轉(zhuǎn)移到容器中，再依托 Kubernetes 強(qiáng)大的調(diào)度能力，就可以實(shí)現(xiàn)資源的動(dòng)態(tài)調(diào)度和編排。

基于以上原因，網(wǎng)易輕舟最終選擇了 Jenkins，但是傳統(tǒng)的 Jenkins 在系統(tǒng)運(yùn)維、資源管理、使用方式等方面，存在很多問(wèn)題。例如，Jenkins 的 master-slave 架構(gòu)比較經(jīng)典，但由于誕生時(shí)間較早，所有配置和數(shù)據(jù)都是基于文件存儲(chǔ)的（存儲(chǔ)在 Jenkins master 節(jié)點(diǎn) home 目錄下），修改時(shí)，會(huì)先更新內(nèi)存，然后異步寫(xiě)入磁盤(pán)，而當(dāng)?shù)讓游募桓聲r(shí)，Jenkins 并不會(huì)自動(dòng) reload 更新后的數(shù)據(jù)，因此，很難做到高可用；Jenkins master 實(shí)例對(duì)文件目錄是獨(dú)占的，不同 Jenkins 實(shí)例也無(wú)法共享底層存儲(chǔ)...... 因此，網(wǎng)易技術(shù)團(tuán)隊(duì)希望能夠在傳統(tǒng) Jenkins 版本中做出以下改進(jìn)：

• 結(jié)合 Docker/Kubernetes 云原生技術(shù)棧，解決傳統(tǒng) Jenkins 使用中的痛點(diǎn)；
• 通過(guò)將業(yè)內(nèi)最佳實(shí)踐固化到產(chǎn)品中，解決易用性的問(wèn)題，降低用戶使用門檻，提高接入效率；
• 重新設(shè)計(jì)上層流水線模型，提供更加強(qiáng)大的流水線編排調(diào)度能力；
• 自研流水線底層組件，替代 Jenkins 插件，提供更加靈活的擴(kuò)展能力，方便與公司內(nèi)部系統(tǒng)進(jìn)行集成；
• 提供豐富的企業(yè)級(jí)特性（如認(rèn)證、鑒權(quán)、審計(jì)、告警、通知等），滿足企業(yè)客戶需求；

除了 Jenkins，網(wǎng)易輕舟在整個(gè)流水線的上下游也整合了其它的主流 CI 工具，例如：

• 代碼倉(cāng)庫(kù)：支持 Git/SVN，可以適配絕大多數(shù)代碼托管平臺(tái)，并且對(duì) Gitlab 做了深度適配，例如，支持從 Gitlab Webhookpayload 中提取各類參數(shù)；
• 代碼掃描：集成了 SonarQube，支持了所有主流的編程語(yǔ)言；
• 單元測(cè)試：整合了 Java 中常用的 Jacoco 工具，方便用戶在運(yùn)行單元測(cè)試時(shí)，生成對(duì)應(yīng)的 UT 和覆蓋率報(bào)告；
• 代碼編譯：Java 支持了 Maven/Gradle，并且內(nèi)置了 Nexus 私服，方便做內(nèi)網(wǎng)代理；Node.js 支持了 Npm；Golang 支持了 go mod 緩存加速；
• 鏡像構(gòu)建：支持 Docker out of Docker、Kaniko 兩種構(gòu)建方式，用戶可以根據(jù)自身需求選擇使用；
• 鏡像倉(cāng)庫(kù)：整合了 Harbor，支持 Harbor webhook，并且集成了 Harbor 的鏡像掃描和鏡像復(fù)制功能；
• 容器部署：支持 kubectl 原生部署、升級(jí)，以及輕舟 CI/CD 應(yīng)用部署等多種部署方式；
• 自動(dòng)化測(cè)試：支持 Java 語(yǔ)言常用的 TestNG，同時(shí)整合了網(wǎng)易內(nèi)部的 GoAPI 測(cè)試平臺(tái)，支持在流水線中運(yùn)行指定的接口測(cè)試集，并在執(zhí)行時(shí)輸出測(cè)試報(bào)告；
• 告警通知：集成了郵件發(fā)送、短信告警、網(wǎng)易 POPO 等多種通知方式；

據(jù)了解，目前國(guó)內(nèi)大部分公司對(duì) Jenkins 的使用方式依然停留在 1.0 的時(shí)代，很多人都還在使用 Jenkins 的 UI 配置方式，并沒(méi)有使用到 Jenkins 2.0 提供的 Pipeline as code 功能，并且在使用場(chǎng)景上，大量依賴一些自定義腳本，這些腳本通常由 QA 同學(xué)事先預(yù)置在機(jī)器上，一旦機(jī)器出現(xiàn)宕機(jī)或故障，遷移起來(lái)成本也很高。相較之下，選擇更新版本的 Jenkins，使用更前沿的功能，并適時(shí)輔以其它 CI 工具，往往會(huì)有更好的效果。

3. 網(wǎng)易 CI 實(shí)踐的分支管理與協(xié)作流程

所有 CI 實(shí)踐的源頭一定是代碼變更，好的代碼分支管理和版本變更規(guī)范是做好 CI 實(shí)踐的前提。網(wǎng)易輕舟是基于 GitFlow 進(jìn)行代碼管理和協(xié)作流程的，主要的階段包括預(yù)發(fā)驗(yàn)證、測(cè)試驗(yàn)證和代碼審查、集成、驗(yàn)證。

網(wǎng)易輕舟 CI 實(shí)踐中的主要分支有 devlop 和 master，輔助分支包括 feature/*、release/v1.x.0、hotfix/v1.x.1。

• develop: 集成分支, 不允許 commit/push, 僅允許來(lái)自 feature/* 或 hotfix/v*
• 分支的合并；
• master: 版本分支, 不允許 commit/push, 僅允許來(lái)自 release/v*或 hotfix/v*
• 分支的合并, 每次接受合并后必須在其上創(chuàng)建 TAG；
• feature/*: 功能分支, 從 develop 派生, 不允許來(lái)自 develop 的合并, 合并到 develop 后刪除；
• release/v1.x.0: 發(fā)版更新驗(yàn)證分支, 從 master 派生, 派生時(shí)根據(jù) master 分支 TAG 標(biāo)記并遞第二位版本號(hào)命名。不允許 commit/push, 只允許來(lái)自 develop 的合并, 合并到 master 之后刪除；
• hotfix/v1.x.1: 補(bǔ)丁更新驗(yàn)證分支, 從 master 派生, 派生時(shí)根據(jù) master 分支 TAG 標(biāo)記并遞增第三位版本號(hào)命名。允許 commit/push, 不允許 來(lái)自 develop 的合并, 合并到 master 后必須再合并到 develop , 合并后刪除。

除此之外，關(guān)于 TAG，網(wǎng)易輕舟也有一些特定要求：

• v1.x.0: 發(fā)版更新, release/v* 分支合入 master 后, 在 master 分支上創(chuàng)建；
• v1.x.1: 補(bǔ)丁更新, hotfix/v* 分支合入 master 后, 在 master 分支上創(chuàng)建；
• 此外，為了保證代碼合入的質(zhì)量，我們也制定了對(duì)應(yīng)的代碼 review 原則；
• 任何代碼變更都必須提 mr，不允許直接 push 到 dev/master 等保護(hù)分支；
• 任何變更至少必須有兩名團(tuán)隊(duì)其他成員 review 過(guò)，才能合入 develop、hotfix 分支，只有被團(tuán)隊(duì)接受的代碼才是團(tuán)隊(duì)的代碼。

網(wǎng)易 CI 流程的具體步驟

通常，一個(gè)持續(xù)集成流程會(huì)包括以下步驟：代碼檢出、單元測(cè)試、靜態(tài)掃描、編譯、構(gòu)建、鏡像掃描和測(cè)試部署。好的持續(xù)集成流程一定是面向質(zhì)量的，所以，在實(shí)踐過(guò)程中除了工具和流程，還需要做好代碼質(zhì)量相關(guān)的工作。

對(duì)于大部分團(tuán)隊(duì)來(lái)說(shuō)，CI 可能是由 QA 維護(hù)的，因此在實(shí)際使用過(guò)程中，會(huì)將線下環(huán)境的 CI 和線上分離開(kāi)，線上通常更加注重持續(xù)部署，主要由 QA、PE 等角色負(fù)責(zé)，流程上會(huì)簡(jiǎn)化一些，更加注重運(yùn)維規(guī)范、上線審核。

代碼檢出： 通常需要在流水線中配置代碼源、ssh 秘鑰以及代碼分支等信息，為了優(yōu)化代碼檢出性能，CI/CD 流水線會(huì)采用的 git 淺拷貝的方式來(lái)加速整個(gè)過(guò)程。

靜態(tài)掃描： 這是流水線至關(guān)重要的一環(huán)，運(yùn)行時(shí)會(huì)將掃描的數(shù)據(jù)上傳至用戶預(yù)先配置好的 SonarQube 平臺(tái)，并且通過(guò) SonarQube 的 QualityGate 進(jìn)行質(zhì)量卡點(diǎn)，除了 QualityGate，用戶還可以自定義一些流水線特有的卡點(diǎn)規(guī)則，并且配置通過(guò)郵件、網(wǎng)易 popo 等通知執(zhí)行結(jié)果。

單元測(cè)試： 這是 CI 過(guò)程中必不可少的一環(huán)，CI/CD 流水線整合了常用的 Jacoco 工具，方便用戶在運(yùn)行單元測(cè)試時(shí)生成對(duì)應(yīng)的 UT 和覆蓋率報(bào)告，報(bào)告的內(nèi)容可以在流水線執(zhí)行詳情頁(yè)查看，同時(shí)支持用戶設(shè)置單元測(cè)試通過(guò)率、UT 覆蓋率卡點(diǎn)，并發(fā)送相應(yīng)的郵件通知。

代碼編譯： 支持大部分主流的編程語(yǔ)言，比如 Java、Node.js、C++、Golang 等，并且針對(duì)各類語(yǔ)言做了相應(yīng)的編譯加速方案，支持 Maven、Gradle、C++、Go mod 構(gòu)建緩存。

鏡像構(gòu)建： 支持 Docker out of Docker、Kaniko 等多種構(gòu)建方式，同時(shí)整合了網(wǎng)易輕舟 Harbor，集成了 Harbor 的鏡像掃描功能，支持在流水線運(yùn)行過(guò)程中執(zhí)行鏡像掃描、查看鏡像安全報(bào)告，同時(shí)支持安全項(xiàng)卡點(diǎn)以及郵件通知等功能。

集成測(cè)試：CI/CD 流水線與網(wǎng)易內(nèi)部自動(dòng)化測(cè)試平臺(tái) GoAPI 做了集成，用戶可以預(yù)先在平臺(tái)側(cè)配置好相應(yīng)的接口執(zhí)行集，然后在流水線中選擇對(duì)應(yīng)的執(zhí)行集執(zhí)行，并在流水線詳情頁(yè)中查看執(zhí)行集的通過(guò)率，同時(shí)支持卡點(diǎn)以及郵件通知。

流水線觸發(fā)器： 多種觸發(fā)器，比如定時(shí)觸發(fā)、PollSCM、Webhook 以及流水線串聯(lián)觸發(fā)，其中 Webhook 還額外提供了對(duì) Gitlab、Harbor 的支持，支持從 Gtilab、Harbor 的 payload 中提取相關(guān)參數(shù)，并在流水線階段中使用。