項(xiàng)目版本管理的優(yōu)秀實(shí)踐：云效飛流Flow篇

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

云計(jì)算

一、分支規(guī)約

二、版本號(hào)規(guī)約

2.1 主版本號(hào)（首位版本號(hào)）

2.2 次版本號(hào)（迭代號(hào)）

2.3 小版本號(hào)

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

3.1 總體流程圖

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

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

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

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

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

3.2.5 危險(xiǎn)分支下線

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

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

四、FAQ

一、分支規(guī)約

二、版本號(hào)規(guī)約

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

V主版本號(hào).次版本號(hào).小版本號(hào)

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

2.1 主版本號(hào)（首位版本號(hào)）

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

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

2.2 次版本號(hào)（迭代號(hào)）

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

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

2.3 小版本號(hào)

小版本號(hào)，是為了某些小功能的臨時(shí)上線，熱修復(fù)的臨時(shí)上線設(shè)置的小迭代，通常不包含大的功能性更新，常常是圍繞某個(gè)功能點(diǎn)進(jìn)行升級(jí)或者某個(gè)bug的修復(fù)進(jìn)行上線。

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

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

3.1 總體流程圖

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

3.2 弓行同學(xué)與阿吉同學(xué)的最佳實(shí)踐

這里要邀請(qǐng)出兩位同學(xué)進(jìn)行接下來的講解，他們是【弓行】同學(xué)與【阿吉】同學(xué)。

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

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

某個(gè)bug的修復(fù)【弓行同學(xué)】

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

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

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

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

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

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

弓行同學(xué)是這樣創(chuàng)建他的項(xiàng)目流水線的（請(qǐng)無視正式環(huán)境的構(gòu)建失敗）：

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

即：【分支集成】-【前后端構(gòu)建】-【前后端制品】-【前后端部署】

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

需要注意的是，因?yàn)槲覀冃枰褂蔑w流Flow對(duì)項(xiàng)目進(jìn)行版本管理，因此在第一步【源】選擇時(shí)，選擇的版本庫(kù)需要開啟分支模式（同一條流水線存在多個(gè)構(gòu)建源時(shí)（如一個(gè)流水線需要同時(shí)構(gòu)建前后端的情況），只支持一個(gè)源設(shè)置分支模式）

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

完成了流水線的設(shè)置后，可以點(diǎn)擊【運(yùn)行】對(duì)流水線進(jìn)行測(cè)試。在運(yùn)行時(shí)，由于開啟了分支模式，此時(shí)需要將本次加入【DEV日常流水線】的分支加入到構(gòu)建列表中。

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

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

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

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

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

此時(shí)則需要到預(yù)發(fā)的流水線中，對(duì)這兩條分支進(jìn)行集成操作。

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

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

測(cè)試同學(xué)和開發(fā)同學(xué)便可以在預(yù)發(fā)環(huán)境對(duì)功能進(jìn)行預(yù)發(fā)驗(yàn)證。

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

3.2.5 危險(xiǎn)分支下線

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

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

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

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

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

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

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

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

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

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

四、FAQ

Q1: 云效Flow下如何進(jìn)行code review和拉取請(qǐng)求？

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

Q2: 云效Flow適合什么樣的開發(fā)場(chǎng)景或者開發(fā)團(tuán)隊(duì)？

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

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

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

Q4 : 遠(yuǎn)程feature分支可以不刪除嗎？

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

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

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