摘要： DevOps 一詞源于 Development 和 Operations 的組合，即將軟件交付過程中開發與測試運維的環節通過工具鏈打通，并通過自動化的測試與監控，減少團隊的時間損耗...

DevOps 一詞源于 Development 和 Operations 的組合，即將軟件交付過程中開發與測試運維的環節通過工具鏈打通，并通過自動化的測試與監控，減少團隊的時間損耗，更加高效穩定地交付制品。

隨著騰訊文檔的項目規模越來越大，功能特性與維護人員越來越多，特性交付頻率與軟件質量之間的矛盾日漸尖銳，如何平衡兩者成為了目前團隊亟需的一個重點，于是，落地一個完善的 DevOps 工具鏈便被提上日程。

當我們在談論 CI 時，我們在談論什么

CI（Continuous Integration），即持續集成，指頻繁地（一天多次）將代碼集成到主干的行為。

注意，這里既包含持續將代碼集成到主干的含義，也包含持續將源碼生成可供實際使用的制品的過程。因此，我們需要通過 CI，自動化地保證代碼的質量，并對其構建產物轉換生成可用制品供下一階段調用。

因此，在 CI 階段，我們至少有如下階段需要實現：

1. 靜態代碼檢查

這其中包括，ESLINT/TSLINT 靜態語法檢查，驗證 git commit message 是否符合規范，提交文件是否有對應 owner 可以 review 等等。這些靜態檢查不需要編譯過程，直接掃描源代碼就可以完成。

2. 單元測試/集成測試/E2E 測試

自動化測試這一環節是保障制品質量的關鍵。測試用例的覆蓋率及用例質量直接決定了構建產物的質量，因此，全面且完善的測試用例也是實現持續交付的必備要素。

3. 編譯并整理產物

在中小型項目中，這一步通常會被直接省略，直接將構建產物交由部署環節實現。但對于大型項目來說，多次頻繁的提交構建會產生數量龐大的構建產物，需要得到妥善的管理。產物到制品的建立我們接下來會有詳細講解。

利于集成的工作流設計

在正式接入 CI 前，我們需要規劃好一種新的工作流，以適應項目切換為高頻集成后可能帶來的問題與難點。這里涉及到的改造層面非常多，除了敦促開發人員習慣的轉變以及進行新流程的培訓外，我們主要關心的是源碼倉庫的更新觸發持續集成步驟的方式。

1. 流水線的組織形式

我們需要一個合適的組織形式來管理一條 CI 流水線該在什么階段執行什么任務。

市面上有非常多的 CI 工具可以進行選擇，仔細觀察就會發現，無論是 Drone 這樣的新興輕量的工具，亦或是老牌的 Jenkins 等，都原生或通過插件方式支持了這樣一個特性：Configuration as Code，即使用配置文件管理流水線。

這樣做的好處是相當大的。首先，它不再需要一個 web 頁面專門用于流水線管理，這對于平臺方來說無疑減少了維護成本。其次對于使用方來說，將流水線配置集成在源碼倉庫中，享受與源碼同步升級的方式，使得 CI 流程也能使用 git 的版本管理進行規范與審計溯源。

確立了流水線的組織形式后，我們還需要考慮版本的發布模式以及源碼倉庫的分支策略，這直接決定了我們該以什么樣的方式規劃流水線進行代碼集成。

2. 版本發布模式的取舍

在《持續交付 2.0》一書中提到，版本發布模式有三要素：交付時間、特性數量以及交付質量。