開發人員應遵循的七項持續整合要領

July 02 22:30~23:25

 

今天沒有廢話，直接介紹《Continuous Integration》這本書中所提到開發人員應該遵守的七項持續整合要領：

1. Commit code frequently：持續整合之所以冠上了持續這兩個字，有一個很重要的要求，那就是開發人員必須要頻繁地將程式送交到版本控制系統中。為什麼？因為持續整合系統在執行建構工作的時候，會從版本控制系統中取出最新的程式碼。如果開發人員打死都不把程式送交到版本控制系統中，那麼就算專案每天被持續整合系建構N次，也沒有任何意義。所以，唯有開發人員「持續送交程式碼」，持續整合才有機會可以發揮作用。
2. Don’t commit broken code：所謂broken code就是會導致建構失敗的程式碼。如果鄉民們送交到版本控制系統中的程式10中有9次都會導致建構失敗，那就表示這些被送交的程式碼品質根本有很大的問題。開發人員在送交程式碼之前，必須要謹記不要因為自己的不小心就造成建構失敗。每次建構失敗就代表著專案的健康狀態出了嚴重的問題，必須要立即花費時間與人力去修復。所以，開發人員要對自己送交的程式負起責任，不要因為自己不小心而造成建構失敗。
3. Fix broken builds immediately：不知道鄉民們有沒有聽過破窗理論（broken windows theory）？依據維基百科的解釋：「此理論認為環境中的不良現象如果被放任存在，會誘使人們仿傚，甚至變本加厲。以一幢有少許破窗的建築為例，如果那些窗不被修理好，可能將會有破壞者破壞更多的窗戶。最終他們甚至會闖入建築內，如果發現無人居住，也許就在那裡定居或者縱火。又或想像一條人行道有些許紙屑，不久後就會有更多垃圾，最終人們會視若理所當然地將垃圾順手丟棄在地上。因此破窗理論強調著力打擊罪行，以零容忍的態度面對罪案。」將破窗理論套用在持續整合上面，如果專案建構失敗（例如測試案例沒有全部通過）但是團隊都沒有人把建構失敗當作一回事，大家都認為只要編譯成功就好了。久而久之，持續整合就失去它的作用。破窗理論告訴鄉民們，要以零容忍的態度面對犯罪。什麼叫做持續整合的犯罪？任何造成建構失敗的事件就是一種「犯罪」，如果忽視它，持續整合就爛掉了。所以這一條要領告訴鄉民們，要「時時勤拂拭，不使惹塵埃」。
4. Write automated developers tests：持續整合和自動化測試是相輔相成的好兄弟，光有持續整合，沒有自動化測試案例，就好像蓋了很多「蚊子館」一樣，空有硬體建設沒有參觀的人（有持續整合系統但沒有自動化測試案例，那麼持續整合頂多做做編譯的工作，無法藉由執行測試案例找出功能錯誤）。反之，光有自動化測試案例，沒有持續整合，就好像開放了一大堆陸客來台觀光，但是卻沒有好景點可以容納大量的陸客（測試案例寫了一堆，但是卻擺在一旁很少執行。不執行測試案例怎麼會知道系統有沒有問出題啊，那還不如不寫把時間省下來早點下班）。
5. All tests and inspections must pass：這一點跟第3點很像，如果測試或是inspection（可以想成靜態程式碼檢查）沒有通過，但是程式可以編譯，那麼這次的建構算不算成功建構？當然不算，因為這一條要領已經說得很明白了啊。
6. Run private builds：第2條要領要求開發人員不要送交有問題的程式，但是開發人員怎麼會知道自己送交的程式有沒有問題啊？就是不知道才要把程式丟到版本控制系統，然後驅動持續整合系統去建構看看能不能成功啊。所以程式還沒在持續整合系統上建構之前，開發人員又不是算命的，怎麼會知道正要送交的程式碼有沒有問題？答案很簡單，就是「在送交程式之前，先執行本地建構」。
7. Avoid getting broken code：最後一條，提醒開發人員不要不小心從版本控制系統拿到無法建構的程式碼。要做到這一點，一個最簡單的方法就是，要從版本控制系統中更新程式之前，先到持續整合系統看看目前的專案是否可以被成功建構。另一個方法就是萬一有人造成建構失敗，要馬上主動通知團隊成員，請他們暫時不要更新程式碼，直到問題解決為止。

鄉民們工作上有實施持續整合嗎？如果有，以上七點要領，又落實了幾項呢？

***

友藏內心獨白：該不會有人想問「什麼是持續整合吧」…啊…說好了不打臉的XD。