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

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

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

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

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

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

因此，在 CI 階段，我們至少有如下階段需要實現(xiàn)：

1. 靜態(tài)代碼檢查

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

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

自動化測試這一環(huán)節(jié)是保障制品質(zhì)量的關(guān)鍵。測試用例的覆蓋率及用例質(zhì)量直接決定了構(gòu)建產(chǎn)物的質(zhì)量，因此，全面且完善的測試用例也是實現(xiàn)持續(xù)交付的必備要素。

3. 編譯并整理產(chǎn)物

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

利于集成的工作流設(shè)計

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

1. 流水線的組織形式

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

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

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

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

2. 版本發(fā)布模式的取舍

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