很多人提到持續整合時, 都會想到一堆工作, CI server, source control system, automation framework 等等. 不是的, CI 和工具是沒有關聯的, 它能不能成功, 重點是在於團隊能不能遵守紀律. 因此當你們開始實施 CI, 必須和團隊溝通清楚, 不要把重心放到錯誤的地方.
以下是常見的要遵守的 practices:
1. 編譯有錯在修復前, 不能 check-in 新程式
Build 失敗要視為一件很嚴重很可恥的事情, 這樣大家才會及時去修復. 否則大家就會鬆懈, 久而久之 build 就一直處於失敗的狀態. 就算之後有人挺身而出要去處理, 他也要花很長的時間才能解決. 然後又很久才會在通過, 這樣的悲劇就一直在上演.
2. 在 check-in 之前要先測試
開發人員在將 code check-in 到 main stream 時, 要先在你的機器上進行測試. 所以第一步就是先將 source code control system 的程式先 check-out 下來, 在你的機器上進行編譯, 接著再進行測試, 當全部都沒有問題, 才將你的程式 check-in 到 main stream 上面.
這樣的好處, 可以讓問題在你的機器上提早發生, 提前就先修復, 避免在 build machine 上才發生, 會影響到很多人.
可惜這一步是大多數開發團隊所缺乏的, check-in 死到誰之後再說 XDD
3. 測試有錯要立即處理
CI 執行後測試沒有通過, 要馬上釐清出問題出在哪裡, 並且立即處理, 否則別人再 check-in 進來會一直都不過, 並且他還要釐清到底是他新寫的東西有問題, 還是上一次遺留下來的問題.
4. 若有錯誤, 要能回復到上一個正確的狀態
有時候 CI 測試不過無法短時間解決掉, 這時候需要準備另一個解決方法: rollback. 要能把程式回復到前一個可運行版本, 這個過程也是要可以自動化的, 這樣我們可以隨時回滾, 並且確保我們不會遺漏任何東西.
這件事情也是大部份人實施 CI 系統時沒有做的, 都認為自己都不會犯錯, 如果有錯, 也不會有搞不定的時間. 就算搞不定, 馬上就可以手動回上一版.
這四個實踐都很不容易做到, 需要團隊成員通力合作, 堅持做對的事情, 這樣才能讓持續整合的效果展現出來.
留言列表
