集成軟件的過程不是新問題，如果項目開發的規模比較小，比如一個人的項目，如果它對外部系統的依賴很小，那么軟件集成不是問題，但是隨著軟件項目復雜度的增加（即使增加一個人），就會對集成和確保軟件組件能夠在一起工作提出了更多的要求-要早集成，常集成。早集成，頻繁的集成幫助項目在早期發現項目風險和質量問題，如果到后期才發現這些問題，解決問題代價很大，很有可能導致項目延期或者項目失敗。
        大師Martin Fowler對持續集成是這樣定義的:持續集成是一種軟件開發實踐，即團隊開發成員經常集成他們的工作，通常每個成員每天至少集成一次，也就意味著每天可能會發生多次集成。每次集成都通過自動化的構建（包括編譯，發布，自動化測試 )來驗證，從而盡快地發現集成錯誤。許多團隊發現這個過程可以大大減少集成的問題，讓團隊能夠更快的開發內聚的軟件。 

持續集成讓我們能夠注意到趨勢并進行有效的決策。如果沒有真實或最新的數據提供支持，項目就會遇到麻煩，每個人都會提出他最好的猜測。通常，項目成員通過手工收集這些信息，增加了負擔，也很耗時。持續集成可以帶來兩點積極效果：

(1)有效決策：持續集成系統為項目構建狀態和品質指標提供了及時的信息，有些持續集成系統可以報告功能完成度和缺陷率。

(2)注意到趨勢：由于經常集成，我們可以看到一些趨勢，如構建成功或失敗、總體品質以及其它的項目信息。
        持續集成可以建立開發團隊對開發產品的信心，因為他們清楚的知道每一次構建的結果，他們知道他們對軟件的改動造成了哪些影響，結果怎么樣。
 　　開展持續集成的十大條件：      

1.統一的代碼庫

2.自動構建

3.自動測試

4.每個人每天都要向代碼庫主干提交代碼

5.每次代碼遞交后都會在持續集成服務器上觸發一次構建

6.保證快速構建

7.模擬生產環境的自動測試

8.每個人都可以很容易的獲取最新可執行的應用程序

9.每個人都清楚正在發生的狀況

10.自動化的部署
      持續集成的七大原則
      1. 所有的開發人員需要在本地機器上做本地構建，然后再提交的版本控制庫中，從而確保他們的變更不會導致持續集成失敗。

2. 開發人員每天至少向版本控制庫中提交一次代碼。

3. 開發人員每天至少需要從版本控制庫中更新一次代碼到本地機器。

4. 需要有專門的集成服務器來執行集成構建,每天要執行多次構建。

5. 每次構建都要100%通過。

6. 每次構建都可以生成可發布的產品。

7. 修復失敗的構建是優先級最高的事情。