項目版本管理的優(yōu)秀實踐：云效飛流flow篇

作者：佚名 2021-05-10 09:38:06

云計算

創(chuàng)新互聯(lián)公司專業(yè)為企業(yè)提供撫順網(wǎng)站建設、撫順做網(wǎng)站、撫順網(wǎng)站設計、撫順網(wǎng)站制作等企業(yè)網(wǎng)站建設、網(wǎng)頁設計與制作、撫順企業(yè)網(wǎng)站模板建站服務，十多年撫順做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡服務。

 目錄

一、分支規(guī)約

二、版本號規(guī)約

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

2.2 次版本號（迭代號）

2.3 小版本號

三、云效飛流Flow優(yōu)秀實踐（使用阿里云云效）

3.1 總體流程圖

3.2 弓行同學與阿吉同學的優(yōu)秀實踐

3.2.1 功能分支(feature分支)的創(chuàng)建

3.2.2 流水線的創(chuàng)建

3.2.3 日常環(huán)境發(fā)布

3.2.4 預發(fā)環(huán)境發(fā)布

3.2.5 危險分支下線

3.2.6 生產(chǎn)環(huán)境發(fā)布

3.2.7 生產(chǎn)環(huán)境發(fā)布:寫基線

四、FAQ

一、分支規(guī)約

二、版本號規(guī)約

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

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

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

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

主版本號，也叫首位版本號、頂位版本號，即V后第一個版本號。主版本號一般代表項目的期數(shù)與產(chǎn)品方向。除非項目合同改變、大規(guī)模api不兼容、產(chǎn)品方向改變、底層架構升級等情況外不輕易更新。

另外，項目未正式發(fā)布、未正式孵化、未正式上線，則首位版本號為0，一期發(fā)布，則為V1，二期發(fā)布則為V2。

2.2 次版本號（迭代號）

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

如V1.1.0：第一期項目第一迭代發(fā)布版本、V1.2.0：第一期第二迭代發(fā)布版本、第一期第十八個迭代發(fā)布版本:V1.18.0。

2.3 小版本號

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

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

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

3.1 總體流程圖

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

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

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

3.2.1 功能分支(feature分支)的創(chuàng)建

項目組規(guī)劃了迭代V1.1.0，迭代backlogs包括

某個bug的修復【弓行同學】

function1 功能的開發(fā)【阿吉同學】

function2 功能的開發(fā)【弓行同學】

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

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

3.2.2 流水線的創(chuàng)建

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

弓行同學是這樣創(chuàng)建他的項目流水線的（請無視正式環(huán)境的構建失?。?/p>

日常環(huán)境和預發(fā)環(huán)境常用于開發(fā)與測試，因此他的步驟比較簡單：

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

注：在【部署階段】，為當前流水線制定部署的機器便可完成流水線和部署環(huán)境的綁定。

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

3.2.3 日常環(huán)境發(fā)布

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

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

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

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

3.2.4 預發(fā)環(huán)境發(fā)布

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

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

選擇完需要集成的分支之后，點擊運行，便可以實現(xiàn)在預發(fā)環(huán)境發(fā)布這兩條分支。

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

測試同學和開發(fā)同學便可以在預發(fā)環(huán)境對功能進行預發(fā)驗證。

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

3.2.5 危險分支下線

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

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

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

3.2.6 生產(chǎn)環(huán)境發(fā)布

將通過測試的分支在生產(chǎn)流水線中添加（如3.2.4步）并實現(xiàn)構建便可完成生產(chǎn)環(huán)境的發(fā)布，生產(chǎn)環(huán)境運行的分支也是一條release分支。

在實踐中，推薦將生產(chǎn)環(huán)境的發(fā)布流程增加人工卡點（審批），即流水線的設置可以如下：

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

3.2.7 生產(chǎn)環(huán)境發(fā)布:寫基線

寫基線是指將發(fā)布分支的代碼合并到當前master分支中，一般在完成生產(chǎn)驗證之后執(zhí)行。

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

四、FAQ

Q1: 云效Flow下如何進行code review和拉取請求？

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

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

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

Q3: 我可以不使用云效來實現(xiàn)Flow嗎？

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

Q4 : 遠程feature分支可以不刪除嗎？

A4：遠程feature可以不刪除，但是由于feature在發(fā)布后已經(jīng)合并到了基線，不刪除留存在遠程版本庫意義不大。

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

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

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

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

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

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

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

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

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

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

以上便是項目版本管理的最佳實踐：云效飛流Flow篇的所有內(nèi)容。

文章標題：項目版本管理的優(yōu)秀實踐：云效飛流Flow篇
網(wǎng)站鏈接：http://www.5511xx.com/article/djscigh.html