阿里云云效平臺分支管理模型—飛流Flow，也就是阿里的AoneFlow，飛流Flow是基于git的多主干分支模式的版本管理模型（也叫分支模型），區別于傳統使用develop分支、release分支和master的gitflow，飛流Flow采用了 feature + n*release + master 的分支形式實作版本管理，而其中，n * release 代表了各環境的發布分支，

在本文中的最佳實踐章節中，筆者將以阿里云云效平臺作為載體，介紹飛流Flow(AoneFlow)的最佳實踐，

一、分支規約

分支	分支名	說明
特性分支 (開發分支)	origin/feature_${specific_feature}	該分支為變更分支或者特性分支，用于承載具體的功能開發與缺陷修復，基于最新的master拉出，${specific_feature} 為具體開發的功能目標，每發起一個變更（特性開發或缺陷修復），都需要創建一個feature與變更進行對應，一般的開發作業都會在此分支上進行，
集成分支	origin/release_${build_no}	該分支主要用于集成和發布，即在環境中（如日常、預發和生產）對各feature分支進行集成和部署，不同的環境下可以使用不同的release分支（如release_daily、release_pre和release_prod）對feature進行集成（即 n * release ），
主干分支	origin/master [只讀保護]	master代表當前專案的基線，不允許直接修改，各分支功能在驗證通過并發布到生產驗證后，將分支集成后release合并回master，保證master代碼最新；若某個feature功能驗證不通過，可以單獨撤下該feature的集成再合并回master，從而實作風險的全域最小影響，

二、版本號規約

在最佳實踐中，我們常用的版本號為三位數版本號，其構成如下：

V主版本號.次版本號.小版本號

eg：V1.0.0、V1.5.0、V1.13.1等

2.1 主版本號（首位版本號）

主版本號，也叫首位版本號、頂位版本號，即V后第一個版本號，主版本號一般代表專案的期數與產品方向，除非專案合同改變、大規模api不兼容、產品方向改變、底層架構升級等情況外不輕易更新，

另外，專案未正式發布、未正式范訓、未正式上線，則首位版本號為0，一期發布，則為V1，二期發布則為V2，

2.2 次版本號（迭代號）

次版本號，也叫迭代號，一般代表某個迭代發布的功能集合（一個迭代發布會包含若干個功能更新），

如V1.1.0：第一期專案第一迭代發布版本、V1.2.0：第一期第二迭代發布版本、第一期第十八個迭代發布版本:V1.18.0，

2.3 小版本號

小版本號，是為了某些小功能的臨時上線，熱修復的臨時上線設定的小迭代，通常不包含大的功能性更新，常常是圍繞某個功能點進行升級或者某個bug的修復進行上線，

三、飛流Flow的最佳實踐（使用阿里云云效）

為了更好地使用飛流Flow，接下來將結合阿里云云效來講解飛流Flow的最佳實踐

3.1 總體流程圖

下圖為最樂觀形式下的飛流Flow模型圖，可以見到，release分支是多個feature的集成版本，同時，release又可以通過流水線進行組織，使用在不同的專案環境構建下，

3.2 弓行同學與阿吉同學的最佳實踐

這里要邀請出兩位同學進行接下來的講解，他們是【弓行】同學與【阿吉】同學，

3.2.1 功能分支(feature分支)的創建

專案組規劃了迭代V1.1.0，迭代backlogs包括

某個bug的修復【弓行同學】
function1 功能的開發【阿吉同學】
function2 功能的開發【弓行同學】

迭代開始時，弓行同學與阿吉同學將會基于master創建三條功能分支，防止三條分支的功能代碼互相耦合，

backlogs	分支
某個bug的修復	origin/feature_bugfix
function1 功能的開發	origin/feature_function1
function2 功能的開發	origin/feature_function2

完成分支創建后，版本庫中的分支情況便如下圖所示，各負責開發的同學可以在各分支上進行開發而不互相影響，

3.2.2 流水線的創建

在云效中，可以將流水線分為三種環境，他們是：【日常環境】、【預發環境】和【生產環境】，云效中的流水線為我們提供了各式各樣靈活的構建步驟、部署步驟和人工卡點模版，我們可以基于不同的需求創建流水線的流程，

弓行同學是這樣創建他的專案流水線的（請無視正式環境的構建失敗）：

日常環境和預發環境常用于開發與測驗，因此他的步驟比較簡單：

即：【分支集成】-【前后端構建】-【前后端制品】-【前后端部署】

注：在【部署階段】，為當前流水線制定部署的機器便可完成流水線和部署環境的系結，

需要注意的是，因為我們需要使用飛流Flow對專案進行版本管理，因此在第一步【源】選擇時，選擇的版本庫需要開啟分支模式（同一條流水線存在多個構建源時（如一個流水線需要同時構建前后端的情況），只支持一個源設定分支模式）

3.2.3 日常環境發布

完成了流水線的設定后，可以點擊【運行】對流水線進行測驗，在運行時，由于開啟了分支模式，此時需要將本次加入【DEV日常流水線】的分支加入到構建串列中，

運行后，分支管理器會對feature_bugfix、feature_function1、feature_function2 等三個分支進行集成，并生成一個新的【origin/release】分支（如下圖），而這個release分支就是專門服務于日常環境的發布分支了，

此時，我們的版本線是這樣的（紅線代表由云效分支管理器的自動集成），需要注意的是，release分支的我們不應該直接修改（除了解決沖突外）

而隨著日常開發的持續進行，每當分支上有同學提交了代碼并觸發了流水線的重新運行，分支管理器變會對分支進行集成處理，形成包含最新分支代碼的commit

3.2.4 預發環境發布

經過每天辛辛苦苦的搬磚，由阿吉同學負責的function1功能和弓行同學負責的bugfix通過了自測和日常冒煙，可以上預發進行驗證了，

此時則需要到預發的流水線中，對這兩條分支進行集成操作，

選擇完需要集成的分支之后，點擊運行，便可以實作在預發環境發布這兩條分支，

此時的版本線是這樣的（綠線代表由預發流水線分支管理器的集成），如此一來，預發環境便得到了只包含bugfix和function1而不含沒有冒煙通過的function2的最新代碼的純凈提交，

測驗同學和開發同學便可以在預發環境對功能進行預發驗證，

同理，當弓行同學的function2功能也開發自測完、在日常冒煙驗證后，在預發流水線里添加他的分支，便可以完成對function2的集成了，至此，整個版本線如下所示：

3.2.5 危險分支下線

在預發環境進行預發驗證和測驗時，測驗同學發現由【阿吉】同學開發的function1功能雖然完成了開發，但是他的改動會影響某個功能正常運行，而發布日迫在眉睫，現在改動一定是來不及的，此時阿吉同學的feature_function1分支便是一個危險分支，不能夠上線，此時，需要在預發流水線對阿吉同學的代碼進行下線操作，

下線后，因為涉及到的改動會比較多，此時云效的分支管理器會自動將feature_function2和feature_bugfix兩條分支重新集成到為我們創建的另一條預發環境使用的發布分支【release_pre_2】中，以減少代碼沖突解決的次數，

此時，版本線如下圖所示（藍線為云效分支管理器集成，而原origin/release_pre分支已經廢除，取而代之的是origin/release_pre2）：

3.2.6 生產環境發布

將通過測驗的分支在生產流水線中添加（如3.2.4步）并實作構建便可完成生產環境的發布，生產環境運行的分支也是一條release分支，

在實踐中，推薦將生產環境的發布流程增加人工卡點（審批），即流水線的設定可以如下：

【構建】-【部署審批（人工卡點）】-【灰度部署(分批)】-【生產部署(分批)】-【生產驗證(人工卡點)】-【寫基線】

3.2.7 生產環境發布:寫基線

寫基線是指將發布分支的代碼合并到當前master分支中，一般在完成生產驗證之后執行，

完成發布后，整體個版本線流程圖是

四、FAQ

Q1: AoneFlow下如何進行code review和拉取請求？

A1: 基于AoneFlow進行團隊協作開發時，可以圍繞feature分支進行code review和pr操作，即除了保護release分支外，還保護feature分支，不允許直接提交到feature分支，且另外創建origin/feature_xxx_pr分支進行拉取請求，不僅如此，在最終發布到生產之前，設定一個人工卡點來進行code review操作也是可行的，只是code review的粒度不一樣（前者基于每個commit、后者基于發布的整個功能），如果團隊的發布節奏比較緊急且人力資源不太充足，可以采取發布前進行人工卡點 + 團隊code review的形式，

Q2: AoneFlow適合什么樣的開發場景或者開發團隊？

A2：AoneFlow適合團隊規模適中，一個迭代中所需要開發的backlogs涉及到不同的業務域，且存在分支發布風隙訓存在迭代周期交叉情況（如1.2.1與1.3.0同時開發并提測）的敏捷團隊，如上述最佳實踐中，【阿吉】同學開發的function1在臨近上線前發現會影響其他業務功能開發，需要臨時下車不發布；如果一個開發團隊中只有兩三個人，那么一切從簡便可，

Q3: 我可以不使用云效來實作AoneFlow嗎？

A3：目前來看，使用云效來實作AoneFlow是最省時間的，若不使用云效，可以采用人工管理release分支的構建+jenkins流水線的形式也是可以實作AoneFlow的（或者采用腳本自動合并分支）

Q4 : 遠程feature分支可以不洗掉嗎？

A4：遠程feature可以不洗掉，但是由于feature在發布后已經合并到了基線，不洗掉留存在遠程版本庫意義不大，

Q5: 多個分支同時開發，遇到代碼沖突怎么辦？

A5：云效提供了完成的沖突解決教程，最安全的做法是將集成分支拉到本地，在本地解決沖突后，構建成功后再提交到遠程release分支

Q6: 下一次迭代，還需要重新創建流水線嗎？

A6: 不需要，只需要在原先的流水線中將原來需要集成的分支洗掉（實際上發布后也會自動洗掉），重新添加需要發布的功能分支上去便可

Q7: 預發、日常都集成了同一個feature，重新構建的話新提交會影響兩個環境嗎？

A7: 一旦預發流水線、日常流水線都集成了同一個feature分支，那么開發者提交代碼后觸發重新部署，在預發環境和日常環境都會呈現最新的功能特性

Q8: 幾條release分支會互相合并嗎（如日常的release和預發的release）？

A8: 不會，release分支相互獨立，完全沒有一點關系，他們的相同也只是名字上的部分相同而已，

Q9: 對比了gitflow、AoneFlow感覺更加靈活和自由，對風險的控制也是比較穩妥的，那么AoneFlow是最好的版本管理模型嗎？

A9：沒有最好的版本管理模型，適合自己生產的具體情況的才是最好的

以上便是專案版本管理的最佳實踐：飛流Flow(阿里AoneFlow)篇的所有內容，歡迎在評論區討論與提出改進意見！

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/242373.html

標籤：其他

上一篇：Mysql相互復制（互為主從）詳細配置步驟

下一篇：一起學爬蟲（Python） — 22 自動化詳解

專案版本管理的最佳實踐：飛流Flow（阿里AoneFlow）篇

導航

目錄