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

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 能夠作的事情還有不少。

歡迎分享你的觀點。