描述持續整合最大的難點在於：它從根本上改變了整個開發模式。如果沒有在持續整合的實踐環境中工作過，你很難理解它的開發模式。實際上，在單獨工作的時候，絕大多數人都能感覺到這種氣氛--因為他們只需要與自己的系統相整合。對於許多人來說，"團隊開發"這個詞總讓他們想起軟體工程領域中的一些難題。持續整合減少了這些難題的數量，代之以一定的制度。 [page]
持續整合最基本的優點就是：它完全避免了開發者們的"除蟲會議"--以前開發者們經常需要開這樣的會，因為某個人在工作的時候踩進了別人的領域、影響了別人的**，而被影響的人還不知道發生了什麼，於是bug就出現了。這種bug是最難查的，因為問題不是出在某乙個人的領域裡，而是出在兩個人的交流上面。隨著時間的推移，問題會逐漸惡化。通常，在整合階段出現的bug早在幾周甚至幾個月之前就已經存在了。結果，開發者需要在整合階段耗費大量的時間和精力來尋找這些bug的根源。
如果使用持續整合，這樣的bug絕大多數都可以在引入的同一天就被發現。而且，由於一天之中發生變動的部分並不多，所以可以很快找到出錯的位置。如果找不到bug究竟在**，你也可以不把這些討厭的**整合到產品中去。所以，即使在最壞的情況下，你也只是不新增引起bug的特性而已。（當然，可能你對新特性的要求勝過了對bug的憎恨，不過至少你可以多一種選擇。）
到現在為止，持續整合還不能保證你抓到所有整合時出現的bug。持續整合的排錯能力取決於測試技術，眾所周知，測試無法證明已經找到了所有的錯誤。關鍵是在於：持續整合可以及時抓到足夠多的bug，這就已經值回它的開銷了。
所以，持續整合可以減少整合階段"捉蟲"消耗的時間，從而最終提高生產力。儘管現在還不知道是否有人對這種方法進行過科學研究，但是作為一種實踐性的方法，很明顯它是相當有效的。持續整合可以大幅減少耗費在"整合地獄"中的時間，實際上，它可以把地獄變成小菜一碟。
整合越頻繁，效果越好
持續整合有乙個與直覺相悖的基本要點：經常性的整合比很少整合要好。對於持續整合的實踐者來說，這是很自然的；但是對於從未實踐過持續整合的人來說，這是與直觀印象相矛盾的。
如果你的整合不是經常進行的（少於每天一次），那麼整合就是一件痛苦的事情，會耗費你大量的時間與精力。我們經常聽見有人說："在乙個大型的專案中，不能應用日建立"，實際上這是一種十分愚蠢的觀點。
不過，還是有很多專案實踐著持續整合。在乙個五十人的團隊、二十萬行**的專案中，我們每天要整合二十多次。微軟在上千萬行**的專案中仍然堅持日建立。
持續整合之所以可行，原因在於整合的工作量是與兩次整合間隔時間的平方成正比的。儘管我們還沒有具體的衡量資料，但是可以大概估計出來：每週整合一次所需的工作量絕對不是每天整合的5倍，而是大約25倍。所以，如果整合讓你感到痛苦，也許就說明你應該更頻繁地進行整合。如果方法正確，更頻繁的整合應該能減少你的痛苦，讓你節約大量時間。
Scrum團隊的持續整合之路（1）
每到專案接近尾聲的時候，專案經理往往是心裡最沒數的時候。專案經理最頭痛的問題是，越到專案後期，程式設計師交付的模組越來越多，聯調測試起來bug也越來越多，什麼時候能交付？說不清楚。下面的問答是幾乎每個專案都會出現的 老闆 按進度的計畫，我們能否按時發布產品？經理 沒法評估，這一輪測試完成的時間我和測...
持續整合與持續交付（1） 基礎知識祥解
git簡介 git 分布式版本控制系統 git是乙個開源的分布式版本控制系統，可以有效 高速地處理從很小到非常大的專案版本管理。git 是 linus torvalds 為了幫助管理 linux 核心開發而開發的乙個開放原始碼的版本控制軟體。torvalds 開始著手開發 git 是為了作為一種過渡...
CI 持續整合（1） 軟體工業「流水線」概述
持續整合 continuous integration 是一種軟體開發實踐，即團隊開發成員經常整合它們的工作，通過每個成員每天至少整合一次，也就意味著每天可能會發生多次整合。每次整合都通過自動化的構建 包括編譯，發布，自動化測試 來驗證，從而盡早地發現整合錯誤 1 持續整合相當於將傳統工業的流水線作...