持續整合已經被公認為極具價值的一項工程實踐。在初始化一個專案時一個重要的任務就是搭建持續整合伺服器，編寫構建指令碼。在我工作的所有專案中都引入了持續整合機制。它已經像氧氣一樣成為軟體開發過程中的一項工程活動。
《持續整合》站在理論的角度闡述了持續整合能夠解決什麼樣的問題，如何解決，需要遵循那些原則等。這本書的副標題是-軟體質量改進和風險降低之道（Improving Software Quality and Reducing Risk）。副標題直指持續整合的兩個好處：提高軟體質量及降低專案風險。
當前面臨的問題
當前軟體開發一直存在兩大難題：一是確定軟體的需求，即確定目標。究竟軟體要做成什麼樣子，在客戶的頭腦裡可能是個三角形，在業務分析員的頭腦中可能是個正方形，在開發者的頭腦中可能是個圓形，而最終出來的產品或多或少都會給客戶帶來“驚喜”。
二是確定目前離目標還有好遠，即確定剩餘的工作量。這個問題就是專案缺少可見性的問題。當一個程式設計師告訴他的經理說這個功能只剩下20%的工作量時，具體指什麼那？這個20%的比例是怎麼得到的？是還要再花20%的時間？……
持續整合雖然解決不了第一個問題，但是關於第二個問題，持續整合向我們介紹了一種增加專案可見性，提高開發效率，降低專案失敗風險的有效實踐經驗。
其實持續整合蘊含有哲學思想：分而治之。即我們通常說的 “滴水穿石，矽步千里”。
傳統瀑布方法一般將系統整合放置到開發完成後，這樣會導致一系列的問題。
-
沒有一致的、可部署的軟體。只有等到整合完成之後，我們才能夠拿到一個可以使用的軟體。
-
很晚才發現缺陷。介面不一致、介面不滿足實際需求、開發人員對功能理解有偏差….這些問題在整合測試時統統暴露出來。由於軟體根基已經建立，這時候修改容易傷筋動骨。
-
低品質的軟體。正如上條所說，缺陷發現的越晚，修改的代價越大。在交付的壓力下，各種猴子補丁散落在系統的各個地方，軟體的品質自然也很難提高。
-
缺少專案可見性。直到系統整合之前，你都拿不出可用的軟體。而且系統整合之時，往往是專案中最棘手、最緊張的時刻，你很難預估整合什麼時候能夠徹底完成。這樣的專案自然談不上什麼可見性了。
CI的價值
引入了CI（Continuos Integration，即持續整合）以後，每個開發人員在提交程式碼的時候都會自動進行構建，包括程式碼審查、編譯、單元測試、打包、功能測試等。這樣保證了開發人員的每次提交都是安全的。打包生成的檔案隨時可以被測試人員拿去測試。如果需要給客戶演示功能，也只需從CI伺服器上直接獲取指定的打包完成的檔案即可。
CI的好處多多。
- 減少風險
缺陷的檢測和修復變得更快，讓尋找和修改bug的工作變簡單（只修改系統一小部分，無需看太多程式碼。由於提交後就可以得到反饋，記憶很新鮮，可以進行差異除錯。）同時過早的引入整合，使我們能更好的審視各個模組的介面是否滿足要求，減少專案中的假定。
- 減少重複過程
由於CI將大量的工作給自動化了，那麼可以讓人們有時間做更多的需要動腦筋的、更高價值的工作。而且通過對重要過程自動化，克服了專案中某些成員對實現改進的抵制，有利於持續整合的推進。這樣就形成了一個良性迴圈。
- 在任何時間、任何地點生成可部署的軟體
對於客戶來說，可以部署的軟體是最實際的資產。而CI則可以輕鬆做到這一點。
- 增強專案的可見性
通過對CI伺服器的監控，可以隨時瞭解專案的趨勢。CI上的紅色或綠色表示了當前專案的健康程度。每一個功能的交付都經歷了單元測試或整合測試的考驗。
- 對開發團隊的軟體產品建立起更強大的產品信心
CI可以防止破窗綜合症，讓開發團隊一點點積累起對產品的資訊。
CI的特徵
從上述圖中可以看出CI有四個特徵：
- 與版本控制系統的連線
當開發者提交程式碼時，就會觸發CI系統的執行。
- 構建指令碼
構建指令碼繼承了審查、編譯、測試、打包、功能測試等環節，保證了產品的質量與可用性。
- 某種型別的反饋機制
整合的結果要能很容易的獲取到。可以通過一個web頁面來呈現，也可以給團隊人員發Email。我們公司有些團隊做了一些有意思的外掛，比如將build的結果對映到一個燈上，或者當構建失敗時播放一段音樂等，隨時提醒團隊成員對build的關注。
- 整合原始碼變更的過程
程式碼變更會觸發構建,保證了CI能夠經常性的執行。
CI對團隊的要求
很多團隊說我們引入了持續整合，但是收到的效果並不好。比如遇到了CI持續失敗、沒人關注構建結果、沒有及時修復build等。那是因為開發團隊沒有遵循一定的原則。
-
經常提交程式碼
-
不要提交無法構建的程式碼
-
立即修復無法整合的構建
-
編寫自動化的開發者測試
-
必須通過所有測試和審查
-
執行私有構建
-
避免遷出無法構建的程式碼
持續整合是一個實踐性很強的工程活動，其實發展到現在也遇到了一些新的挑戰。比如如何減少構建時間、怎樣實現分階段分散式構建、如何應用在有Branch的程式碼庫中、從持續整合進階到持續交付等。這本書基本沒怎麼涉及這些話題，畢竟它出版有些年頭了，但這仍不失為一本好書。
如果你理解了持續整合的好處，那麼在應用過程中就不會有牴觸心理，而且也更容易理解持續交付。