什麼是Release Train?

無敵碼農 無敵碼農 10月18日

導讀

今天給大家介紹下Google的Release Train Model（俗稱火車發版模型）。大家知道，在公司初創的時候，產品技術人數比較少，版本發佈的流程也比較簡單，速度也非常快，只需要那麼一兩個技術骨幹把控好代碼質量就基本上不會出現太多的問題。

而如果公司進入快速發展階段，產品技術人員迅速擴展，產品需求迭代的種類和規模都成倍增加的情況下，之前依賴於個別人的套路可能就會玩不轉了，因為此時產品、開發已經劃分多條線，溝通成本已經變得很高，稍不注意就會出現問題，導致線上問題不斷。這也就是為什麼我們經常會感覺很多創業公司“亂”的原因之一。

當然還有很多其他原因會導致創業公司讓人感覺混亂，這裡不是我們要討論的重點，在本篇文章中，我們主要討論如何讓產品迭代更加高效有序的Release Train流程。

Release Train的基本思想

Releae Train簡單來說就是一種軟件發佈的形式和計劃。不同業務線可以根據發佈的獨立性來制定自己的Release Train。以一個互聯網App的發佈為例，假設固定每兩週發佈一個版本（或者叫發一趟車可能比較形象），那麼針對App中不同的功能需求，參與各方包括產品經理、技術（涉及前後端）、QA都需要提前互相溝通好自己的需求和內容，並在規定的時間內完成相應的步驟，如果沒有問題能趕上車就正式跟車，如果存在某些問題那麼就要及時下車，以免影響其他需求的上線和產品的正常迭代。

一句話就是“車是按照時間發的，能趕上火車的就一起走，趕不上火車的，就只能等待下一班車了！”，通過這種發佈形式確保產品的持續迭代。如何協調好產品、技術、QA等參與方，以及制定合理的時間節點，是確保Release Trian流程能夠正常運轉的關鍵。

發車時間軸

如果按照每兩週一個版本的迭代速度，為了確保每趟車都能夠順利發車，在Release Trian流程上就需要有嚴格的計劃。

release trian流程

在這個時間軸中，很多工作其實是需要提前做的，在正式上車之前PM需要組織需求評審、開發人員需要根據需求進行功能開發。此時該需求的開發代碼處於功能開發分支上（具體關於開發代碼分支管理的內容可以在後面進行討論），如果功能開發完畢，準備搭乘本躺車，就需要嚴格按照圖中的時間軸運轉。

在每週四需要TPM或項目經理組織召開Cut Meeting會議，及時Cut掉無法按照正常節奏上車的需求或功能。一旦Cut Meeting後，剩下的功能和需求就需要全力確保進度，各需求開發負責人需要在週五前完成代碼自測併合並至本次發佈代碼版本中，如果無法完成的需要自覺週末加班，確保最晚週日20:00錢完成本次Release所有功能的提測。

代碼分支管理

在整個Release Trian流程中，在一個版本的發佈流程中，可能會涉及多個開發人員同時並行進行開發，如何確保代碼不衝突就需要對代碼分支進行合理的管理。

為了更好的適配整個Release Trian流程，需要對代碼分支進行有效地命名，對於需要Release的代碼分支，統一用release/1.1.x 這樣的方式命名，並需要約定相應的權限。

這裡介紹兩種主要代碼發佈流程：

（一）、新功能開發&Release

這是主要的代碼開發流程，當一名開發人員開始開發一個新功能時，需要從master上拉取一個分支前綴命名為feature/<feature-name>的開發代碼分支，並在該分支上完成自己的功能開發及自測工作。/<feature-name>

如果該功能需要跟上某躺車，進入一個Release Train流程，則需要根據流程中的時間節點，在完成代碼自測後聯繫相應的release master，這是的release master是指負責負責本躺車涉及的所有公共代碼工程合併的技術人員。當準備開始一次Release Train時Release Master會從master代碼分支中拉取分支前綴為release/1.0.x這樣的發佈分支。

之後，功能開發人員提出從feature分支到release分支的Merge Request，並將assignee指向release master或者所屬項目的owner。release master或者項目owner進行code review，當code review通過後，接受Merge Request。

至此就完成了流程中各端代碼的Merge工作，如果沒有問題就正式將release分支代碼提請QA測試。最後，在完成正式線上發佈後再將release分支代碼合併至master分支，本次release train完成！

流程示意圖如下：

（二）、線上問題緊急修復（Hotfix）

如果線上發現緊急Bug，需要針對線上版本代碼進行緊急修復的話，需要相應問題責任開發從master拉取前綴名為hotfix/<hotfix-name>的修復分支，當完成代碼bug修復工作並自測完成後，向線上運行的release版本代碼發起Merge Request，與正常流程一樣需要相關的人員進行code review，完成後由release master接受合併，release分支提請QA測試，完成後上線。最後將此次hotfix所產生的代碼，再次從release分支合併到master分支，以便下一次的Release Train流程。/<hotfix-name>

流程示意圖如下：

後記

Release Trian是一種比較有效的發版模型，從流程上來說並不是很複雜，只是用好這種模型，還需要處理好很多細節的內容，即有代碼工程方面、也有團隊制度、流程等方面的內容。

希望本文的內容能對你所有幫助，如果覺得有所收穫，感謝關注本頭條號，您的支持，將是是作者不懈的動力！

搜索關注微信公眾號【“無敵碼農”】獲取更多精彩內容！！