當Branch遇到持續整合（2）：Branch for Release

June 25 14:29~15:17

 

今天要介紹跟「Develop on Mainline」經常一起搭配使用的Branch for Release（為了釋出而分支）。如果鄉民們有看前一集的介紹並且瞭解了Develop on Mainline模式，哪麼Branch for Release就很簡單了。以下是這個模式的特點：

• 功能都是在trunk上開發，也就是說Branch for Release必須要跟Develop on Mainline搭配使用。在這邊Teddy先偷跑說明一下，Branch for Release是可以跟其他三個模式（Develop on Mainline、Branch by Feature、Branch by Team）一起搭配使用。
• 當trunk上面的程式碼功能已經完整到可以釋出的時候，而且鄉民們還要繼續開發新的功能就為這次的釋出產生一個branch。產品釋出後還需要持續開發新功能這一點很重要，如果產品功能到達可以釋出的階段，但是鄉民們並沒有打算為此產品繼續開發新的功能，那麼就不一定需要為此次的釋出而產生一個branch，直接釋出trunk上的版本即可。
• 當產品釋出之後，針對每一個釋出版本所做的bug fix直接送交到該版本的branch中，確認這些修正沒有問題之後在merge回trunk。以上圖為例，1.0.x版的bugfix會先merge回trunk中，然後在merge到1.1.x版中。由此圖可看出來，每個版本的bugfix要先merge回trunk，然後再判斷是否要進一步merge到其他各個release的branch。如果一個軟體釋出的版本越多，這種merge的時機點越需要小心謹慎，以免發生沒merge沒事，一merge之後整個軟體反而無法建構的問題（Teddy內心獨白：難道這就是傳說的中越補越大洞的靈異現象？！）。
• 最後一點，也是與持續整合最相關的一點，原本trunk上的專案在持續整合系統上一定會有一個相對應的專案這一點鄉民們應該都了解了。一旦為了釋出而產生一個branch之後，鄉民們也要幫這個釋出版本在持續整合系統上新增一個專案，這樣日後才有「人」可以幫這個釋出版本所做的修改或是bugfix做整合與建構的工作。如上圖所示，版本控制系統中有一個trunk和兩個釋出（Release 1.0.x與Release 1.1.x），而持續整合系統上也有三個專案，分別用來建構trunk、Release 1.0.x與Release 1.1.x。
  

***

就這樣，Branch for Release可以算是一個「輔助模式」，因為它跟軟體的主要開發活動無關，而是用來保持不同釋出軟體版本之用。最後一個送分題：何種開發情境適合Branch for Release？如果鄉民們看到這邊還不知道就要打屁股了，答案很簡單，就是軟體要釋出的時候…XD。

***

友藏內心獨白：最後一句難道就是傳說中的廢話？！