Version Control for Multiple Agile Teams, TC version

1. 多個敏捷團隊之間的版本控制
http://www.infoq.com/articles/agile-version-control
介紹
這篇文章是在描速, 在敏捷的環境中, 多個團隊之間如何進行版本控制工作的實
例. 我假設你已經熟悉 Scrum 的基本元素, XP 和任務板.這些方式不是我發明的.
它們是基於 mainline 模型或 stable trunk 模式. 想知道更多, 請參考引用部分.
撰寫這篇文章是因為我一直在遇到需要類似事情的團隊. 許多團隊在理解它之
後，似乎非常喜歡這些模型. 它也正是我們在 Scrum and XP from the
Trenches 中描述的公司, 所採納的方式. 它真的可以幫助我們, 以更敏捷的方
式來開發和發佈軟件. 利用方便閱讀的方式來描述這個模型, 也許我不需要一直
在白板前做解釋了。 :o)
注意這只是眾多模式中的一種, 並不是銀彈。如果你決定採取這個模型, 你可能
需要做出一些調整, 來適應你自己的特定的環境.
目標
在由多個團隊所組成的敏捷環境中, 版本控制模型必須達成以下目標:
快速失敗
程式碼的碼衝突和整合的問題應該可以被迅速發現
經常修復小問題會比久久修復一次大問題來的好
一直可以發佈
即使經歷了一個混亂的 Sprint, 應該至少有些可以發佈的內容。
簡單
所有的團隊成員每天都會使用這些方法, 所以相關的規則和程序必須要很
簡單

2. 單頁總結（可掛在牆上的內容）
如果這個圖讓你覺得很困惑, 別緊張, 閱讀本文即可. 如果這個圖形的想法對你
來說很明顯, 不看也無紡.

3. 版本控制模式
分支的擁有人&方針
這裡有一條簡單規則
規則：每個分支（即使是主幹分支）都有一個擁有人和一條方針
如果不遵守這個規則, 我們會一片混亂. 這個方針說明了, 什麼樣的內容可以檢
入到當前分支中. 擁有者是負責定義和確認規則執行情況的人。
“做完”概念
一個使用者故事怎麼樣才算”做完”? 更準確地說, 什麼時候團隊才可以把一
個使用者故事, 移入到任務版上的“完成”欄位中? 這實際上是代表什麼意思
呢?
我會定義下面的假設
假設：做完的定義=“可發佈”
所以當一個團隊成員說某個用戶故事已經做完, 並且將故事移入到“完成”這
個欄位, 客戶就可以馬上跑到房間, 並說: ”好棒！現在就上線吧!”, 並且團隊
中沒有人會說：“不, 先等一下”

4. 你可以使用任何你喜歡的“做完”的定義. 但是記得 - 如果定義中完全沒有包
含“可發佈”的說明, 你就要好好想想了: 什麼東西沒有被包含在“做完”的定
義? 誰會來補齊這些內容? 什麼時候? 如果在“做完成”之後出現問題, 那又
會如何?
“做完”的分支
當一個故事做完後, 它需要有一個歸屬之處. 根據我的做完的定義（可發佈）, 這
意味著系統中的某個分支可以發佈, 可以讓這個故事進入到生產線上. 這就是
“做完”的分支。
任何分支都可以是“做完”的分支。我將會使用主幹（trunk）來當作“做完”
的分支（這是一個不錯的開始）. 有時候這也被叫做“主線”.
假設：主幹就是“做完”的分支
主幹的方針：
* 任何時候都可以發佈
* 希望儘早發佈
“任何時候都發佈”這意味在任何時候, 產品負責人都可以根據主幹的最新版
本, 發佈新版本的產品.
這裡有一個範例
藍色的線表示主幹. 每個綠色的球形圖案表示一次 check-in. 所以在這次 Sprint

5. 中總共有 5 次 check-in. 雖然我們通常是在每個 Sprint 結尾時才進行發布, 不
過我們還是隨時可以從主幹中發佈. 如果在接近 Sprint 結束時, 有一半的人生病,
導致沒有時間完成故事 5, 我們還是可以發佈. 當然, 我們也可以選擇不發佈,
以等待團隊在下一個 Sprint 中完成故事 5.
“希望儘早發佈”意味著除非我們想讓某個故事相關功能上線（或者說不在乎它
是否上線）, 否則就不要 check-in 這個故事的代碼. 如果我不希望發佈上圖中
的故事 3, 這個分支就被我毀掉了. 由於這個分支不再是可發佈的，所以我就違
反了分支的方針。
規則：不要將不同發佈週期的內容放到同一個分支上
我們何時需要建立額外分支？
越少越好. 以下面是一條經驗法則
推薦: 只在下面這種狀況下才創建新的分支: 當需要 check-in 新的內容, 而
且沒有哪個現有的分支, 能夠在不違反自身方針的狀況下完成本次 check-in.
工作分支
好的, 假設我們已經有了一個很好, 很乾淨的主幹. 並且隨時是可以發佈的
等一下, 可發佈代表已完成整合測試. 這意味著我們需要進行整合測試. 也就
是說我們要在 check-in 到主幹前, 需要運行整合測試.
在 check-in 程式之前, 那我應該在何處驗證我認為已經完成的程式碼呢? 當
然, 我可以在本機上完成測試, 然後直接 check-in 到主乾中. 但這有點嚇人, 我
相信大家都遇到過”嘿，但是它在我的機器上跑得好好的”這樣的問題.
另外一個問題是“好吧, 我完成了今天的編碼任務, 現在要回家了. 我該把程式
碼 check-in 到哪裡? 還沒有測試過, 所以不能 check-in 到主幹中. 我想把它
check-in 到別的地方, 這樣其他的團隊成員就可以繼續處理它了”(敏捷團隊
= 程式碼所有權是共有的, 對吧?).

6. 你看這裡, 我們有希望 check-in 的內容, 但是不存在不違反分支方針就可以進
行 check-in 的地方. 這就是建立一個新分支的合理原因了。
我們把它稱為工作分支, 團隊所有成員都可共享該分支. 有人叫它是開發分支.
團隊 A 的工作分支方針:
程式完成編譯和構建, 並且所有的單元測試已通過.
很好, 現在我們有兩個分支了! 一個穩定的分支(主幹)和一個稍微不那麼穩定的
分支(團隊分支). 團隊分支是紅色的, 代表它不太穩定. 也就是這個分支通過了
單元測試, 但是它可能還沒有完成整合測試, 所以還沒有穩定到可以發佈的狀態.
好, 現在團隊有地方可以 check-in 正在進行中的工作了！
嗯…. 那麼不同的分支之間要怎麼同步呢？讓我們繼續往下看.