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

July 04 16:26~18:10

昨天介紹了前五項，今天繼續介紹後五項：

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》的時候，因為沒有授課的壓力，所以隨便翻一翻，有時候還會冒出有一種：「這本書沒講什麼啊，自己好像都知道了」的感覺。但是，仔細一看，其實這本書基本上將持續整合該注意的事情都交代了一遍，堪稱是目前市面上介紹持續整合最好的一本書。給它按個讚。

***

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