沒有自動化, 就沒有準時交付 @ David Ko的學習之旅

在敏捷開發中, 我們都知道要將功能切割, 每次做些小功能, 然後持續交付價值給客戶.

因此當你在開發每個小功能時, 你會不斷進行以下事情:
1. 從主幹 check out 程式碼到分支
2. 開發團隊在分支進行開發
3. 小功能開發完後, 將分支程式, merge 回主幹
4. 在主幹進行測試

可是通常這樣在第四步時, 就會遇到一堆錯誤. 這是因為小功能還沒確認是否正確, 就和整個系統和起來測試, 將導致問題多多. 如果有很多小功能要放進來時, 這種情況就會更惡化.

因此有些團隊可能會這樣做:
1. 從主幹 check out 程式碼到分支
2. 開發團隊在分支進行開發
3. 開發完畢在分支進行測試
4. 在分支測試通過, 將分支程式, merge 回主幹
5. 在主幹再進行測試

這樣做之後, 可以讓小功能測試比較穩定後, 再放到主幹來. 可是遇到多個小功能同時開發時, 還是會遇到你進來的東西會跟別人不和, 導致整個系統無法運作.

所以下一步你會在這樣改進:
1. 從主幹 check out 程式碼到分支
2. 開發團隊在分支進行開發
3. 開發完畢在分支進行測試
4. 把主幹的程式 merge 到分支
5. 把 merge 完後的分支程式進行測試
6. 將 merge 完後的分支程式, 再 merge 回主幹
7. 在主幹再進行測試

因此你先確認小功能是否運作正常; 然後將主幹的程式合併到分支後, 再確認是否正確; 最後合併到主幹後, 在做一次確認是否都正常.

看起來到目前為止, 應該考慮的很周到.

可是... 有多少人這樣做呢? 似乎很少, 為什麼正確的事情, 大家都不做呢? 因為這樣反覆進行的測試工作, 如果你沒有自動化, 你就會沒有空, 或者討厭去做這樣的事情, 導致大家就很少去做.

有些人說沒問題, 我們會把測試自動化搞好, 這是小事. 於是他們就開始處理測試自動化的問題, 接著你又會發現到:
要能自動產生 build, 否則每次手動要花多時間
測試環境要自動準備好, 沒有乾淨的環境, 測試結果可能會有影響
每個小功能整合到主幹後, 有可能之後出問題, 要重新回上個版本, 這個事情若是手動做, 也是件崩潰的事情
……

所以再做下去, 你會發現整件事情沒有你想像的單純, 若是沒有落實 continuous integration 或是 continuous delivery, 你永遠沒有機會達到 agile 所說的, 每個 iteration 持續交付價值給客戶. 你所有的, 將會是至少落後一個 iteration 的交付. 因為在 agile 中, 每個 iteration 測試和開發要花的代價不同, 測試的代價是隨著 iteration 的進行, 逐漸高升.