文章出處

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

《持續集成》站在理論的角度闡述了持續集成能夠解決什么樣的問題,如何解決,需要遵循那些原則等。這本書的副標題是-軟件質量改進和風險降低之道(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的代碼庫中、從持續集成進階到持續交付等。這本書基本沒怎么涉及這些話題,畢竟它出版有些年頭了,但這仍不失為一本好書。

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


文章列表


不含病毒。www.avast.com
arrow
arrow
    全站熱搜
    創作者介紹
    創作者 大師兄 的頭像
    大師兄

    IT工程師數位筆記本

    大師兄 發表在 痞客邦 留言(0) 人氣()