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

1. 1
多個敏捷團隊之間的版本控制(4)
http://www.infoq.com/articles/agile-­‐version-­‐control
Version
Control
for
Multiple
Agile
Teams
Posted
by
Henrik
Kniberg
on
Mar
31,
2008
縱觀全局
好的, 現在我已經給出一個的相當詳細範例, 讓你了解到如何使用這個模式. 讓
我們退後一點, 來看看整個的全局吧.
在主線 (mainline) 模型中, 一個分支被稱為是一條 codeline (實際上, 分支
可以被視為是一條 codeline 的實現). 有時候也叫做 streams.
一條 codeline 的父親 (也就是 codeline 的原先出處) 叫做它的基線
(baseline), 主線是沒有基線的 codeline.
所以上面的例子, 我們可以歸納出:
• 主幹是我們的主線. 它沒有父親, 不是嗎?
• 其他所有 codeline（發布版本 1.0, 團隊 A 的工作分支, 團隊 B 的工作分支）
都是以主幹作為其基線.
這裡有、一個更複雜的例子:

2. 2
這個圖形告訴我們:
• 專案 X 的 codeline 衍生自主線. 目前此專案已完成, 所以分支已經結束.
• 團隊 A 有一個作用中的工作分支, 它衍生自主線.
• 團隊 A 還有一個進行中的 spike 分支, 他則是衍生自團隊 A 的工作分支
• 發布版本 2.3 已關閉，因為 2.3 已經不在上線的系統, 並且不再被維護
每條 codeline 有一個相對其基線的堅固水平, 也就是說, 每條 codeline 要不
就比其基線更堅固, 要不就沒有基線堅固(比較柔軟)
• 一條堅固的 codeline 是穩定的, 徹底測試過的, 很少變更, 並且接近可以發
佈
• 一條柔軟的 codeline 是不穩定, 很少測試, 經常變更, 遠離可以發佈有點距
離
在繪製 codeline 時，堅固的 codeline 分支向上, 而柔軟的代碼線分支向下.
所有觀看上面圖形, 我們可以歸納出：
• 發佈版本 2.3 比主線更堅固
• 團隊 A 的工作分支比主線更柔軟
• 團隊 A 的 spike 比團隊 A 的工作分支更柔軟

3. 3
利用上面的方式來繪製圖表, 來說明分支的歷史是很有用. 但是如果同時有很多
分支存在, 可能就會有點混亂. 這裡有一個更清晰的格式, 只顯示了目前存在的
codeline 以及它們的衍生自於哪裡.
我建議你使用這個格式去繪製你的分支關係, 並起把它掛到團隊所在房間的牆
上. 當在討論整合的問題時, 看看這個圖表真的很有幫助.
這裡有一條重要的規則, 所有的變更都應沿著所在的線發展! 所以不能直接從團
隊 A 的工作分支向團隊 B 的工作分支去合併程式, 這會造成很多混亂. 反之, 在
團隊 A 工作分支中發生的變更, 應該流回到主線中, 然後再向下進入到團隊 B 的
工作分支中.
任何在主線之上面的 codeline 都可以叫做發佈 codeline, 也就是意味著這是
一個比主線更堅固的 codeline.
任何在主線下面的 codeline 都可以稱作是開發中 codeline (或工作
codeline), 這意味著它是一個比主線更柔軟的 codeline.
協作的黃金規則:
- 總是接受穩定的變更
- 絕不強制使用會導致不穩定的變更

4. 4
那麼這對於不同類型的 codeline 代表什麼意思呢?
上圖以顏色的方式說明了:
• 在發佈 codeline 上, 每當有任何的變更, 都應該立即合併到其基線中, 並發
佈到主線上。
o 範例: 在 2.4.2 版本中修復了一個 bug, 應該立即合併到 2.4 版本中, 並且
將其合併到主線上。
• 一個發佈 codeline 永遠不要從其基線接受變更
o 範例: 有新的程式被 check-in 到主線中, 但是這個變更不應該進入 2.3
版本和 2.4 版本.
• 變更應持續從基線流入到開發 codeline 中
o 範例: 任何針對主線的變更, 應該儘快往下流到團隊 A 和團隊 B 中, 以及
從團隊 A 往下流到團隊 A 的 spike 中.
• 開發中 codeline 的變更只有在穩定時, 才能發佈到基線中
o 範例: 只有當一個故事完成, 並且通過測試後, 團隊 B 才能向主線合併
它.
無論變更何時放到 codeline 及其基線，有些合併是需要做的. 因為程式合併是
一個很容易犯錯的操作, 我們希望在兩條 codeline 中稍柔軟的一條上進行, 一

5. 5
旦這個合併完成並且通過驗證, 我們可以把合併的程式, 複製回比較堅固的
codeline.
根據我們畫圖的慣例, 堅固的 codeline 要畫得比柔軟的 codeline 高, 所以我
們可以推出一個簡單的規則:
規則: 向下合併, 向上複製
範例：團隊 A 注意到主線已經被更新了, 他們將變更向下合併到自己的開發中
codeline, 並且修復任何衝突. 只要團隊 A 的開發中 codeline 達到一個穩定的
狀態, 他們會將程式複製回主線. 當然啦, 他們同時必須檢查主線上沒有發生任
何變更.
模型的變型
“版本控制模式”一節中, 描述了一個如何實施主線模型的範例.
“縱觀全局”一節中, 則以更一般化的方式描述了主線模型.
本節中, 我將對如何實踐該模式提出一些典型的變型.
“完成”的定義不必一定是“可發佈的“
先決定“完成”的定義, 然後確保有一個分支可以容納根據該定義已經“完成”
的故事. 不過, 要小心有些重要的內容沒到做完的定義裡. 例如, 整合測試沒有
包括在“完成”中, 那什麼時候你才要做整合測試呢?
主幹(Trunk)不必是主線(Mainline)
這個模型需要一條主線才能運作, 不過不需要是主幹(雖然在大部分的情形下,
使用主幹是很自然的選擇)
團隊不一定必須有自己的分支
你當然可以有多個團隊共享同一個分支, 或是甚至直接在主線上工作, 只要你遵
循分支的方針即可.
通常, 團隊希望有自己的分支, 避免未完成的故事造成其他個團隊的困擾.

6. 6
不需要每次都建立一個全新的發佈分支
你可以決定使用同樣的發布分支, 而不是在每個 sprint 結束後都建立一個新分
支. 那個發佈分支可以稱為“最新上線的版本”或是其他類似的名字. 如果同時
間, 在上線的系統中只有一個版本, 這當然是很好的模型.
不需要在每個 sprint 結束後都進行發佈
你可以在每個故事完成後進行發佈, 或者每三個 sprint 完成後發佈一次. 選擇你
自己的步調.
不需要對每個故事都運行回歸測試
如果在你的環境中，回歸測試或是整合測試很難做到, 那麼可以在 sprint 接近尾
聲的時候進行, 這樣你就可以批次對一堆故事進行測試和整合的工作. 不過這是
你要承擔的風險. 如果回歸測試和整合是包括在 “完成”的定義, 這可能意味
如果你在 sprint 尾聲時遇到問題, 可能會有沒有任何故事完成的風險.
FAQ
持續集成(CI)如何整合到這個模式中?
CI 伺服器應該對哪個分支作處理? 這要根據實際狀況而定. 不過以下是一個好
的起點.
假定主幹的方針是“完成而且可發佈”, 而每個工作分支的方針是“通過單元
測試”:
• 對每個工作分支來說, CI 伺服器會自動且持續地檢查構建和通過所有單元測試
o 如果有任何東西沒過, 就會發出一個紅色警告, 讓機器冒煙.
• 對每個工作分支來說, CI 伺服器自動且週期性地 (如果不能持續地) 進行整合
測試和回歸測試
o 如果有任何東西沒過, 就顯示一個的警告, 因為這不符合當前分支的方
針
o 每當有人考慮從工作分支向主幹發行程式時, 需要觸發手動測試, 用這
個方式去檢查故事是否“完成”
• 對主幹來說, CI 伺服器自動且持續地執行整合測試和回歸測試

7. 7
o 如果有任何東西沒過, 就發出一個紅色警告, 讓機器冒煙, 觸發警笛、
USB 火箭發射器, 再把國民警衛隊叫來.
哪種工具最合適這個版本控制的模型?
不確定. 我知道在 Perforce 中是可行的, 我想 subversion 應該也沒有問題, 但
是我不確定 CVS 是否可以. 任何建議都很歡迎.
不過要記得一個重要的事情 - 切換工具的成本要比不能有效合作的成本低得多!
所以想清楚你想怎麼做, 然後找到合適的工具來幫你.
與使用者故事無關的 check-in 要怎麼處理?
並非所有的程式變更都必須與某個使用者故事相關, 在上面例子中, 我的範例都
只是為了讓你容易了解才這樣做. 無論 check-in 哪種類型的程式 (或文檔之
類), 同樣的模型也是可以使用的.
合併程式很痛苦, 所以我想做得越少越好！
恭喜, 你得了合併恐懼症 - 對於合併程式的非理性恐懼! 合併讓你覺得痛苦是
因為你做的太少了. 越常合併, 痛苦就越少. :o)
我還有更多問題!
看看後面的參考資料! 我相信它們可以解決你大部分的問題.
參考資料
如果你想了解更多, 我強烈推薦下列資源
《Practical Perforce》
作者 Laura Wingerd. 這裡有一個試讀的章節
(http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf), 涵蓋了大
部份的主線模型
這是一本關於 Perforce 的書, 但是主線模型不會只適用於 Perforce.
《High level best practices in Software Configuration Management》
由Laura Wingerd和Chirstopher Seiwald所寫的, 有關於版本控制的常見最佳

8. 8
實踐的摘要, 非常有用.
《Branching and merging – an agile perspective》
由 Robert Cowham 所寫的, 和本篇文章有關的有趣文章.
(http://www.cmcrossroads.com/article/agile-perspective-branching-and-
merging)
《The Flow of Change》
又是由 Laura Wingerd 所作, 關於主線模型的摘要. 在縱觀全局一節中絕大部
分內容是根據這些投影片所改寫的.
關於作者
Henrik Kniberg 是位於斯德哥爾摩的 Crisp 公司的一名顧問, 擅長於 Java 和敏
捷軟體開發. 他建立了多個瑞典軟體公司, 並且熱衷於學習、講授和應用軟件開
發的藝術. Henrik 從事了多種類型的工作, 並喜歡擔任經理, 開發人員, Scrum
Master, 老師和教練等不同角色. Henrik 是熱門的 InfoQ 迷你書的作者
“Scrum and XP from the Trenches: How We Do Scrum”.