我認為持續集成最顯著也最廣泛的益處是降低風險。說到這里，我的腦海中還是會浮現出第一段描述的早期軟件項目。他們已經到了一個漫長項目的末期（至少他們期望如此），但還是不知道距離真正的結束有多遠。 延遲集成的問題在于時間難以估計，你甚至無法得知你的進展。結果是你在項目最緊張的階段之一把自己置入了一個盲區，此時即使沒有拖延（這很罕見）也輕松不了多少。 持續集成巧妙的解決了這個問題。長時間的集成不再存在，盲區被徹底消除了。在任何時間你都知道你自己的進展，什么能運轉，什么不能運轉，你系統里有什么明顯的 bug，這些都一目了然。 Bug 讓人惡心，它摧毀人的自信，搞亂時間表，還破壞團隊形象。已部署軟件里的 bug 招致用戶的怒氣。未完成軟件里的 bug 讓你接下來的開發工作受阻。 持續集成不能防止 bug 的產生，但它能明顯讓尋找和修改 bug 的工作變簡單。從這個方面看，它更像自測試代碼。如果你引入 bug 后能很快發現，改正也會簡單得多。因為你只改了系統中很小的一部分，你無需看很多代碼就能找到問題所在。因為這一小部分你剛剛改過，你的記憶還很新鮮，也會讓找 bug 的工作簡單不少。你還可以用[差異調試](http://www.martinfowler.com/bliki/DiffDebugging.html)——比較當前版本和之前沒有 bug 的版本。 Bug 也會積累。你的 bug 越多，解決掉任何一個都會越困難。這部分原因是 bug 之間的互相作用，你看到的失敗實際上是多個問題疊加的結果，這使得檢查其中任何一個問題都更加困難。還有部分原因是心理層面的因素，當人們面對大量 bug 時，他們尋找和解決 bug 的動力就會減弱。《Pragmatic Programmer》一書中稱之為“[破窗綜合癥](http://www.amazon.com/exec/obidos/ASIN/020161622X)“。 使用持續集成的項目的通常結果是 bug 數目明顯更少，不管在產品里還是開發過程中都是如此。然而，我必須強調，你受益的程度跟你測試的完善程度直接相關。其實建立測試系統并非想象中那么困難，但帶來的區別卻顯而易見。一般來說，團隊需要花一定時間才能把 bug 數量減少到理想的地步。做到這一點意味著不斷添加和改進測試代碼。 如果你用了持續集成，你就解決了頻繁部署的最大障礙之一。頻繁部署很有價值，因為它可以讓你的用戶盡快用到新功能，從而快速提供反饋，這樣他們在開發過程中可以有更多的互動。這可以幫助打破我心目中成功的軟件開發最大的障礙——客戶與開發團隊之間的障礙。