目錄

一、分支規約

二、版本號規約

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篇的所有內容,歡迎在評論區討論與提出改進意見!

本文爲阿里雲原創內容,未經允許不得轉載。

相關文章