l

2012年7月5日 星期四

持續整合工程師應遵循的十項要領(下)

July 04 16:26~18:10

image

昨天介紹了前五項,今天繼續介紹後五項:

6. Fail builds fast

假設鄉民們的建構工作包含編譯(需要30秒)、測試(需要2分鐘)、計算行號(需要10秒)、產生JavaDoc(需要20秒),請問哪一件工作應該要先做?答案是編譯,為什麼?因為如果編譯失敗,後續的建構工作就沒有意義,也就不需要繼續執行,所以整個建構工作最多30秒就結束了。也就是說,如果先執行編譯,開發人員最多只需要等待30秒就知道建構失敗。如果先做計算行號與產生JavaDoc,基本上這兩件事都是不太會出錯的工作,做完之後需要30秒。此時再來做編譯工作,結果失敗,因此開發人員需要等待60秒後才會知道建構失敗。所以,在安排建構工作執行順序的時候,一個很簡單的原則就是「越可能失敗的工作要越早執行」如此便可在比較短的時間內得到建構(失敗)的結果。看到這邊鄉民們可以會問:那為什麼不先執行測試,測試不是很容易失敗嗎?是啊,測試是很容易失敗,但是如果程式無法編譯,那麼就不可能去執行測試了。所以除了「越可能失敗的工作要越早執行」以外,還要考慮到「建構工作之間的相依性」。

7. Build for any environment

在設計建構腳本的時候,需要考慮到單一建構腳本要能夠支援各種所需的建構環境。例如,假設專案需要分別產生以下三種不同的安裝程式:開發人員debug、給測試人員、以及正式釋出,那麼建構腳本最好設計成只要給定不同的參數,便可達成上述要求。

  • ant –f build.xml –Denv=debug --–> 產生debug版本
  • ant –f build.xml –Denv=qa --–> 產生給測試人員的版本
  • ant –f build.xml –Denv=release --–> 產生正式釋出版本

8. Use a dedicated CI machine and a CI server

要實施持續整合,當然一定要有一套持續整合系統,例如Jenkins。由於持續整合所需要時間越短,開發人員才會願意頻繁地建構軟體,所以最好把持續整合系統安裝在一台專屬的電腦之上。這台給持續整合系統使用的電腦,最好是越高檔越好,詳情請參考「土炮跨平台自動化功能測試環境」。

9. Run fast builds

麥當勞與肯德雞這類的「速食店」,之所以稱之為「速食」,就是強調點餐之後可以很快地就拿到食物。應該很少人在速食店點餐之後還需要等超過10分鐘以上才拿到餐點。總之有些行業就是強調以快取勝,例如 快打旋風 PxHhome 24小時購物、某數字人力銀行強打的24小時必回覆(迷之音:難道是24小時一到,如果沒有回覆將會由系統自動寄出一封感謝狀?!)、以及某數字組屋網最近猛打的廣告:XXX組屋網,組屋就是快。持續整合也具有類似的特性,建構的過程一定要快,這樣開發人員才可以在很短的時間內得到回饋。至於要多短的時間才算得上快,可以參考「Ten-Minute Build」。

10. State builds

快、快、快,什麼都要快。問題是,有些建構工作就是會跑很久啊,怎麼可能在短短的10分鐘之內執行完畢。怎麼辦,難道就要放棄持續整合?當然不是。遇到這種情況,可以採取分階段執行持續整合工作的策略。這是什麼意思?很簡單,就是把建構工作分成兩段(或很多段),先執行一個輕量級的建構專案,如果成功,再接著執行要跑比較久的重量級建構專案。當第一個輕量級的建構專案(假設可以在10分鐘或是更短的時間內執行完畢)執行結束之後,雖然不保證專案完全沒有問題,但是至少可以提供團隊某種程度以上的信心。因此在持續整合系統繼續執行後續重量級建構專案的時候,開發人員便可繼續開發的工作,不用等到全部的建構工作都執行完畢。

聽起來有點抽象,舉例說明:輕量級的建構專案可以只包含編譯、執行「純單元測試」、產生安裝程式等工作。如果這樣還是無法壓縮在10分鐘之內,甚至可以只執行編譯與產生安裝程式(前提是開發人員有在本地端執行過單元測試了)。假設輕量級的建構專案成功之後,開發人員便可「大膽假設」專案目前狀況是OK的,然後看是要直接使用剛剛產生的安裝程式來做手動驗收測試,還是繼續開發功能。就在此時,持續整合系統便可繼續執行後續的重量級建構專案,例如產生測試涵蓋率報表、執行驗收測試、靜態程式碼檢查等。

***

前一陣子因為要去教人家持續整合,所以Teddy就強迫自己把《Continuous Integration》這本書的某些章節仔細地讀了一次。「開發人員應遵循的七項持續整合要領」、「持續整合工程師應遵循的十項要領(上)」以及今天所介紹的內容就是從Teddy授課的投影片中節錄出來的。其實說真的,光是讀《Continuous Integration》這本書,有時候會覺得有點無聊。為什麼?因為書中有很多敘述性的文字,要很用力去思考才可以把持續整合跟開發整個串起來。之前Teddy在讀《Continuous Integration》的時候,因為沒有授課的壓力,所以隨便翻一翻,有時候還會冒出有一種:「這本書沒講什麼啊,自己好像都知道了」的感覺。但是,仔細一看,其實這本書基本上將持續整合該注意的事情都交代了一遍,堪稱是目前市面上介紹持續整合最好的一本書。給它按個讚。

***

友藏內心獨白:持續整合不是只有工具的議題而已喔。

沒有留言:

張貼留言