當Branch遇到持續整合（4）：Branch by Team

June 25 21:49~ 23:00

 

這一集要介紹四個「分支/合併模式」的最後一個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

***

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