在一個專案中, 你可能分成很多小組去做開發. 多個小組會需要把他們寫完的程式放進 soruce control system, 或是從 soruce control system 把程式整合到他們手頭上的程式裡.

 

這時候你會遇到的問題是, 太多人 check-in 程式碼, 導致系統的穩定度變得很差, 甚至沒有任何build是可以運作的.

 

Henrik寫了一篇文章, 介紹在agile中, 如何處理這個問題, 你可以在以下URL中找到這篇文章
http://www.infoq.com/articles/agile-version-control

 

首先, 他先定義一些事情, 確保大家的假設是相同的

 

1. Branch
每個branch要有一個負責人和policy, 即使trunk也是一樣.

 

2. Done
甚麼叫做一個user story做完? 作者認為做完就是指這個user story可以被release

 

3. Done branch
作者假設Trunk是一個done branch, 它要遵守的policy是 1) 隨時可以release, 2) 要盡快去realase. 此外truk branch的rule是: 不要把不同的release cycles放到同一個branch中.

 

4. 甚麼時候需要建立額外的branch
越少越好 除非當你要check-in一些東西時, 發現你都必須違背現存branch的polcy, 這時候才需要建立一個新的branch

 

5. Work branch

當程式還沒開發完畢, 或是還沒測完, 這時候程式碼要放哪裡呢? Work branch是一個好的選擇. 你可能定義它的polcy為 1) 程式碼要能被編譯過, 2) 所有的單元測是要通過

 

6. Publish
當我們已經做完某個功能, 要把程式碼從work banch放到trunk去release, 這個動作叫作publish

 

 

 

這些名詞定義好了, 我們就可以來看如何進行版本控制, 這裡會依據組織架構和做事方法, 有以下組合:

 

A. 當我們只有一個小組, 並且一次只做一個user story, 事情會比較容易處理, 其步驟如下:

(1) 當程式寫完後, check-in 到 work branch
(2) 執行 integration test, 並且修復相關的 bugs
(3) 當所有測試通過並且bug也被修完時, 便可以 publish 到 trunk 中

 


B. 當我們只有一個小組, 可是同時進行多個user stories, 我們可能會遇到以下問題

(1) Engineer 可能會 check-in 還沒完成的程式碼到 work
因為他同時做很多 user story, 一定會有某個 user story 是在還在開發中, 可是大家都是在同一個 work branch 中, 你無法將 work branch 的東西都 publish 到 trunk 中


(2) 很難查出測試失敗的原因
當某個測試失敗時, 是因為已完成的 user story 有問題, 還是因為未完成的 user story 所產生的問題

 

最好的解法是不要同時時做很多 user stories. 每次都只處理最高優先順序的那個 user story. 這樣就可以用 A. 的做法來進行版本控制

一般人都誤認同時進行多個 user story 會比較快, 可是卻忽略了之後 merge 和整合測試所帶來的 effort, 往往需要花更多 effort 才能補救

 


C. 當我們只有多個小組, 每個小組只處理一個 user story, 在提這個問題之前, 作者先介紹兩個觀念

(1) Done 是要包含回歸測試的
Trunk 上的東西是要隨時可以 release 的, 因此每當你做完一個功能, 要 publish 到 trunk 時, 必須做 regression test 以確保之前的功能仍能運作正常


(2) 要常常整合有衝突的程式碼
當你的程式沒有常常 merge trunk 的程式, 時間長了以後, 你的程式便會和 trunk 的程式差距非常的大, 要 merge 的代價便會非常的大.

 

當多個小組各自開發自己的 user story, 雖然他們各自有自己的 work branch, 但是每當他們做完自己的 user story, 便會 check-in 到 trunk, 因此可能會造成其他小組和 trunk 的程式碼差距越來越大.

 

之後若是有別的小組要再 check-in 到 trunk 去, 便會因為和 trunk 差距甚大, 導致要整合很久.

 

 

基於這樣的問題, 和前面兩個觀念, 作者提出以下的作法:
(1) 每天都從 trunk 把程式碼merge到你小組的 work branch


(2) 在執行步驟(1)時若是發現 conflict, 則立刻解決, 以確保 work branch 基本的穩定度
 

(3) 為了讓別的小組不會跟你的小組程式碼差太多, 你必須周期性把你的程式碼 merge 回 trunk. 例如, 每當你的小組完成一個 user story 時, 便立即 merge 回trunk. 不要等到 sprint 的最後才 merge 回去.

 



arrow
arrow
    全站熱搜

    kojenchieh 發表在 痞客邦 留言(2) 人氣()