讓你的CI跑起來-《持續整合》讀書總結

無敵西瓜發表於2013-09-22

持續整合已經被公認為極具價值的一項工程實踐。在初始化一個專案時一個重要的任務就是搭建持續整合伺服器,編寫構建指令碼。在我工作的所有專案中都引入了持續整合機制。它已經像氧氣一樣成為軟體開發過程中的一項工程活動。

《持續整合》站在理論的角度闡述了持續整合能夠解決什麼樣的問題,如何解決,需要遵循那些原則等。這本書的副標題是-軟體質量改進和風險降低之道(Improving Software Quality and Reducing Risk)。副標題直指持續整合的兩個好處:提高軟體質量及降低專案風險。

當前面臨的問題

當前軟體開發一直存在兩大難題:一是確定軟體的需求,即確定目標。究竟軟體要做成什麼樣子,在客戶的頭腦裡可能是個三角形,在業務分析員的頭腦中可能是個正方形,在開發者的頭腦中可能是個圓形,而最終出來的產品或多或少都會給客戶帶來“驚喜”。

二是確定目前離目標還有好遠,即確定剩餘的工作量。這個問題就是專案缺少可見性的問題。當一個程式設計師告訴他的經理說這個功能只剩下20%的工作量時,具體指什麼那?這個20%的比例是怎麼得到的?是還要再花20%的時間?……

持續整合雖然解決不了第一個問題,但是關於第二個問題,持續整合向我們介紹了一種增加專案可見性,提高開發效率,降低專案失敗風險的有效實踐經驗。

其實持續整合蘊含有哲學思想:分而治之。即我們通常說的 “滴水穿石,矽步千里”。

傳統瀑布方法一般將系統整合放置到開發完成後,這樣會導致一系列的問題。

  • 沒有一致的、可部署的軟體。只有等到整合完成之後,我們才能夠拿到一個可以使用的軟體。

  • 很晚才發現缺陷。介面不一致、介面不滿足實際需求、開發人員對功能理解有偏差….這些問題在整合測試時統統暴露出來。由於軟體根基已經建立,這時候修改容易傷筋動骨。

  • 低品質的軟體。正如上條所說,缺陷發現的越晚,修改的代價越大。在交付的壓力下,各種猴子補丁散落在系統的各個地方,軟體的品質自然也很難提高。

  • 缺少專案可見性。直到系統整合之前,你都拿不出可用的軟體。而且系統整合之時,往往是專案中最棘手、最緊張的時刻,你很難預估整合什麼時候能夠徹底完成。這樣的專案自然談不上什麼可見性了。

CI的價值

引入了CI(Continuos Integration,即持續整合)以後,每個開發人員在提交程式碼的時候都會自動進行構建,包括程式碼審查、編譯、單元測試、打包、功能測試等。這樣保證了開發人員的每次提交都是安全的。打包生成的檔案隨時可以被測試人員拿去測試。如果需要給客戶演示功能,也只需從CI伺服器上直接獲取指定的打包完成的檔案即可。

CI的好處多多。

  • 減少風險

缺陷的檢測和修復變得更快,讓尋找和修改bug的工作變簡單(只修改系統一小部分,無需看太多程式碼。由於提交後就可以得到反饋,記憶很新鮮,可以進行差異除錯。)同時過早的引入整合,使我們能更好的審視各個模組的介面是否滿足要求,減少專案中的假定。

  • 減少重複過程

由於CI將大量的工作給自動化了,那麼可以讓人們有時間做更多的需要動腦筋的、更高價值的工作。而且通過對重要過程自動化,克服了專案中某些成員對實現改進的抵制,有利於持續整合的推進。這樣就形成了一個良性迴圈。

  • 在任何時間、任何地點生成可部署的軟體

對於客戶來說,可以部署的軟體是最實際的資產。而CI則可以輕鬆做到這一點。

  • 增強專案的可見性

通過對CI伺服器的監控,可以隨時瞭解專案的趨勢。CI上的紅色或綠色表示了當前專案的健康程度。每一個功能的交付都經歷了單元測試或整合測試的考驗。

  • 對開發團隊的軟體產品建立起更強大的產品信心

CI可以防止破窗綜合症,讓開發團隊一點點積累起對產品的資訊。

CI的特徵

讓你的CI跑起來-《持續整合》讀書總結

從上述圖中可以看出CI有四個特徵:

  • 與版本控制系統的連線

當開發者提交程式碼時,就會觸發CI系統的執行。

  • 構建指令碼

構建指令碼繼承了審查、編譯、測試、打包、功能測試等環節,保證了產品的質量與可用性。

  • 某種型別的反饋機制

整合的結果要能很容易的獲取到。可以通過一個web頁面來呈現,也可以給團隊人員發Email。我們公司有些團隊做了一些有意思的外掛,比如將build的結果對映到一個燈上,或者當構建失敗時播放一段音樂等,隨時提醒團隊成員對build的關注。

  • 整合原始碼變更的過程

程式碼變更會觸發構建,保證了CI能夠經常性的執行。

CI對團隊的要求

很多團隊說我們引入了持續整合,但是收到的效果並不好。比如遇到了CI持續失敗、沒人關注構建結果、沒有及時修復build等。那是因為開發團隊沒有遵循一定的原則。

  • 經常提交程式碼

  • 不要提交無法構建的程式碼

  • 立即修復無法整合的構建

  • 編寫自動化的開發者測試

  • 必須通過所有測試和審查

  • 執行私有構建

  • 避免遷出無法構建的程式碼


持續整合是一個實踐性很強的工程活動,其實發展到現在也遇到了一些新的挑戰。比如如何減少構建時間、怎樣實現分階段分散式構建、如何應用在有Branch的程式碼庫中、從持續整合進階到持續交付等。這本書基本沒怎麼涉及這些話題,畢竟它出版有些年頭了,但這仍不失為一本好書。

如果你理解了持續整合的好處,那麼在應用過程中就不會有牴觸心理,而且也更容易理解持續交付。

相關文章