實踐者的 DevOps 之路(3. 持續集成 CI)

在上一篇中我們談到了分支模型，如果說分支模型是 DevOps 實踐的開始，那麼 CI 就是 DevOps 核心實踐，沒有 CI 保障的 DevOps 無異於盲人騎瞎馬，承擔了巨大的風險卻沒有任何的收益。那麼如何開始 CI ，如何確保 CI 在 DevOps 中發揮更好的作用，從而推動整個 DevOps 的進步呢？希望本文會給你一些幫助。

自動化

CI 的第一步應該將你項目整個構建的過程自動化，典型的 CI 流程至少包括以下幾個步驟：

從源碼倉庫簽出最新的代碼
靜態分析，檢查最新的代碼是否存在潛在的 bug 並符合項目的編碼規範
編譯源碼
運行單元測試
運行集成測試
打包

自動化的優點毋庸置疑，能夠極大的提升項目效率，將開發運維人員從繁瑣的手工操作中解放出來，並且大大降低出錯的概率。

很多項目中運維人員通過自己編寫 shell 腳本來完成項目的自動化集成，這的確比完全手工執行好了很多，但是這仍然遠遠不夠。首先 shell 腳本是依賴於某個操作系統環境或是某個特定的 shell 版本。其次，shell 腳本相對不易維護，如果沒有把 shell 腳本放入版本管理中，那麼當項目越來越複雜後，shell 腳本本身也就很難管理，非常容易出錯了。因此在 CI 自動化的過程中我建議採用以下的一些實踐：

使用 Jenkins 這樣的工具管理整個 CI 流程
使用類似 Jenkinsfile 的 DSL 配置項目的構建流程
儘量使用 Python 這樣的高級語言運行構建的各種任務，或者使用 Ansible 這樣的框架管理基礎設施
將所有的 CI 相關的代碼都放入版本管理中，視爲與源代碼相同的資產

理想狀態下 CI 的第一階段應該做到「一鍵集成」：點擊 CI 系統中的按鈕就會完成所有的 CI 任務，生成可以發佈的二進制包。這纔是自動化應該有的狀態。

CI 的頻率

自動化帶來的另一項優點就是我們能夠隨時觸發 CI 的運行。從系統化思考的角度來看 CI，CI 其實帶來了的是快速反饋的循環。當項目的任何一點發生變化時(例如源碼，配置參數，依賴的第三方類庫等)，就應該觸發 CI 的運行，檢查整個項目是否正常。

參考之前提到的實踐者的 DevOps 之路(2. 邁出第一步: 分支模型)，如果我們使用類似基於主幹開發的分支模型是，應該將 CI 運行的時機與 commit 掛鉤。即每次代碼的 commit 都應該觸發 CI 的任務。這樣做的目的在於最小化的反饋當前項目的健康狀態，讓整個團隊不會偏離主航道。而不同分支之間的 PR 合併也應該觸發 CI 的執行，原則就是當某個分支上的代碼發生更新時就應該立即觸發 CI。

從上面可以看到，代碼提交的頻率對 CI 也是有一定影響的。如果整個團隊的 User Story 的粒度不合理，或者程序員的開發習慣不好，總是集中，一次性的提交大量代碼，那麼 CI 的效果也會大打折扣。因此在開始實踐 CI 的同時不要忘了在團隊內普及開發的最佳實踐和良好習慣。

爲什麼我的 CI 沒什麼效果？

很多項目中，客戶一開始就告訴我，我們是有 CI 的，每天都要集成好幾十次，但是效果卻差強人意，並沒有很好的提升項目交付的質量。在深入查看客戶的 CI 之後，我發現問題的答案很明顯：缺乏足夠的自動化測試！

從下圖看一個典型的 CI 構建流水線，我們不難發現自動化測試是必不可少的一個環節，我個人認爲應該是 CI 中最重要的一個環節。如果拋開測試，你的 CI 到底做了些什麼呢？靜態分析，編譯，打包？並不是說這些不重要，只是自動化測試提供了更多的價值。

思考一下，自動化測試爲你的項目提供了一張「安全網」，任何一點項目上的變動都會觸發這些測試用例的執行，作爲某種形式的迴歸測試，可以讓你不必擔心新功能的引入導致新的缺陷。大部分的技術管理者往往只關注與是否使用 CI，卻疏忽了 CI 的核心價值與所需的基礎支持。如果沒有一個覆蓋率較高的自動化測試保障，CI 的價值會大大降低，並不能起到應有的作用。

如果發現自己的項目已經有了 CI，但是交付質量仍然堪憂的話，不妨檢查一下自己的單元測試是否足夠，集成測試有沒有自動化，可能這纔是 CI 背後的真正問題。

不要讓 CI 淪爲「擺設」

項目實施 DevOps，CI 的初期，許多原因都可能造成 CI 的構建失敗。比較常見的是因爲增加了對代碼規範的靜態檢查，而開發人員在初期無法適應，提交的代碼不符合編碼要求，從而導致 CI 構建失敗。

當項目遇到頻繁的 CI 構建失敗時，我們應該像精益中所提倡的，在出現缺陷時果斷的「拉燈」。要求造成構建失敗的開發人員在修復問題的前提下再開始手上的工作，修復 CI 的失敗永遠是團隊優先級最高的任務！

我在許多項目中都曾見到過形同虛設的 CI，構建的界面永遠是紅色的，沒有人關心 CI 究竟出現了什麼問題，最終 CI 淪爲了一個自動化的打包工具。此時的 CI 已經陷入了所謂的「破窗理論」，當構建失敗對於整個團隊而言已經見怪不怪的時候，CI 已經喪失了它存在的意義和作用。因此作爲技術管理者，應該讓整個團隊意識到 CI 失敗的重要性，要求無論何時 CI 都應該保持綠色。