定義
大師Martin Fowler對持續集成是這樣定義的:持續集成是一種軟體開發實踐，即團隊開發成員經常集成他們的工作，通常每個成員每天至少集成一次，也就意味著每天可能會發生多次集成。每次集成都通過自動化的構建（包括編譯，發布，自動化測試)來驗證，從而儘快地發現集成錯誤。許多團隊發現這個過程可以大大減少集成的問題，讓團隊能夠更快的開發內聚的軟體。
持續集成的宗旨是避免集成問題，如同在極限編程(XP)方法學中描述的集成地獄。持續集成並非普遍接受是用來改善集成頻率的方法，因此重要的是區分兩者所帶來的效益。
在極限編程方法學，持續集成需要達到最佳成果，必須依靠著自動化集成單元測試並通過測試驅動開發。首先必須構想在上線運作之前，已在開發環境完成並通過所有的單元測試。這將幫助避免一個開發者的作業流程，導致其他開發者作業的中斷。如果有需要，可以在完整上線運作之前進用部分已完成的功能，例如使用功能切換。
接著進行CI伺服器建置概念的闡述、自動化運行單元測試的周期與每次測試需要提交給開發者的報告。建置CI伺服器的用途(不一定要運行單元測試) 已經開始在極限編程(XP)社群之外的團隊練習。如今，許多企業組織已經開始採用持續性集成，而非採用完整的極限編程(XP)。
除了自動化單元測試，組織在運用持續性集成(CI)一般會建置CI伺服器來維護持續性套用質量控制的程式-小部分的影響，並且經常性使用。除了運行單元與集成測試之外，還有額外的靜態與動態測試，量測與描述性能，從程式來源碼摘錄與檔案格式與促成手動質量保證(QA)程式。持續性質量控制應用程式用意在提升軟體質量以及減少交付的時間，在完成所有開發後，取代傳統軟體上線質量控制機制。此非常相似進行頻繁集成的最初概念讓集成得以在QA程式上更容易地達成。
同樣的道理，持續性交付的最佳實踐進一步擴展了持續性集成(CI)，以確保軟體檢核在主要程式上並且能夠布署到用戶以確保實際的布署流程可以非常快速。
措施
減少風險
一天中進行多次的集成，並做了相應的測試，這樣有利於檢查缺陷，了解軟體的健康狀況，減少假定。
減少重複過程
減少重複的過程可以節省時間、費用和工作量。說起來簡單，做起來難。這些浪費時間的重複勞動可能在我們的項目活動的任何一個環節發生，包括代碼編譯、資料庫集成、測試、審查、部署及反饋。通過自動化的持續集成可以將這些重複的動作都變成自動化的，無需太多人工干預，讓人們的時間更多的投入到動腦筋的、更高價值的事情上。
任何時間、任何地點生成可部署的軟體
持續集成可以讓您在任何時間發布可以部署的軟體。從外界來看，這是持續集成最明顯的好處，我們可以對改進軟體品質和減少風險說起來滔滔不絕，但對於客戶來說，可以部署的軟體產品是最實際的資產。利用持續集成，您可以經常對原始碼進行一些小改動，並將這些改動和其他的代碼進行集成。如果出現問題，項目成員馬上就會被通知到，問題會第一時間被修復。不採用持續集成的情況下，這些問題有可能到交付前的集成測試的時候才發現，有可能會導致延遲發布產品，而在急於修復這些缺陷的時候又有可能引入新的缺陷，最終可能導致項目失敗。
增強項目的可見性
持續集成讓我們能夠注意到趨勢並進行有效的決策。如果沒有真實或最新的數據提供支持，項目就會遇到麻煩，每個人都會提出他最好的猜測。通常，項目成員通過手工收集這些信息，增加了負擔，也很耗時。持續集成可以帶來兩點積極效果：
(1)有效決策：持續集成系統為項目構建狀態和品質指標提供了及時的信息，有些持續集成系統可以報告功能完成度和缺陷率。
(2)注意到趨勢：由於經常集成，我們可以看到一些趨勢，如構建成功或失敗、總體品質以及其它的項目信息。
建立團隊對開發產品的信心
持續集成可以建立開發團隊對開發產品的信心，因為他們清楚的知道每一次構建的結果，他們知道他們對軟體的改動造成了哪些影響，結果怎么樣。
要素
1.統一的代碼庫
2.自動構建
3.自動測試
4.每個人每天都要向代碼庫主幹提交代碼
5.每次代碼遞交後都會在持續集成伺服器上觸發一次構建
6.保證快速構建
7.模擬生產環境的自動測試
8.每個人都可以很容易的獲取最新可執行的應用程式
9.每個人都清楚正在發生的狀況
10.自動化的部署
原則
1. 所有的開發人員需要在本地機器上做本地構建，然後再提交的版本控制庫中，從而確保他們的變更不會導致持續集成失敗。
2. 開發人員每天至少向版本控制庫中提交一次代碼。
3. 開發人員每天至少需要從版本控制庫中更新一次代碼到本地機器。
4. 需要有專門的集成伺服器來執行集成構建,每天要執行多次構建。
5. 每次構建都要100%通過。
6. 每次構建都可以生成可發布的產品。
7. 修復失敗的構建是優先權最高的事情。
8. 測試是未來，未來是測試
工作流程
當從事變更時，開發者會從目前基礎代碼庫複製以進行作業，其他開發者提交代碼的變更至來原始碼庫，並透過副本的方式取代來原始碼庫的代碼。不只變更目前的代碼庫，新的代碼也可以新增成為程式庫、其它共享資源與潛在衝突。
當分支代碼保持在取出狀態時間越長，當分支代碼開發者進行主線重新集成時，就愈容易遭遇集成多重衝突的風險以及失敗。當開發者將代碼提交到代碼庫時，首先必須更新代碼以反映他們在代碼庫中的更改，因為他們拿到了副本。代碼庫包含的更改越多，開發人員在提交自己的更改前必須運行的工作越多。
終於，該程式庫也許變成非常不同於開發者的目標代碼，他們進入有時候被稱為合併地獄或集成地獄的階段，這時候開發者所花費的集成時間，將超過最初代碼開發的時間。
持續性集成涉及預先集成與預先與經常性的集成，藉此來避免踩到集成地獄的陷阱，實踐的目標是減少重工、減少成本與時間。
持續性集成補充的實踐是在提交成果之前，每個開發人員必須運行一個完整的構建與運行及通過所有的單元測試、集成測試，這些都是當持續性集成伺服器偵測到代碼有新的提交時，必須經常性與自動化的進行。
