那些不加班的開發團隊，都看透了持續整合的四大好處

Martin Fowler 和 Kent Beck 首次提出 Continuous Integration （簡稱CI）：

持續整合是一種軟體開發實踐：許多團隊頻繁地整合他們的工作，每位成員通常進行日常整合，進而每天會有多種整合。每個整合會由自動的構建（包括測試）來儘可能快地檢測錯誤。許多團隊發現這種方法可以顯著的減少整合問題並且可以使團隊開發更加快捷。

持續整合，讓很多開發團隊又「 愛 」又「 恨 」。愛，在於整個流程對專案的交付價值大有裨益，盡最大可能地減少不必要的加班；恨，在於成本過大，部署的困難、工程文化的隔閡。

無論你是堅定的持續整合擁護者，中立派，甚至是 CI 反對者，作為一個高效的開發工具，持續整合是一個非常重要特殊的存在。通過這篇文章，我們來看看持續整合的好處有哪些。

儘早暴露問題，把握開發節奏

在團隊開發中，問題暴露的越早，修復程式碼的成本越低，成功部署的勝算就越大。持續整合高頻率地編譯、測試、審查、部署專案程式碼，這其中程式碼整合是主要的風險來源。要想規避這個風險，只有提早整合，持續而有規律的整合，以此來確保當前程式碼庫的質量，把握開發的程式和節奏。

當然發現問題程式碼，也不要一味地墜入快速的簡單修復之中，要投入時間和精力保持程式碼的整潔、敞亮。

很明顯的一點，使用持續整合後，程式設計師們提交程式碼也會變得更加小心謹慎。想想應該沒人樂意讓其他同事不停地見到自己的分支上 CI 失敗的通知郵件吧:)

避免重複操作，讓流程自動化

工具環境的滯後，加上工作的重複枯燥，讓開發者對寫程式失去新鮮感。

在持續整合過程，一步一步的編譯、測試、審查、部署，牽扯大量重複的工作。搭建持續整合環境，可以讓開發人員不再需要手動地 checkout 程式碼，節省大量的時間和避免不必要的壓力，把精力放在更多有價值的事情上，這樣也可以形成良性的迴圈。

flow.ci 是融入了 workflow 機制的持續整合（CI）服務，也可以理解為自動化流程平臺，除了整合程式碼、編譯、測試之外，還可以整合常用的工具、靈活自定義流程。工程師只需要專注寫程式碼，其他的 build, test, deploy 都可以交給 flow.ci 來完成。一切運轉起來只需要1分鐘!

保持隨時部署，簡化釋出流程

每日高頻率的整合保證了專案隨時處於可部署執行的狀態，如果沒有持續整合，專案釋出之前將不得不手動地整合，然後花費大量精力修復整合問題，弄的團隊成員疲憊不堪。

使用持續整合，幫助我們跨越頻繁部署的障礙。大家都知道，只有保持頻繁部署，讓使用者看到產品的新特性， 才能不斷地磨合優化構建和釋出流程，讓反饋週期更短更有效。

flow.ci 包含各種程式碼質量檢測分析和報告的外掛，可以輕鬆地檢視專案的測試結果。

增強團隊信心，建立工程師文化

無論什麼樣的工程師，都會對存在大量 bug 的程式碼產生恐懼心理，這就是心理學上的的 Broken Windows 綜合症（Broken Windows syndrome）。CI 可以有效防止破窗綜合症，讓開發團隊一點點積累起對產品的信心，對使用技術的保持成就感。

與此同時，持續整合讓每個人都能看到良好的介面和檢視來了解專案的成熟度，讓所有人都知道正在發生什麼。也許更容易增強開發信心，培養團隊良好的工程文化，齊心協力向目標前進。

除了上面我們所總結的 CI 的好處，APIUMTECH 在Top benefits of continuous integration文章中有一張圖說非常全面，分享給大家：

**作為編碼規範的度量尺、程式碼質量的把關者、專案健康的測量儀，CI 可以做的事情還有很多。

歡迎分享你的觀點。**