Martin Fowler 和 Kent Beck 首次提出 Continuous Integration （簡稱CI）：
持續集成是一種軟件開發實踐：許多團隊頻繁地集成他們的工作，每位成員通常進行日常集成，進而每天會有多種集成。每個集成會由自動的構建（包括測試）來盡可能快地檢測錯誤。許多團隊發現這種方法可以顯著的減少集成問題並且可以使團隊開發更加快捷。
持續集成，讓很多開發團隊又「 愛 」又「 恨 」。愛，在於整個流程對項目的交付價值大有裨益，盡最大可能地減少不必要的加班；恨，在於成本過大，部署的困難、工程文化的隔閡。
盡早暴露問題，把握開發節奏
在團隊開發中，問題暴露的越早，修復代碼的成本越低，成功部署的勝算就越大。持續集成高頻率地編譯、測試、審查、部署項目代碼，這其中代碼集成是主要的風險來源。要想規避這個風險，只有提早集成，持續而有規律的集成，以此來確保當前代碼庫的質量，把握開發的進程和節奏。
當然發現問題代碼，也不要一味地墜入快速的簡單修復之中，要投入時間和精力保持代碼的整潔、敞亮。
很明顯的一點，使用持續集成后，程序員們提交代碼也會變得更加小心謹慎。想想應該沒人樂意讓其他同事不停地見到自己的分支上 CI 失敗的通知郵件吧
避免重復操作，讓流程自動化
工具環境的滯后，加上工作的重復枯燥，讓開發者對寫程序失去新鮮感。
在持續集成過程，一步一步的編譯、測試、審查、部署，牽扯大量重復的工作。搭建持續集成環境，可以讓開發人員不再需要手動地 checkout 代碼，節省大量的時間和避免不必要的壓力，把精力放在更多有價值的事情上，這樣也可以形成良性的循環。
保持隨時部署，簡化發布流程
無論什么樣的工程師，都會對存在大量 bug 的代碼產生恐懼心理，這就是心理學上的的 Broken Windows 綜合症（Broken Windows syndrome）。CI 可以有效防止破窗綜合症，讓開發團隊一點點積累起對產品的信心，對使用技術的保持成就感。
與此同時，持續集成讓每個人都能看到良好的界面和視圖來了解項目的成熟度，讓所有人都知道正在發生什么。也許更容易增強開發信心，培養團隊良好的工程文化，齊心協力向目標前進。