多個敏捷團隊之間的版本控制 (3)
http://www.infoq.com/articles/agile-­‐version-­‐control	
  
	
  
Version	
  Control	
  for	
  Multiple	
...
現在我們遇到了一個有趣的問題. 假設我在團隊 A 中, 而且我們有自己的工作分
支. 變更可能在主幹中發生, 而不會出現在我的工作分支中! 為什麼? 嗯, 因為
有另一個團隊存在, 他們每完成一個故事就會將其發行到主幹中!
所以在任何給定的時刻...
他們過來, 一起把問題解決掉. 重點是我的團隊要負責解決問題, 並且要在我們
的工作分支上(而不是在主幹上) 完成.
規則:在比較不穩定的分支上解決衝突
當然,如果大家不常常向主幹發行代碼, 那從主幹 check-out 城市來合併就是
浪費時...
第幾天 團隊 A 的觀點 團隊 B 的觀點 主幹的觀點
1 從主幹下載程式碼來合併,
沒有新的內容. 開始開發
預訂. 將程式 check-in
到自己的工作分支
從主幹下載程式碼來合併,
沒有新的內容. 開始開發
發票. 將程式 check-...
Sprint 結束了! 除黑名單外, 所有的故事都完成了. 但是沒關係, 我們還是可以
發佈! 這是因為我們是以漸進的方式, 完成合併與整合的工作. 如果我們等到
sprint 結束再做, 任何分叉代碼的問題, 就會在錯誤的時刻被發現 - 此時...
注意, 當我們在發佈 1.0.0 版本時, 不需要建立”發佈 1.0”的分支, 可以等到問
題出現時再做. 除非真的需要在那個分支上做些什麼, 否則我們就不需要創建額
外的分支.
	
  
Upcoming SlideShare
Loading in …5
×

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

415 views
347 views

Published on

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
415
On SlideShare
0
From Embeds
0
Number of Embeds
93
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

  1. 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. 2. 現在我們遇到了一個有趣的問題. 假設我在團隊 A 中, 而且我們有自己的工作分 支. 變更可能在主幹中發生, 而不會出現在我的工作分支中! 為什麼? 嗯, 因為 有另一個團隊存在, 他們每完成一個故事就會將其發行到主幹中! 所以在任何給定的時刻,在主幹上都可能有我不知道的新的程式, 而且這些程式 可能 (但願不會如此) 會跟我的程式衝突! 也許團隊 B 中的某人會重新命名 Widget class, 可是我已經在我的程式中呼叫了它, 而且……呃……等一下,我們 不是剛談過這個話題了嗎? 是, 沒錯, 相同的問題, 解決也相同, 但是範圍有點不同. 規則: 每天都從主幹中 check-out 程式合併到你的工作分支 每天開始工作時,我所在的團隊的某人負責將最新的程式, 從主幹中合併到我們 的團隊工作分支中(=“跟上”主幹中發 生的變化)。 如果我的團隊 (團隊 A) 發現一個代碼衝突, 我們會馬上解決它 - 這是最高優 先順序的事! 如果我們需要團隊B的幫助 (或者是寫出和我們程式相衝的人), 找
  3. 3. 他們過來, 一起把問題解決掉. 重點是我的團隊要負責解決問題, 並且要在我們 的工作分支上(而不是在主幹上) 完成. 規則:在比較不穩定的分支上解決衝突 當然,如果大家不常常向主幹發行代碼, 那從主幹 check-out 城市來合併就是 浪費時間了. 除非有人發行工作到主幹上, 否則團隊 A 和團隊 B 之間的任何分歧 都是不可見的. 所以接下來的規則如下: 規則:經常將工作分支向主幹發行程式. 例如每做完一個故事之後, 不要等 到 sprint 結束才向主幹發行程式 注意這裡有一個有趣的副作用: 副作用:先 check-in 程式的先贏! 如果兩個團隊正在開發的程式, 發現互相衝突, 後面 check-in 的團隊必須負責 解決衝突問題. 這是一個好的副作用, 因為它可以鼓勵團隊儘早 check-in 程 式。 :o) 下面是一個完整 Sprint 範例: 兩個團隊進行了一次 6 天的 sprint. 團隊 A 準備實作預訂和取消. 團部 B 準備實 作發票和黑名單. 讓我們看看發生了什麼事.
  4. 4. 第幾天 團隊 A 的觀點 團隊 B 的觀點 主幹的觀點 1 從主幹下載程式碼來合併, 沒有新的內容. 開始開發 預訂. 將程式 check-in 到自己的工作分支 從主幹下載程式碼來合併, 沒有新的內容. 開始開發 發票. 將程式 check-in 到自己的工作分支 今天沒事發 生 2 從主幹下載程式碼來合併, 沒有新的內容. 完成預訂 的實作, 通過整合測試, 搞 定了! 複製到主幹. 開始 開發取消 跟昨天相同 預定做完了 3 從主幹下載程式碼來合併, 沒有新的內容. 仍在開發 取消 從主幹下載程式碼來合併, 啊哈, 添加了預訂相關的 程式. 合併到團隊 B 分支 中的程式, 解決任何的程 式衝突, 然後繼續開發發 票 今天沒事發 生 4 跟昨天相同 從主幹下載程式碼來合併, 沒有新的內容. 完成發票 的實作。通過(包括預訂在 內的)整合測試, 複製到主 幹. 開始開發黑名單 發票做完了 5 從主幹下載程式碼來合併. 啊哈, 添加了發票相關的 程式. 合併到團隊 A 分支 中的程式, 解決任何的程 式衝突, 然後繼續開發取 消 從主幹下載程式碼來合併, 沒有新的內容. 仍在開發 黑名單 今天沒事發 生 6 從主幹下載程式碼來合併, 沒有新的內容. 做完取消 的實作, 複製到主幹 跟昨天相同 取消做完了
  5. 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. 6. 注意, 當我們在發佈 1.0.0 版本時, 不需要建立”發佈 1.0”的分支, 可以等到問 題出現時再做. 除非真的需要在那個分支上做些什麼, 否則我們就不需要創建額 外的分支.  

×