目錄

一、分支規約

二、版本號規約

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

2.2 次版本號（迭代號）

2.3 小版本號

三、云效飛流Flow優秀實踐（使用阿里云云效）

3.1 總體流程圖

3.2 弓行同學與阿吉同學的優秀實踐

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

3.2.2 流水線的創建

3.2.3 日常環境發布

3.2.4 預發環境發布

3.2.5 危險分支下線

3.2.6 生產環境發布

3.2.7 生產環境發布:寫基線

四、FAQ

一、分支規約

二、版本號規約

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

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創建三條功能分支，防止三條分支的功能代碼互相耦合。

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

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: 云效Flow下如何進行code review和拉取請求？

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

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

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

Q3: 我可以不使用云效來實現Flow嗎？

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

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篇的所有內容。