本文轉載 CodeSheep。
作者受邀參加 Techo Day 騰訊技術開放日線上活動，收穫頗豐，有感而發。
前言
上期 Techo Day 騰訊技術開放日活動講的是「輕量級工具」，這一期主要講的是「雲原生」。
在所有課題裏，個人比較關心的是 CI 設計這個課題——CODING CI 3.0，比傳統 CI 好在哪裏？
傳統 CI 的問題和痛點
CI 的概念
CI 全稱 Continuous Integration，名爲「持續集成」，傳統的 CI 含義指的是代碼倉庫只要有代碼變更（或者說有人想推代碼入庫），就會自動執行預先設計好的檢查、防護流程，運行一系列構建、測試、部署等流程，並最終告知每一步的運行結果，確保人提交上來的代碼沒有問題後，纔有機會將新代碼合併到主幹分支，而主幹分支無論何時都一定是正確可運行的高質量版本，可以隨時交付客戶使用。
持續集成的詞面意思其實某一程度上也道出了該做法思想的精髓：即小步快走，持續地去做代碼集成。
不得不說持續集成在現代軟件研發流程中，扮演了十分重要的角色。
平時的工程中，總有一部分工作是相對機械化，易出錯的（例如打包、部署），我們可以把這部分工作交給機器來做。讓持續集成構建計劃進行自動化的單元測試、代碼檢查、編譯構建、契約測試，甚至自動部署，能夠大大降低開發人員的工作負擔，減少許多不必要的重複勞動，持續提升代碼質量和開發效率。
傳統 CI 問題和痛點
聊到 CI 系統，那不得不提的就是 Jenkins 了，它是一個使用廣泛的持續集成工具。
但是不少團隊或項目使用 Jenkins 系統的目光還侷限於在 Jenkins 上建各種各樣的 Job 來完成 CI 任務，所以依然存在不少痛點，典型的比如：
-
配置繁瑣且不靈活，尤其是對於新拉分支的 CI 部署比較麻煩，配置的可擴展性和可複用性有待提高。
-
傳統的 Jenkins Job 難以靈活高效地並行（包括 Job 間、節點間、任務間、甚至任務內等各個維度的並行），所以任務執行效率有待提高。
-
傳統的 Jenkins Job 日益失控的趨勢讓我們措手不及，Job 太多，CI 腳本太離散，維護成本實在太高了，而且很危險，一旦 Jenkins Server 掛了，一切都 Game Over 了，需要重新搭建了。
-
如今很多的業務上雲了以後，如何對雲端代碼快速構建一個高效的 CI 系統也成了一個必須要面對的問題。
什麼是 CODING CI 3.0
CODING 持續集成是 CODING DevOps 的子產品，其全面兼容 Jenkins 的持續集成服務，支持 Java、Python、Node.js 等主流語言，並且支持 Docker 鏡像構建，圖形化編排，高配集羣多計劃並行構建全面提速您的構建任務。支持主流的 Git 代碼倉庫，包括 CODING 代碼託管、GitHub、GitLab 等等。在構建依賴拉取方面，使用專用網絡優化包括 Maven，NPM 等主流鏡像源，保證拉取速度，進一步提升構建速度。
而如今在這次的活動上，騰訊雲又推出了全新的 CODING CI 3.0。
CODING CI 3.0 是騰訊雲面向雲原生打造的全新 CI 平臺，基於 OverlayFS 的高性能 CI 技術，爲持續構建應用、靈活定製流水線提供高效、穩定的服務保障。
所以接下來就來聊一聊這次發佈的 CODING CI 3.0 的一些特性和優勢。
CODING CI 3.0 特性和設計
通過 YAML 文件聲明流水線
YAML 格式的聲明式配置文件相信大家都不陌生，各種企業級項目裏用得比較頻繁。
而此次的 CODING CI 3.0 同樣支持通過通過 YAML 配置文件的方式來聲明並快速拉起一條流水線，非常便捷，並且易於理解：
master:
push:
- docker:
image: node:14
stages:
- name: 依賴安裝
script: npm install
- name: 測試用例檢查
script: npm test
比如上面這個案例描述的流程如下：
- 聲明瞭在 master 分支在收到 push 事件時（即有新的 Commit 推送到 master 分支）的時候；
- 會選擇以 node:14 Docker 鏡像（opens new window）啓動的容器作爲構建環境；
- 依次執行任務 npm install 和 npm test。
另外，由於該 YAML 配置文件和項目源代碼一樣都作爲倉庫文件，一起被託管和版本控制，所以完全遵循 Pipeline as Code 的思想，這樣後續不管是 CI 流程的協作以及版本追溯都非常易於進行，而且也更利於實現 CI 配置的複用。
這樣一來，設計 CI 流程=設計聲明式配置代碼，所以也非常符合程序設計的思維。
基於容器技術的 CI 設計
我們都知道雲原生時代非常典型的一個代表技術就是容器了，同理雲原生時代的 CI 設計也必須兼容和支持容器技術。
CODING CI 3.0 基於 Docker 技術生態，對構建環境、存儲、插件進行抽象，更徹底地支持 Pipeline as Code。
當然這裏有多個層面的設計思想。
1. Docker image as env
用戶可以通過在配置文件裏直接指定使用所需的 Docker 鏡像，甚至是 Dockerfile，就可以指定 CI 流程中所用到的一些基礎構建環境。
- 通過 Docker 鏡像來指定構建環境
- 通過 Dockerfile 來指定構建環境
2. Docker image as plugins
同時 CODING CI 3.0 也支持在配置文件中使用 Docker 作爲流水線插件，支持使用任意語言編寫插件，從而擴展更多的功能。
同時其也支持直接使用 Docker Hub 上已有的容器插件，目前支持的生態有：Drone Plugins 等。
3. Native docker support
第三個層面就是原生 Docker 服務的支持，包括直接執行各種 Docker 命令以及腳本。
具體來說，一是支持在流水線上直接執行 Docker 命令，另外也支持在流水線上直接使用 docker-compose 編排服務。
基於 OverlayFS 的高性能方案
在上文中也提到，傳統的 CI 流水線中一個很麻煩的問題就是任務的並行和效率，尤其是當代碼倉庫非常龐大的時候。
這時候在拉起多條 CI 流水線時不可避免地就會出現速度慢和效率低的問題。
針對這個問題，在傳統的 CI 實踐中也有一些常見的解決方案，比如：
| 已有的方案 | 存在的問題 |
|---|---|
| 流水線加鎖 | 並行變串行，需要排隊執行 |
| 保留多份緩存，超出併發數時排隊 | 隨着單個流水線使用增多或時長增加，會需要不斷提高併發數，來保證構建速度 |
| 出現併發流水線時，先複製一份緩存 | 隨着緩存數據變大，複製本身的耗時也會越來越大 |
而這次推出的 CODING CI 3.0 則是通過基於 OverlayFS 的高性能方案來解決這個問題。
其本質上是使用緩存，然後主要通過 OverlayFS 技術實現緩存的“瞬間複製”。
這裏通俗來理解就是，第一次執行沒有緩存的時候，所有流程走完一遍，執行 git clone 命令，把整個倉庫克隆下來；但後續的 CI 流水線，只要發現機器上有這個倉庫的代碼，就可以先通過 OverlayFS 技術複製一份緩存來用，然後在緩存的基礎上進行 git fetch 操作，因此每條 CI 流水線都能很快啓動。
這樣一來，即使是上百 GB 容量的倉庫，也都可以在秒級完成代碼克隆。
如下圖所示，當 clone 方式從 git worktree 切換到 OverlayFS 瞬時複製方案後，帶來的效果就是代碼的準備時間大幅度縮短，從而提高效率。
CI+ 遠程開發
我們都知道傳統的本地開發模式有着很多缺陷和不足，突出表現在以下幾點：
- 倉庫多，環境無法相互隔離；
- 開發環境複雜多樣，每個人都需要重新配置；
- 切換辦公機/遠程辦公後，重新配置環境麻煩；
- 克隆代碼和構建速度慢；
- 本地機器性能有限，影響開發效率。
所以此次 CODING CI 3.0 帶來的一項很重要的能力就是支持遠程開發服務運行在 CI 上。
即推出了一套基於 CODING CI 的遠程開發方案，隨時隨地一鍵啓動開發，無需繁瑣的操作，就可以爲開發人員打造出一套現成的環境，從而可以享受無比流暢的編譯構建以及開發測試體驗。
而且不同的人拿到環境，只需要改一下配置，就又可以迅速拉起一套 CI 開發環境，所以非常方便高效。
而用戶只需要通過瀏覽器或者類似 VS Code 這樣的終端軟件即可參與遠程開發。
一旦有 Git 事件或者 Open API 觸發了 CI 流水線，CODING CI 就可以自動創建工作區，並且啓動遠程開發服務。
總結
另外此次 Techo Day 騰訊技術開放日活動所有的資料和課件都整合成了一份《騰訊云云原生工具指南》，裏面詳盡介紹了涵蓋 CODING CI 3.0、遨馳分佈式雲操作系統在內的騰訊雲熱門產品技術原理，可以說非常實用了，感興趣的小夥伴可以掃描下方二維碼，前往資料專區下載查看。
