l

2012年6月28日 星期四

當Branch遇到持續整合(4):Branch by Team

June 25 21:49~ 23:00

螢幕快照 2012-06-25 下午9.49.40

 

這一集要介紹四個「分支/合併模式」的最後一個Branch by Team(依團隊而分支)。Branch by Team的主要目的是要讓一個很大的團隊(數十人以上)可以同時開發一個專案或產品,但是同時還要維持trunk上的程式碼達到隨時可釋出的狀態。其主要做法為:

  • 將一個大團隊分成數個人數在九個人左右的較小團隊。
  • 每個團隊都是一個feature team,也就是說,整個專案依功能被切成若干的功能模組,而每個團隊負責開發至少一個功能模組。例如,假設有一個48人的團隊要開發一個圖書館管理系統,整個系統被分成讀者管理模組、書籍管理模組、借還書模組、期刊管理模組、電子書管理模組、報表管理模組等六大模組。整個團隊被分成六個小組,每個小組剛好八個人。這六組人馬就被指派分別開發上述那六大模組。
  • 為每一個團隊產生一個branch,每一個團隊就在自己所屬的branch上開發。
  • 當branch上的程式碼達到穩定的狀態時,branch才可以被merge回trunk。
  • 每次merge回trunk的程式碼必須要立即在merge到其他團隊的branch之中。

同樣是做branch,Branch by Team和Branch by Feature有一點很大的不同,那就是前者的branch是很「長壽」的branch,只要團隊還在,這個branch就存在。而後者的branch是很「短命」的branch,只要功能完成之後將branch的程式被merge回trunk之後該branch的生命也就跟著結束了。由於Branch by Team的branch生命週期很長,所以開發團隊就可以為每一個branch在持續整合系統上面建立一個建構專案也就是說,持續整合的工作在branch與trunk上同時執行

***

看完這四種「分支/合併模式」的介紹,還有應用時機和持續整合系統之間的關係,鄉民們應該可以發現,一個看起來很簡單的版本控制系統與持續整合的實務做法,其實箇中還是有著奧妙的學問。開發團隊必須依據專案與團隊的特性來選擇適合自己的「分支/合併模式」。不過還好扣除掉Branch for Release這個為了軟體釋出而存在的模式,真正用在開發上的模式只有三個。而這三個也很容易選擇:

  • 團隊人數很少:
    • 團隊成員集中:Develop on Mainline或是Branch by Feature
    • 團隊成員分散:Branch by Feature
  • 團隊人數很多:Branch by Team
  • 開放原始碼專案:Branch by Feature
  • 需要經常實施持續整合:Develop on Mainline或Branch by Team

***

友藏內心獨白:看完這四個模式,心中的疑惑又少了一個。

沒有留言:

張貼留言