Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

482 views

Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

多個敏捷團隊之間的版本控制 (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”的分支, 可以等到問 題出現時再做. 除非真的需要在那個分支上做些什麼, 否則我們就不需要創建額 外的分支.  

×