偶爾想起學生時，幾個同學一起做項目，雖然不大，但還是分了模塊，每個人負責一個或多個模塊。每天打開電腦，從版本控制庫更新最新代碼，運行下程序，回憶昨天完成的并計劃今天的任務。突然發現昨天好好的功能，今天突然不work甚至拋出異常，于是大喊一聲誰破壞了我的功能？沒人回應，只能自己一步一步查看到底那個代碼破壞了昨天的功能，然后找到提交的同學，再商量到底該怎么解決。其實當時我們各自實現自己的模塊，寫（或不寫）測試，然后提交代碼，各自只關心和測試自己的模塊，難免會發生沖突，尤其是兩個模塊結合的地方，如果被破壞方可能在幾個小時，幾天甚至更長時間后發覺應用被破壞，或者直到最后項目上線前一分鐘才發覺。。。
后來參加工作，知道了持續集成可以解決當時的痛苦，而且可以提供更多。持續集成是XP實踐之一，于是，很多人錯誤認為持續集成是為了實現敏捷編程的。實際上，早于敏捷編程概念的提出，持續集成作為一個best practice就已經被很多公司采用了，只不過作為一個概念，則是由Martin大叔為了推進敏捷所倡導并由此風靡起來。
那么為什么我們需要持續集成或者說持續集成給我帶來了什么好處呢？
- 及早獲得系統級的成果或者是可以deploy到production環境的產品。因為代碼已經被集成起來了，即使整個系統還不是那么可用，至少比零散的模塊讓人更有安全感。增強了客戶和我們自己的信心。
- 可以很容易的知道每一個版本之間有什么變化，甚至我們可以很容易的重新build出任何一個時間點上的版本，這點非常重要。工作后第一個項目就遇到了難纏的客戶，經常今天告知我們明天需要一個版本部署到生產環境，如果沒有持續集成，我們如何得到有信心可以部署到production的build？如果沒有持續集成，我們如何提供包含最新功能的可以部署到production的build？偶爾，客戶并不需要你提供的最終build，而是包含功能1和2而不包含功能3的build，如果沒有頻繁的持續集成，我們又怎么快速的得到某一時間的build？
- 及早的發現和定位錯誤：比如學生時代的項目，某個人在工作的時候踩進了別人的領域、影響了別人的代碼，而被影響的人還不知道發生了什么，于是bug就出現了。這種bug是最難查的，因為問題不是出在某一個人的領域里，而是出在兩個人的交流上面。隨著時間的推移，問題會逐漸惡化。通常，在集成階段出現的bug早在幾周甚至幾個月之前就已經存在了。結果，開發者需要在集成階段耗費指數倍的時間和精力來尋找這些bug的根源。如果有了持續集成，當持續集成失敗了，很容易說明最新加入的代碼或者修改的代碼引起了錯誤，當然這需要強大的自動化測試作為后盾。
- 項目進度的一目了然。頻繁的集成使我們可以看到哪些功能可以使用，哪些功能還沒有實現。開發人員不用在匯報任務的時候說我完成了多少百分比而煩惱，而PM也不再煩惱程序員說完成了編碼的50%到底是個什么概念。
因此引用同事的原話“沒有持續集成，說明交付流程是混亂不清晰隨機的。”