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

1. 多個敏捷團隊之間的版本控制 (3)
http://www.infoq.com/articles/agile-­‐version-­‐control
Version
Control
for
Multiple
Agile
Teams
Posted
by
Henrik
Kniberg
on
Mar
31,
2008
多個團隊——如果其他團隊也同時向主幹發佈程式那該怎麼辦？
假設我們有團隊 A 和團隊 B, 他們都是跨功能的團隊, 並且一起開發一個航班訂
票系統. 團隊 A 的重點放在開發訂票流程, 而團隊 B 主要負責後台相關功能.
假設他們現在要開始一個 sprint，每個團隊要開發兩個使用者故事 (通常一個
sprint 中會有更多的故事要做)
在發行程式到主幹前, 每個團隊都要進行測試, 因此他們有各自的工作分支.

2. 現在我們遇到了一個有趣的問題. 假設我在團隊 A 中, 而且我們有自己的工作分
支. 變更可能在主幹中發生, 而不會出現在我的工作分支中! 為什麼? 嗯, 因為
有另一個團隊存在, 他們每完成一個故事就會將其發行到主幹中!
所以在任何給定的時刻，在主幹上都可能有我不知道的新的程式, 而且這些程式
可能 (但願不會如此) 會跟我的程式衝突! 也許團隊 B 中的某人會重新命名
Widget class, 可是我已經在我的程式中呼叫了它, 而且……呃……等一下，我們
不是剛談過這個話題了嗎?
是, 沒錯, 相同的問題, 解決也相同, 但是範圍有點不同.
規則: 每天都從主幹中 check-out 程式合併到你的工作分支
每天開始工作時，我所在的團隊的某人負責將最新的程式, 從主幹中合併到我們
的團隊工作分支中（=“跟上”主幹中發 生的變化）。
如果我的團隊 (團隊 A) 發現一個代碼衝突, 我們會馬上解決它 - 這是最高優
先順序的事! 如果我們需要團隊B的幫助 (或者是寫出和我們程式相衝的人), 找

3. 他們過來, 一起把問題解決掉. 重點是我的團隊要負責解決問題, 並且要在我們
的工作分支上(而不是在主幹上) 完成.
規則：在比較不穩定的分支上解決衝突
當然，如果大家不常常向主幹發行代碼, 那從主幹 check-out 城市來合併就是
浪費時間了. 除非有人發行工作到主幹上, 否則團隊 A 和團隊 B 之間的任何分歧
都是不可見的. 所以接下來的規則如下:
規則：經常將工作分支向主幹發行程式. 例如每做完一個故事之後, 不要等
到 sprint 結束才向主幹發行程式
注意這裡有一個有趣的副作用:
副作用：先 check-in 程式的先贏!
如果兩個團隊正在開發的程式, 發現互相衝突, 後面 check-in 的團隊必須負責
解決衝突問題. 這是一個好的副作用, 因為它可以鼓勵團隊儘早 check-in 程
式。 :o)
下面是一個完整 Sprint 範例:
兩個團隊進行了一次 6 天的 sprint. 團隊 A 準備實作預訂和取消. 團部 B 準備實
作發票和黑名單. 讓我們看看發生了什麼事.

4. 第幾天 團隊 A 的觀點 團隊 Ｂ 的觀點 主幹的觀點
1 從主幹下載程式碼來合併,
沒有新的內容. 開始開發
預訂. 將程式 check-in
到自己的工作分支
從主幹下載程式碼來合併,
沒有新的內容. 開始開發
發票. 將程式 check-in
到自己的工作分支
今天沒事發
生
2 從主幹下載程式碼來合併,
沒有新的內容. 完成預訂
的實作, 通過整合測試, 搞
定了! 複製到主幹. 開始
開發取消
跟昨天相同 預定做完了
3 從主幹下載程式碼來合併,
沒有新的內容. 仍在開發
取消
從主幹下載程式碼來合併,
啊哈, 添加了預訂相關的
程式. 合併到團隊 B 分支
中的程式, 解決任何的程
式衝突, 然後繼續開發發
票
今天沒事發
生
4 跟昨天相同 從主幹下載程式碼來合併,
沒有新的內容. 完成發票
的實作。通過(包括預訂在
內的)整合測試, 複製到主
幹. 開始開發黑名單
發票做完了
5 從主幹下載程式碼來合併.
啊哈, 添加了發票相關的
程式. 合併到團隊 A 分支
中的程式, 解決任何的程
式衝突, 然後繼續開發取
消
從主幹下載程式碼來合併,
沒有新的內容. 仍在開發
黑名單
今天沒事發
生
6 從主幹下載程式碼來合併,
沒有新的內容. 做完取消
的實作, 複製到主幹
跟昨天相同 取消做完了

5. Sprint 結束了! 除黑名單外, 所有的故事都完成了. 但是沒關係, 我們還是可以
發佈! 這是因為我們是以漸進的方式, 完成合併與整合的工作. 如果我們等到
sprint 結束再做, 任何分叉代碼的問題, 就會在錯誤的時刻被發現 - 此時我們
能夠用來修復問題的時間會是最少.
發布分支
假定我們完成了 sprint 1, 並發佈了系統的 1.0.0 版本. 現在, 當我們在進行
sprint 2 時，有人說之前發佈的版本中, 發現一個嚴重的缺陷! 噢, 不! 我們該怎
麼辦?
最簡單的方式是在主幹上修復這個問題, 然後發佈 1.1.0 版本. 這意味著在
sprint 2中, 目前所有新實現的故事, 都會包括在新發佈版本中. 理論上來說, 這
應該是可以的, 因為主幹是做完的分支, 而做完的定義就是可以發佈的. 所以在
任何時候, 主幹上的內容都是我們可以發佈的東西.
但是, 還是有些原因導致我們現在不想發佈新的故事. 例如:
• 發現了嚴重的缺陷這件事意味著, 主幹在發佈時就已經有問題了. 也就是說
sprint 2 的故事都是在有問題的基礎上構建的. 在繼續處理新的故事之前, 我們
可能想要修復這個基礎.
• 可能利害關係人不希望在 sprint 中間, 有新的功能被發佈
• 從主幹中, 要發佈一個包含新功能和全部現有功能的新版本, 也許需要一點時
間才能完成, 所以我們需要一個簡單的“hotfix”機制, 來讓修復的問題可以更
快的出門.
所以我們該如何做呢？
1. 建立一個叫做 “發布 1.0”的發佈分支, 它的內容是基於主幹可發佈時的內
容來產生的.
2. 在發佈分支上, 針對缺陷產生補丁.
3. 在發佈之後, 馬上將發佈分支的程式合併到主幹上面 (這樣補丁的內容, 將
會包括在未來的發佈中)

6. 注意, 當我們在發佈 1.0.0 版本時, 不需要建立”發佈 1.0”的分支, 可以等到問
題出現時再做. 除非真的需要在那個分支上做些什麼, 否則我們就不需要創建額
外的分支.