不可錯過的「持續整合」進階指南

隨著軟體部署的越來越成熟，敏捷、DevOps、CI/CD、Docker 等詞語慢慢出現在工程師的視野中。對於持續整合，業界也沒有一個通用的模式，每個團隊可能習慣的方式和關注點都不一樣。持續整合最關鍵的在於「持續」與「自動化」，這篇文章根據這兩個關鍵點，將 CI 系統分為四個進階過程，來看看你們的團隊處在哪個階段。

第一進階 — 程式碼級別的整合，這是最初的持續整合

在最初的持續整合過程中，不依賴獨立的持續整合工具，一般語言的 build 工具基本內建，比如 java 的maven/gradle/ant/ivy，c/c++ 的make /premake，同時也會加入程式碼風格檢查，靜態程式碼分析，單元測試呼叫，測試覆蓋率檢查等增強功能。接下來的交付準備環境、執行測試、備份舊版本、新版本打標籤以及反饋機制等其他重複的事情全由手工完成 ，會花費很多時間。

第二進階 — 整合 Workflow，基本實現了真正的持續整合

單一的編譯-構建工具逐漸地不能滿足產品快速交付的需求。

整個開發流程的重心從「程式碼級別的整合」轉移到了更自動化地編譯和更完美的測試驗證，致力於在最短的時間內發現問題，縮短開發週期，提高軟體質量。比較常見的一個場景，某個團隊先進行程式碼 Build，觸發單元測試、整合測試，打包測試完畢後再自動部署到測試環境，迴圈往復，形成「編譯-構建-測試-整合-部署到測試環境」的 Workflow.

flow.ci 是融入了 workflow 機制的持續整合（CI）服務，也可以理解為自動化流程平臺，除了整合程式碼、編譯、測試之外，還可以整合常用的工具、靈活自定義流程，幫助你們塑造一個更優秀智慧的持續整合系統。

第三進階 — 持續交付與部署，相對成熟的持續整合系統

在上個進階中，產品是自動部署在測試環境，手動部署在生產環境。之所以這樣選擇，是因為產品在從需求到部署的過程中，會經歷若干種不同的環境，例如 QA 環境、各種自動化測試執行環境、生產環境等。這些環境的搭建、配置、管理，在不同環境中的具體部署是比較複雜的。經常會遇到這麼一種場景：明明在測試環境已經部署成功，但線上環境又出現部署故障。這種情況很可能是生產環境和測試環境的異構造成的。

這時候需要改進你的 CI 系統，建立標準化的環境部署順序，在 Workflow 中增加部署預生產環境並進行灰度整合測試的流程，做好線上環境部署後的迴歸測試。到這裡，已經真正做到了持續交付。

持續交付並不是指軟體每一個改動都要儘快部署到產品環境中，它指的是任何的程式碼修改都可以在任何時候實施部署。而“持續部署”，即自動部署到生產環境中而無需手工干預：得到一個版本後，自動部署該版本到生產環境中。實踐證明，相對獨立快速地部署新功能是一個核心競爭力，可以減輕大規模功能變更的風險。

持續部署，是相對成熟的持續整合系統。

“開發人員提交程式碼，持續整合伺服器獲取程式碼，執行單元測試，根據測試結果決定是否部署到預演環境，如果成功部署到預演環境，進行整體驗收測試，如果測試通過，自動部署到產品環境，全程自動化高效運轉。”

第四進階 — 並行多 workflow 整合以及個性化整合，基於 Docker 的持續整合

隨著專案和團隊規模增長，模組之間依賴關係變得複雜，如何確保程式碼質量的同時，保證程式碼構建的一致性和穩定性，成為一大挑戰。Docker 可以方便地以“容器化”的方式部署，它就像集裝箱一樣，打包了所有依賴，在其他伺服器上部署很容易，不至於換伺服器後發現各種配置檔案散落一地，這樣就解決了編譯時依賴和執行時依賴的問題。

還有一個問題，開發的分支越來越多，每個活躍分支都進行環境部署和整合測試，對持續整合環境的維護成本也就越高。Docker 的快速啟動和映象倉庫是天生為 CI/CD 設計的，以前啟動一個虛擬機器需要幾分鐘，而啟動 Docker 只需要幾秒鐘，讓並行的持續整合才能成為可能。

目前，比較常見的基於 Docker 進行持續整合的流程如下：

• 開發者提交程式碼
• 觸發映象構建
• 構建映象上傳至私有倉庫
• 映象下載至執行機器
• 映象執行

PS：目前 flow.ci 還未支援 Docker. 下圖以 Jenkins 作為 CI/CD 的測試執行引擎，在整個持續整合系統中使用 Docker 的流程圖。

最後，開發團隊面對越來越複雜的環境，需要結合團隊的實際情況，定製出適合的方案，不斷優化整個開發工作流，從而打造出一套更適合的持續整合系統。

---

【參考】

談談持續整合，持續交付，持續部署之間的區別

持續整合系統的演進之路