云計算的普及，不僅改變了目前的 IT 基礎設施與企業系統架構，同時也改變了技術團隊的組織架構和企業內部的研發流程。而持續集成（CI）和持續交付（CD）就是企業內部研發流程提升交付效率的關鍵。

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

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

1. 網易 CI/CD 實踐的背景

據了解，網易的大部分互聯網產品業務團隊都是使用統一的平臺來進行 CI/CD 實踐，目前平臺上運行著數萬個倉庫，活躍倉庫近萬個，同時平臺內還有大量副本數超過數千個的服務，這些服務每天承載著業務方大量的訪問。

為了適應業務發展的節奏，網易內部廣泛推行了敏捷開發，每天通過平臺發布應用的次數達到數萬次，產品迭代節奏快，交付周期短。所有業務使用統一的平臺進行 CI/CD，無需各自搭建，降低成本，使用統一的規范，避免了相同問題的多次采坑。

網易公司內部的 CI/CD 實踐主要是輕舟 CI/CD 平臺，該平臺提供了可視化的流水線編排界面，一次配置，多次運行，支持團隊成員共享配置。每次提交或者合并代碼都會自動觸發流水線的執行，自動將代碼發布到環境上。數據顯示 CI/CD 流水線相比傳統的手工或腳本方式平均效率提升了 5 倍以上，發布效率提升了 8 倍以上。另外通過整合多種自動化測試工具幫助業務方實現高質量的集成。通過可視化度量平臺從多個維度了解構建，部署的相關指標數據，幫助產品提高發布效率。

之前，網易內部有一套從主機部署時代發展過來的自動化部署平臺，但是其對容器部署的支持不友好，部署之前需要先在服務器上部署 agent，注冊到內部 CMDB，再下發指令執行。這樣的執行操作注定了這個平臺在大批量部署場景下會存在性能瓶頸。

基于原平臺存在的性能問題，以及對業務容器化、微服務化演進的判斷，網易研發了新的輕舟 CI/CD 平臺，成為了網易云原生技術棧的重要組成部分，滿足云原生環境下企業在能效、團隊協作效率、產品迭代速度等多方面的需求。

在使用體驗上，輕舟 CI/CD 是一體的，但是在系統架構設計方面，其實是分開的。下面，我們就分別來講講 CI 和 CD 的系統設計。

2. 網易 CI 實踐的整體架構及工具選型

與絕大多數互聯網公司一樣，網易內部各業務方的持續集成也大都是由研發團隊的 QA 負責的，CI 工具選擇了比較常用的 Jenkins，同時在流水線的上下游整合了其它的主流 CI 工具。整個流水線平臺依托于 Kubernetes，基于 K8s 的 CRD（自定義資源）重新設計了流水線上層模型，并通過 Operator 驅動流水線執行過程。

當流水線觸發一次執行時，將會產生一個 PipelineRun 對象，Operator 將會根據對應的流水線預先定義好的階段生成對應的 Job，然后通過 Jenkins 的 API 觸發 Job 執行。Job 執行完成后，將會通過 Webhook 回調上層服務接口，將狀態回寫到 PipelineRun 中，然后觸發下一個階段的執行。

CI 工具選型

傳統的持續集成實踐本身就很占資源，編譯構建對磁盤、CPU，甚至是網絡都有一定的要求，如果在高峰期想要保證持續集成任務能夠及時運行，通常需要預留大量的構建機資源，這不僅會導致資源浪費，同時也需要更多人力來維護管理，成本會很高。

所以，網易技術團隊在進行 CI 工具選型時，就直接圈定了 4 個當前主流的工具，分別是 Travis CI、Circle CI、GitLab CI 和 Jenkins，并詳細對比了 4 個工具。

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

基于以上原因，網易輕舟最終選擇了 Jenkins，但是傳統的 Jenkins 在系統運維、資源管理、使用方式等方面，存在很多問題。例如，Jenkins 的 master-slave 架構比較經典，但由于誕生時間較早，所有配置和數據都是基于文件存儲的（存儲在 Jenkins master 節點 home 目錄下），修改時，會先更新內存，然后異步寫入磁盤，而當底層文件被更新時，Jenkins 并不會自動 reload 更新后的數據，因此，很難做到高可用；Jenkins master 實例對文件目錄是獨占的，不同 Jenkins 實例也無法共享底層存儲...... 因此，網易技術團隊希望能夠在傳統 Jenkins 版本中做出以下改進：

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

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

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

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

3. 網易 CI 實踐的分支管理與協作流程

所有 CI 實踐的源頭一定是代碼變更，好的代碼分支管理和版本變更規范是做好 CI 實踐的前提。網易輕舟是基于 GitFlow 進行代碼管理和協作流程的，主要的階段包括預發驗證、測試驗證和代碼審查、集成、驗證。

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

• develop: 集成分支, 不允許 commit/push, 僅允許來自 feature/* 或 hotfix/v*
• 分支的合并；
• master: 版本分支, 不允許 commit/push, 僅允許來自 release/v*或 hotfix/v*
• 分支的合并, 每次接受合并后必須在其上創建 TAG；
• feature/*: 功能分支, 從 develop 派生, 不允許來自 develop 的合并, 合并到 develop 后刪除；
• release/v1.x.0: 發版更新驗證分支, 從 master 派生, 派生時根據 master 分支 TAG 標記并遞第二位版本號命名。不允許 commit/push, 只允許來自 develop 的合并, 合并到 master 之后刪除；
• hotfix/v1.x.1: 補丁更新驗證分支, 從 master 派生, 派生時根據 master 分支 TAG 標記并遞增第三位版本號命名。允許 commit/push, 不允許 來自 develop 的合并, 合并到 master 后必須再合并到 develop , 合并后刪除。

除此之外，關于 TAG，網易輕舟也有一些特定要求：

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

網易 CI 流程的具體步驟

通常，一個持續集成流程會包括以下步驟：代碼檢出、單元測試、靜態掃描、編譯、構建、鏡像掃描和測試部署。好的持續集成流程一定是面向質量的，所以，在實踐過程中除了工具和流程，還需要做好代碼質量相關的工作。

對于大部分團隊來說，CI 可能是由 QA 維護的，因此在實際使用過程中，會將線下環境的 CI 和線上分離開，線上通常更加注重持續部署，主要由 QA、PE 等角色負責，流程上會簡化一些，更加注重運維規范、上線審核。

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

靜態掃描： 這是流水線至關重要的一環，運行時會將掃描的數據上傳至用戶預先配置好的 SonarQube 平臺，并且通過 SonarQube 的 QualityGate 進行質量卡點，除了 QualityGate，用戶還可以自定義一些流水線特有的卡點規則，并且配置通過郵件、網易 popo 等通知執行結果。

單元測試： 這是 CI 過程中必不可少的一環，CI/CD 流水線整合了常用的 Jacoco 工具，方便用戶在運行單元測試時生成對應的 UT 和覆蓋率報告，報告的內容可以在流水線執行詳情頁查看，同時支持用戶設置單元測試通過率、UT 覆蓋率卡點，并發送相應的郵件通知。

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

鏡像構建： 支持 Docker out of Docker、Kaniko 等多種構建方式，同時整合了網易輕舟 Harbor，集成了 Harbor 的鏡像掃描功能，支持在流水線運行過程中執行鏡像掃描、查看鏡像安全報告，同時支持安全項卡點以及郵件通知等功能。

集成測試：CI/CD 流水線與網易內部自動化測試平臺 GoAPI 做了集成，用戶可以預先在平臺側配置好相應的接口執行集，然后在流水線中選擇對應的執行集執行，并在流水線詳情頁中查看執行集的通過率，同時支持卡點以及郵件通知。

流水線觸發器： 多種觸發器，比如定時觸發、PollSCM、Webhook 以及流水線串聯觸發，其中 Webhook 還額外提供了對 Gitlab、Harbor 的支持，支持從 Gtilab、Harbor 的 payload 中提取相關參數，并在流水線階段中使用。