持續集成最大的優點是可以避免這種傳統模式在集成階段的除蟲會議。持續集成主張項目的開發人員頻繁的將他們對源碼的修改提交(check in)到壹個單壹的源碼庫，並驗證這些改變是否對項目帶來了破壞，持續集成包括以下幾大要點：
訪問單壹源碼庫，將所有的源代碼保存在單壹的地點（源碼控制系統）， 讓所有人都能從這裏獲取最新的源代碼（以及以前的版本）。
支持自動化創建腳本，使 創建過程完全自動化，讓任何人都可以只輸入壹條命令就完成系統的創建。
測試完全自動化，要求開發人員提供自測試的代碼，讓 任何人都可以只輸入壹條命令就運行壹套完整的系統測試。
提供主創建，讓任何人都可以只輸入壹條命令就可以開始主創建。
提倡開發人員頻繁的提交（check in）修改過的代碼。
持續集成的關鍵是完全的自動化，讀取源代碼、編譯、連接、測試，整個創建過程都應該自動完成。對於壹次成功的創建，要求在這個自動化過程中的每壹步都不能出錯，而最重要的壹步是測試，只有最後通過測試的創建才是成功的創建。
在持續集成裏面創建不再只是傳統的編譯和連接那麽簡單，創建還應該包括自測試，自測試的代碼是開發人員提交源碼的時候同時提交的，是針對源碼的單元測試（源自 XP 的實踐），將所有的這些自測試代碼整合到壹起形成測試集，在 所有的最新的源碼通過編譯和連接之後還必須通過這個測試集的測試才算是成功的創建。這 種測試的主要目的是為了驗證創建的正確性，M cConnell 稱之為冒煙測試，在 持續集成裏面，這 叫做集成驗收測試Build Verify Test，簡稱 BVT。BVT 測試是質量的基礎，QA 小組不會感受到 BVT 的存在，他們只針對成功的
創建進行測試（如功能測試）。
BVT 測試應該盡量的詳盡，詳盡的測試才能發現更多的問題，而由此得到的反饋結果也更有參考意義，測試應該全部執行完畢，這樣得到的反饋結果才是完整的，而不是遇到錯誤就放棄測試過程。
持續集成和日創建相比還有以下特點：
持續集成強調了集成頻率，和日創建相比，持續集成顯得更加頻繁，目前推薦的最佳實踐是每壹個小時就集成壹次。
持續集成強調及時反饋，日創建的目的是得到壹個可以使用的穩定的發布版本，而持續集成強調的是集成失敗之後向開發人員提供快速的反饋，當 然成功創建的結果也是得到穩定的版本。
日創建並沒有強調開發人員提交（check in）源碼的頻率，而持續集成鼓勵並支持開發人員盡快的提交對源碼的修改並得到盡快的反饋。
從上面列出的續集成和日創建相比的特點來看，很明顯， 頻率和反饋這兩個詞出現的特別多，持 續集成有壹個與直覺相悖的基本要點，那 就是 經常性的集成比偶爾集成要好。Martin Fowler 認為對於持續集成來說，集成越頻繁，效果越好 ，如果妳的集成不是經常進行的（少於每天壹次），那麽集成就是壹件痛苦的事情，如果集成偶爾才進行壹次（壹周甚至壹個月）， 等到集成階段發現bug，然後找原因解決bug，會耗費妳大量的時間與精力，而且這種方式有點象傳統的集成模式，這違背了持續集成的初衷。
根據Martin Fowler 的觀點，項目 bug 的增加和時間並不是線性增長的關系，而是和時間的平方成正比，兩次集成間隔的時間越長，bug 增加的數量越超過妳的預期，解決 bug 付出的工作量也越大，而妳越覺得付出的工作量越大，妳就越想推遲到以後去集成，企圖到最後壹次性解決問題，結果 bug 產生的就更多，導致下壹次集成的工作量更大，妳越感覺到集成的痛苦，就越將集成的時間推後，最後形成惡性循環。
因此如果集成的結果是讓妳感到痛苦，也許就說明妳應該更頻繁地進行集成。頻繁的集成和及時的反饋鞭策著項目小組積極的面對問題，而 不是將問題推到最後來解決，如 果方法正確，更頻繁的集成應該能減少妳的痛苦，讓妳節約大量時間。
因為持續集成最終是通過測試來驗證創建，所以妳會發現對於持續集成的頻率的要求跟Kent Beck 提出的測試驅動的開發方法裏面測試第壹的理念完全壹致。需要註意的是從項目的壹開始就引入持續集成可以盡早的發現 bug，但是並不代表持續集成可以幫妳妳抓到所有的 bug。持續集成的排錯能力取決於測試技術，眾所周知，無法證明已經經過測試的代碼就已經找到了所有的錯誤。