项目版本管理的最佳实践：云效飞流Flow篇
簡介： 飛流Flow的最佳實踐（使用阿里云云效）為了更好地使用飛流Flow，接下來將結合阿里云云效來講解飛流Flow的最佳實踐
目錄
?
一、分支規約
?
二、版本號規約
?
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篇的所有內容，歡迎在評論區討論與提出改進意見！
原文鏈接
本文為阿里云原創內容，未經允許不得轉載。
總結
以上是生活随笔為你收集整理的项目版本管理的最佳实践：云效飞流Flow篇的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Let‘s Fluent：更顺滑的MyB
- 下一篇： 爱奇艺体育：体验Serverless极致