持續整合是一種軟體開發實踐：許多團隊頻繁地整合他們的工作，每位成員通常進行日常整合，進而每天會有多種整合。每個整合會由自動的構建（包括測試）來盡可能快地檢測錯誤。許多團隊發現這種方法可以顯著的減少整合問題並且可以使團隊開發更加快捷。持續整合，讓很多開發團隊又 「 愛 」 又 「 恨 」 。愛，在於整個流程對專案的交付價值大有裨益，盡最大可能地減少不必要的加班；恨，在於成本過大，部署的困難、工程文化的隔閡。
無論你是堅定的持續整合擁護者，中立派，甚至是 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 可以做的事情還有很多。
那些不加班的開發團隊，都看透了持續整合的四大好處
martin fowler 和 kent beck 首次提出 continuous integration 簡稱ci 持續整合是一種軟體開發實踐 許多團隊頻繁地整合他們的工作，每位成員通常進行日常整合，進而每天會有多種整合。每個整合會由自動的構建 包括測試 來盡可能快地檢測錯誤。許多團隊發現這種方法...
加班與不加班 公司的選擇
根據本人近些年的工作經驗以及多次的面試經歷，就軟體測試工程師這個職位來說，我覺得相對來說公司使用b s架構的加班頻率高於做c s架構的 b s架構的公司，很大一部分都是和網頁相關的，這種模式的專案一般都具有專案周期短，實時性要求比較高，在此種專案中發現的問題，一般都需要及時的修復，而且版次發布也比較...
加班與不加班 公司的選擇
根據本人近些年的工作經驗以及多次的面試經歷，就軟體測試工程師這個職位來說，我覺得相對來說公司使用b s架構的加班頻率高於做c s架構的 b s架構的公司，很大一部分都是和網頁相關的，這種模式的專案一般都具有專案周期短，實時性要求比較高，在此種專案中發現的問題，一般都需要及時的修復，而且版次發布也比較...