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

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

第一進階 — 代碼級別的集成，這是最初的持續集成

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

第二進階 — 集成 workflow，基本實現了真正的持續集成

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

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

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

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

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

原文轉自：http://blog.flow.ci/ci_advancedguide/