敏捷開發中最基本的分支管理員模式實戰和補遺

關於3分支的開發方式,請詳見我的另一篇隨筆 <敏捷開發中最基本的分支管理員模式解析 >; 3分支模式的如下

如果你和你的Team Dev同時面臨以下幾個問題,那麼我強烈建議你至少考慮採用3分支的開發模式:

·         你開發只用一個分支或兩個分支.

·         你的項目已經進入維護階段,就是說項目本身已經上線使用.

·         使用者的後續修改很多,而且仍然會有突發性的緊急錯誤修複.

·         你的代碼需要通過測試人員測試才能發布.

·         你的發布人員就是簡單的把現有的分支打包發布.

如果你的項目組存在以上幾個問題,那麼可以說作為一個上線項目,你們的處境非常不利,你們每一次的發布都可能對原有系統產生不可預計的破壞;但不發布任何改動顯然是不行的,為不斷滿足客戶的要求,系統必須升級;要使每一次的發布對系統的影響降到最低,3分支方案是最基本的解決辦法.

要採用3分支的開發模式,其實並不困難,首先,我先假設一下你們項目組擁有以下3個角色(並不一定是3個人):

Ø 開發人員

Ø 測試人員

Ø 發布人員

如何產生3分支:

Ø 首先,確認目前的版本的代碼和現行系統的內容一致.

Ø 把現行的分支命名為主幹分支(Main)

Ø 從主幹分支分出2個分支,分別命名為開發分支(Development)和發布分支(Release)

Ø 明確分支的負責人: 開發人員負責開發分支,測試人員負責主幹分支,發布人員負責發布分支.

如何使用3分支

v 開發人員

Ø 開發人員人員可以在開發分支上開發目前的版本,並任意簽入代碼. 注意已經提交測試的版本,不能在開發分支上修改.

Ø 開發人員僅當被測試人員通知修複錯誤時,才能在主幹分支上修改指定的錯誤碼,並簽入.

Ø 開發人員僅當被發布人員許可的情況下,才能在發布分支上修複緊急錯誤;注意緊急修複一般都是非常緊急和微小的,如果改動較大,應該考慮進入版本開發.

Ø 如果開發人員認為某一個版本已經開發結束,他有權把開發分支現有的代碼完全合并入主幹分支,提交測試.(只有一個特例,就是上一個版本還沒有通過測試並發布,那麼下一個版本就不能合并入主幹分支,這屬於專案管理中的失誤,並不在本文章討論範圍)

v 測試人員    

Ø 測試人員有權在測試出錯誤後,讓開發人員在主幹上直接修複.

Ø 測試人員需要定期,將主幹分支代碼完全合并到開發分支. (這一步看似簡單, 但其實十分重要!)

Ø 測試人員可以在測試通過後,將主幹分支完全合并到發布分支,移交發布人員準備發布.

v 發布人員

Ø 發布人員可以允許開發人員直接在發布分支上修複緊急錯誤.

Ø 緊急修複後,發布人員需要把發布分支完全合并到主幹分支.

Ø 發布人員可以編譯發布分支,並製作發布版本.

 

不過開發中不可能是一帆風順的,緊急事件和臨時變更經常發生,面對各種開發中的緊急情況,我們應該如何利用多分支開發來減少臨時變更帶來的風險.(而且在處理某些特殊事件時,必須採用面向修改集的代碼合并技術才能解決問題,但產生的合并問題是不可預見的,這也是出現臨時變更時必須面對的風險.)

 

特殊情境	處理辦法
開發版本中任務需要緊急發布	不能保證開發的品質,對系統穩定極為不利,建議至少等到測試階段再更新
測試版本中任務需要緊急發布	前提是該任務已經通過測試,然後將該任務相關的修改集單獨合并到發布分支,然後緊急發布系統
開發版本中任務被取消	復原該任務對應的修改集,如果和其他代碼重疊,解決合并問題
測試版本中任務被取消	同樣採用復原的方式,但復原後,代碼必須再次合并回開發分支
開發版本中任務被延期	在版本開發結束時,採用修改集合并的方法代替最新版合并方式,把除該任務以外的修改集一一合并到主幹分支,留下的修改集進入下一個版本.
測試版本中任務被延期	類似於上面的方法,把版代碼合并到發布分支時,跳過該任務對應的修改集,把剩下的修改集分別合并入發布分支發布,被跳過的修改集保留到下一個版本提交.
緊急錯誤修複被取消	復原緊急修複代碼,如果該修複代碼已經合并回主幹分支了,還需要把復原後代碼再次合并回主幹分支,當然通過定期合并,還將合并回開發分支.