持續整合與跑步呼吸

大約是一月時的事，我看到消息說「GitHub已將持續整合服務器Janky開源」。然後，我就在公司的郵件群組中發了封信，說我可能會評估一下 Janky 這套持續整合工具。同事在跟帖中說，這樣會不會分心，是不是應該等目前的專案都結束了再做？

同事的說法，反應出他們尚未確實理解「持續整合」的意義。我相信大部份開發團隊初次接觸「持續整合」時，都會有相同的誤解。我在郵件與 twitter 上表達了我的看法。

持續整合與跑步呼吸

在專案進行的過程中，又同時去評估與導入一套持續整合系統這件事，並不是分心。「持續整合」這個名詞的意義，就體會在字面上。持續整合不是另一個專案，而是與現行專案黏著並行的工作。甚至於持續整合就是要在現行專案進行的過程中一併執行，才能發揮它「找出問題與改善手段」的效果。

持續整合之於專案開發，就好像人在跑步的同時也要持續呼吸，不可能說我要專心跑步，所以就停止呼叫。好的跑者在日常訓練中，最重視的項目，就是如何在跑步過程中調整呼吸。專案開發亦如是

舉個例子來說。如果團隊在專案進行的過程中，才發現自己連最基本的版本管理工具都還沒用，導致源碼管理困難。難道說「那我們等這個專案結束後，再開一個專案來研究如何使用版本管理工具」？這顯然不可行的。最好是馬上就使用版本管理工具(這屬於持續整合的一部份)。

好的跑者有良好的呼吸方法配合。好的專案也要有良好的持續整合配合。

不要把持續整合當成麻煩製造者

「持續整合」與敏捷開發方法實務中的其他項目一樣，都有翻人老底、強迫問題浮出的找碴特色。我前幾天看了漫畫「蒼藍鋼鐵戰艦」，想到裡面的魚雷戰術還挺像「持續整合」的情形，就用這做個譬喻吧。在深海航行時，敵人總是潛伏在目不可視的海底中，要找出敵人或潛在的危險除了靠聲納，還需要仰賴音響魚雷。透過音響魚雷爆炸時的回響，主動誘出潛出威脅，以便趁早擬定應對戰術。當然我方也可以不發射音響魚雷誘敵，讓那些潛在威脅「不存在」，讓我們自己繼續認為航行過程非常順利。但是代價將會非常昂貴。當那些潛在威脅動作時，我們將措手不及，永遠沉睡在海底中。

軟體開發過程也如同深海航行一般，週遭始終潛伏著許多風險。我前年記錄的一篇實際案例《軟體開發之建置風險的故事》中就列出不少。在那則案例中，最大的問題就是大部份的風險並不是在編寫程式的過程中爆發。我們的前期開發工程看似一帆風順，就算有些「小麻煩」也被「專案時程要緊，以後再處理」這個理由敷衍過去了。不幸的是，「看不到」並不表示不存在。這些風險最終在整合與驗收時期一一爆發。團隊成員開始加班加點，但專案還是不能如期結案。

持續整合的作用就像是音響魚雷一樣，把那些問題提前炸出來。所以鄉愿的程式人員不喜歡持續整合，他們抱怨持續整合在開發過程中「製造問題」。實際上，那些問題一直都在，只是那些人一直視而不見罷了。所以持續整合並不是製造問題，而是讓問題浮現。

持續整合就在當下

難道我們真的不能等現在的專案結束後，再以事後檢討的方式導入持續整合機制，應用在下個專案嗎？

基本上，大部份想要事後檢討的問題，在下個專案仍然會發生。因為人類的記憶並不可靠。我在《軟體開發之建置風險的故事》寫下這一段話：「根據心理學研究，人們在回憶過去的痛苦時期時，仍然會記得當時比較快樂的事，而淡忘痛苦的事。在軟體開發過程中，儘管我們遭遇了許多大大小小的問題，但是事後回想時，往往只記得成功的事而忘了失敗的事。想在事後正確地回想我們在開發過程中做過的蠢事，並不容易。」在案例研討(case study)的場合討論為什麼某些問題一再發生時，這段話總是可以於結論中一用在用。

如果問題在專案宣告失敗之前就已出現，最好當下就去處理。

不要再用「專案時程緊迫」當作不導入持續整合的理由了。在沒有持續整合機制的情形下，所有「軟體開發時程可以如期完成」的想法都是在賭博，你是在賭問題不會爆發。而遺憾的是，絕大多數案例都賭輸了。所以大家注定延期交付。既然結果不變，那麼發現問題時，還是老老實實地承認專案不能準時交付，把日後修正問題的時間挪到前面來導入持續整合機制。這樣做，說不定還能減少延期的時數。