多個敏捷團隊之間的版本控制 (2)

1. 多個敏捷團隊之間的版本控制 (2)
http://www.infoq.com/articles/agile-­‐version-­‐control
Version
Control
for
Multiple
Agile
Teams
Posted
by
Henrik
Kniberg
on
Mar
31,
2008
從工作分支發行(publish)至主幹
在某個時間點(滿懷希望地), 一個故事已經做完. 或者更明確地說, 在某個時間
點, 工作分支會達到可發佈狀態. 此時我們可以(而且應該)將此分支發行到主幹
上. 也就是將工作分支上所有的新寫的程式複製到主幹上. 完成後, 主幹與工作
分支就完全相同了.
我們可以稱此過程為“發行(publishing)”, 因為我們已經完成了一些工作, 而
且現在已經準備好將其“發行”回主幹以供之後發佈. 這只是一個有幫助的隱
喻.
這裡有一個範例. 假設我們已經實現了兩個故事: 開戶和存款. 它們都已經做完.
也就是說通過了單元測試, 整合測試. 並且處於可發佈狀態. 我們已經開始處理
取款這個故事, 但是它還沒有做完. 任務板看起來會像這樣:

2. 在任務板上面, 每張黃色的便利貼代表一個工作, 也就是要完成故事所需要做的
一項工作. 例如編 class X，更新構建腳本等等. 每個工作通常是一個人天的工作,
每個故事通常需要 3 至 8 個人天的工作.
分支的歷程會像下面這樣:
所以我們團隊首先實現了開戶故事, 並將程式 check-in 到工作分支中, 進行整
合測試, 修復一些問題, 再次 check-in, 再次進行測試, 通過了! 開戶故事做完
了! 然後發行到主幹中.
接下來實作存款. 只需要一次 check-in 就可以了, 整合測試通過, 所以我們再次
把程式發佈到主幹中。
現在團隊正在實現取款的故事. 目前他們已經做了兩次 check-in, 但是還沒有
完成.

3. 注意, “發佈到主幹”並不意味我們只是把某個故事的程式, 直接拷貝到主幹中.
而是意味著我們把工作分支中, 所有事情拷貝到主幹中, 也就是做一次完整的同
步.
所以這樣就兩個很有趣的問題冒出來:
如果團隊同時在實作多個故事, 那該怎麼辦?
如果其他團隊也正在向主幹發行程式, 那又該怎麼辦?
我們還是一次看一個問題吧.
如果團隊同時在實現多個故事該怎麼辦？
如果團隊每次只實作一個故事, 然後將程式發行發佈到主幹中, 這並沒有什麼大
不了的. 只要這個故事在工作分支上完成實作, 並通過測試, 我們就可以把所有
東西, 從工作分支上複製到主幹上, 搞定.
但是先等一下, 如果團隊中, 我們同時開發多個故事呢? 如果開戶做完成, 而存
款正在進行中呢?
如果這個時候, 我們同步到主幹, 就會把尚未完成的存款故事同步進去, 這時候
它還不能發佈呢！違反了主幹的方針!
當然啦, 我們可以等到存款做完.

4. （等待……）
好了, 存款做完了! 太好了! 等一下……現在有人開始開發取款! 沒錯! 同樣的問
題又發生了!
如果存款的其中一個測試失敗了, 將會很難知道, 是因為存款的程式的緣故, 還
是因為有人 check-in 了部分完成的取款的程式到相同的分支的緣故.
等待這招是沒有用的. 這樣實際上是在滾雪球, 期望在未來某個假設的時間點上,
所有的故事都可以完成(如果這樣的情況真的能夠發生的話), 而且可以進行一次
大規模的發佈.
這是一個非常普遍的問題, 我們該怎麼做呢?
以下面是一些對策:
* 不要做過多的同時開發. 試圖將團隊的注意力每次都只放在一個故事上面.
* 如果在開戶做完成之前,就有人準備開始做存款, 必須要等到開戶徹底做完,
才能再 check-in 存款相關的程式碼. 或者可以將存款的程式 check-in 到一個
臨時的分支上面, 如果你喜歡處理多個分支的話.
* 如果在開戶做完前, 就有人準備開始做存款, 可以讓他先從一些相對安全
和不可見的部分開始, 這些程式的變化不會影響到整個分支的可發佈性. 例如,
存款需要寫一些新的程式, 以及對一些舊有程式碼的修改, 可以先開發新的代碼

5. (新的 method, 新的 class, 新的測試等等), 而不是先去修改已有程式碼. 如果
存款需要寫新的 GUI 元素, 則先讓它們不被看到. 等到開戶做完成, 而且發佈到
主幹之後, 我們才開始實現存款剩餘的部分.
下面是一個合適的規則集：
* 任何開發最高優先順序故事的人都是國王.
* 團隊其他的人都是僕人.
* 如果要是你想要當國王, 就試著找方法, 幫助完成最高優先順序故事的工
作吧
* 任何時候國王需要幫助時, 僕人需要馬上提供相應的服務
* 僕人不能打擾國王的工作
* 僕人不能 check-in 不可發佈的代碼到工作分支中. 國王可以 check-in 任
何他想要的東西 (當然啦, 只要他不違反分支方針即可)
* 當最高優先順序的故事一旦做完, 任何做下一個優先順序的人就變成了國
王
你甚至還能為團隊爭取到一些王冠飾品呢. :o)
總體來說，很多團隊都會高估同時實作多個故事的效果. 從開發速度的角度感覺
好像不錯, 但這只是一個幻象, 因為它將有風險以及要花很多時間的工作推到了
最後 - 像是程式碼合併, 整合與測試等工作.
這就是為什麼 Scrum 團隊應該保持小規模的原因 (少於 9 個人) - 這樣他們就可
以緊密協作, 並將將注意力集中於自己的工作成果上面. 如果每個人都只做自己
的故事, 那就不會有太多協同合作的事情發生. 當然你可以有人為將來的事情做
規劃, 準備下一個故事, 並先做一些實作的工作. 但是在任何時候, 團隊的主要
工作重心都要放在最高優先順序的故事上.
多個團隊就是不同的情況了. 多個團隊是被建立在當你想並行實作多個故事, 我
們不久後就會談到這件事. 現在, 我想先討論一下有關於回歸測試的事情, 以及
分叉代碼的相關話題.

6. 做完成包括回歸測試在內
當一個故事做完後, 我們會把它移入到完成這個欄位中, 並將相關的內容從工作
分支複製到主幹中. 但是因為主幹必須一直要保持可發佈狀態, 所以這裡有一個
重要的暗示。
規則：任何接觸到主幹的人, 必須保證整個主幹保持可發佈的狀態 - 包括之
前的所有功能!
實際上，這條規則意味著, 對故事 A 的測試，需包括對之前已經做完的故事的全
部相關回歸測試. 如果只是故事 A 沒有問題, 但是之前故事的測試卻不能通過,
這是不行的。
等等, 是不是有點不合理啊? 每次完成一個故事就要重跑所有的回歸測試?
嗯,, 首先, 我沒有說重跑所有的回顧測試, 我是說所有相關的回歸測試. 記
得嗎, 我們已經有了一個乾淨而且可發佈的主幹作為基礎，現在只是添加一個
故事而已! 這是一個很小的增量改變。如果回歸測試可以自動化, 我們就可以
全部重跑了. 但是如果有手動的回歸測試, 那我們就要有選擇性了.
這一切都是回歸到 風險 vs 成本 的平衡: 對於每一個手動的回歸測試, 我
們應該評估測試的成本 (例如需要多少工作來完成它) v.s 發現任何重要 bug
的可能性, 對二者進行權衡. 當然還要加入自動化該測試的成本. :o)
分叉代碼（合併衝突）
假設我正在興高采烈地撰寫呼叫 Widget class 的程式, 可是我卻不知道我的團
隊成員 Jim 在一個小時之前, 進行重構時移除了 Widget class. 所以我們現在就
有了分叉代碼. 在花費更多時間撰寫呼叫 Widget 類的程式前, 我希望能儘早發
現這樣的問題.
規則: 持續不斷地(=盡可能的多次)將你的程式同步到工作分支中。

7. 這個狀況的同步是雙向的. 從工作分支中 check-out 最新的程式來合併, 然後
再 check-in 你的程式. 第一步可以叫做“跟上”( = 我要知道其他人 check-in
了哪些內容). 第二步可以叫做“發行”( = 我希望我所做的更新, 可以讓團隊
其他人都知道).
每小時同步一次是好習慣. 基本上, 在進行工作切換或者沒有某項工作做到一半,
就可以進行同步. 這不只是關於“我要盡快知道別人的程式, 是否與我的相衝
突”, 還包括“我希望其他人盡快知道我的程式, 是否與他們的衝突”. 要記得
不要違反工作分支的方針 (單元測試要通過等等).
這規則聽起來很簡單, 但是請允許我再三敘述, 我希望大家都能對它非常清楚,
因為處理到多個團隊協作時，我們會再利用這樣的想法.