不可錯過的「持續集成」進階指南

隨着軟件部署的愈來愈成熟，敏捷、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 的流程圖。

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

---

【參考】

談談持續集成，持續交付，持續部署之間的區別

持續集成系統的演進之路