在大型開發團隊中, 很多時候 source tree 上所產生出來的 build 都是無法執行, 通常是最後一兩周的階段, 這個系統才有機會真的可以運轉.
為什麼會這樣呢? 主要原因是早期開發人員在寫程式時, 只在乎自己的那一塊是否寫完, 至於和別人都在一起是否能動, 那是之後的問題, 老闆只會為你寫完了沒有, 而不是這個系統能不能動.
所有通常在專案進入測試階段時, 大家才會開始處理這個系統是否能運作的事情. 也就是開始修復 bug. 這裏要花多少時間才能修復完畢, 系統要多久才能穩定, 就要祈求上天了.
為了要解決這樣的問題, agile 裡面便提出了一個 practice, 叫做持續整合(continuous integration, CI). 希望程式一有變動時, 我們就趕快做整合, 確保整個系統仍能運作正確. 也就是你新增的部分, 不會影響原先系統的運行.
所以開發人員需要持續頻繁 check-in 程式到 source control system, build 出系統, 然後執行全面的自動化測試, 看看是否全部都通過, 如果失敗, 開發團隊要停下手中的工作, 馬上解決這個問題.
這樣做可以帶給我們什麼好處呢?
(1) 如果有小修改就進行 CI, 有錯的話, 比較好修復, 成本比較低.
(2) 別人修改的部分, 在早期你就會知道, 不會最後才意外發現.
(3) 讓系統在大多時間是可運行的, 容易對外展示, 及早收集回饋.
(4) 系統後期測試和修復 bug 的時間, 會是可控制的.
不過要切記一點, 頻繁整合是關鍵, 一天一次應該不算是頻繁, 那只是 cargo cult, 專案的團隊一天應該可以發生上百次.
所以持續整合重點不在工具, 在於實踐. 需要團隊成員遵守一些紀律, 願意以小步增量的方式, check-in 並進行 CI, 若是 CI 發生錯誤, 需要視為 P1 處理. 如果大家不能接受這樣的紀律, 那持續整合就會沒有效果. 切記切記 ….
嗯, David, 我們也有做 CI , 不過只有一次, 就是程式寫出來那一次!!!
…...
留言列表
