l

2012年7月3日 星期二

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

July 02 22:30~23:25

image

 

今天沒有廢話,直接介紹《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。

沒有留言:

張貼留言