1.5 統(tǒng)一代碼分支策略

想必大家看到這里，應(yīng)該迫不及待地想看代碼質(zhì)量提升項(xiàng)目如何運(yùn)轉(zhuǎn)了。但就在這個(gè)時(shí)候，我們發(fā)現(xiàn)一個(gè)非常棘手的問(wèn)題，若這個(gè)問(wèn)題不解決，很難讓各團(tuán)隊(duì)進(jìn)行有效配合，更難對(duì)各指標(biāo)采用同一個(gè)評(píng)估標(biāo)準(zhǔn)。

既然可視化平臺(tái)展現(xiàn)了各團(tuán)隊(duì)的指標(biāo)數(shù)據(jù)，這就意味著開(kāi)啟了團(tuán)隊(duì)間的比較；既然我們把這些指標(biāo)和趨勢(shì)圖搬到了代碼質(zhì)量委員會(huì)上，就要確保這些指標(biāo)是準(zhǔn)確的。否則，效能團(tuán)隊(duì)肯定會(huì)遭到質(zhì)疑，進(jìn)而導(dǎo)致項(xiàng)目推進(jìn)受阻。

所以，先不著急，在運(yùn)轉(zhuǎn)項(xiàng)目前，我們先把這些影響指標(biāo)數(shù)據(jù)準(zhǔn)確性的因素找出來(lái)，然后和所有團(tuán)隊(duì)達(dá)成一致意見(jiàn)，按照統(tǒng)一的標(biāo)準(zhǔn)行事。這是很重要的。

1.5.1 往往簡(jiǎn)單的問(wèn)題最復(fù)雜

基于當(dāng)前現(xiàn)狀，我們?cè)谧龃a質(zhì)量指標(biāo)計(jì)算時(shí)，遇到如下問(wèn)題。

1）技術(shù)團(tuán)隊(duì)有4個(gè)部署環(huán)境，分別是開(kāi)發(fā)環(huán)境、測(cè)試環(huán)境、預(yù)生產(chǎn)環(huán)境和生產(chǎn)環(huán)境，多環(huán)境將導(dǎo)致分支策略和指標(biāo)統(tǒng)計(jì)規(guī)則的復(fù)雜度增加。

我們想度量部署到各環(huán)境中的代碼質(zhì)量，因各團(tuán)隊(duì)使用的觸發(fā)分支不一致，而無(wú)法使用統(tǒng)一的指標(biāo)統(tǒng)計(jì)規(guī)則。若針對(duì)不同環(huán)境和團(tuán)隊(duì)設(shè)置不同的分支策略，可視化度量平臺(tái)設(shè)計(jì)成本就會(huì)增加。所以，觸發(fā)分支策略和各環(huán)境相對(duì)應(yīng)很重要。

2）各團(tuán)隊(duì)的分支開(kāi)發(fā)模式不一致，導(dǎo)致指標(biāo)計(jì)算方式比較復(fù)雜。

比較常見(jiàn)的3種分支開(kāi)發(fā)模式為主干開(kāi)發(fā)、分支發(fā)布，分支開(kāi)發(fā)、主干發(fā)布，主干開(kāi)發(fā)、主干發(fā)布。統(tǒng)一分支開(kāi)發(fā)模式很重要。圖1-12所示為分支開(kāi)發(fā)、主干發(fā)布模式。若采用這種分支開(kāi)發(fā)模式，我們只需設(shè)置在分支代碼合并到主干時(shí)觸發(fā)指標(biāo)計(jì)算即可。

3）各團(tuán)隊(duì)分支工作流使用不統(tǒng)一，導(dǎo)致部署在不同環(huán)境中的代碼指標(biāo)重復(fù)計(jì)算多次。

技術(shù)團(tuán)隊(duì)使用的代碼管理工具是Git。基于Git使用最廣泛的分支工作流有Git Flow、GitHub Flow、GitLab Flow。其中，GitLab Flow是一個(gè)基于環(huán)境分支屬性的工作流程（適用于為不同的部署環(huán)境創(chuàng)建不同分支的項(xiàng)目，所有的代碼都要在不同環(huán)境中測(cè)試通過(guò)），如圖1-13所示。其中，master、test、pre-prod、production這4個(gè)分支分別為主干分支、測(cè)試分支、預(yù)生產(chǎn)分支和生產(chǎn)分支。若采用這種工作流，我們可能只需在觸發(fā)測(cè)試分支部署到測(cè)試環(huán)境時(shí)計(jì)算指標(biāo)；在部署到其他環(huán)境，構(gòu)建流水線時(shí)，無(wú)須再重復(fù)計(jì)算相關(guān)指標(biāo)，因?yàn)榇舜a已經(jīng)在測(cè)試環(huán)境中驗(yàn)證過(guò)。

我們?cè)居?jì)劃隨意選擇一個(gè)工作流，然后找各技術(shù)部門負(fù)責(zé)人做評(píng)審，盡早達(dá)成統(tǒng)一；但當(dāng)我們?cè)谛》秶鷥?nèi)調(diào)研時(shí)，結(jié)果大吃一驚：80%研發(fā)人員投了反對(duì)票。我們不得不停止此事的推進(jìn)，還需要再深入了解他們的業(yè)務(wù)場(chǎng)景和痛點(diǎn)。

經(jīng)過(guò)如上分析不難看出，若使用標(biāo)準(zhǔn)的工作流，各分支采用統(tǒng)一的命名規(guī)范，并為每個(gè)分支名賦予一定的意義，同時(shí)將相應(yīng)的觸發(fā)分支綁定到不同環(huán)境，這樣看似能把所有問(wèn)題都解決。但實(shí)際上，由于各研發(fā)人員在不同的文化環(huán)境下養(yǎng)成的研發(fā)習(xí)慣不同，這種代碼分支策略很難實(shí)行。

先看一下在實(shí)際的代碼管理過(guò)程中，我們經(jīng)常遇到什么問(wèn)題。

? 合并后的代碼若其中一個(gè)分支出現(xiàn)問(wèn)題，需要回滾所有分支的代碼。

? 線上版本出現(xiàn)Bug，若此時(shí)需要快速發(fā)布，得及時(shí)清理出一個(gè)滿足線上發(fā)布的“純凈”版本。

? 緊急需求插入，導(dǎo)致上線計(jì)劃調(diào)整，部分已經(jīng)合并的分支功能需要摘出來(lái)延后上線。

基于這些現(xiàn)狀，有的團(tuán)隊(duì)比如前端團(tuán)隊(duì)就很難接受Git工作流。前端團(tuán)隊(duì)是一個(gè)技術(shù)團(tuán)隊(duì)各部門共用的強(qiáng)職能團(tuán)隊(duì)，它們需要對(duì)接所有的后端研發(fā)團(tuán)隊(duì)。在代碼管理過(guò)程中，如它們每天都會(huì)遇到以上問(wèn)題。若使用Git工作流，它們每天可能需要花費(fèi)很長(zhǎng)時(shí)間在分支開(kāi)發(fā)和分支發(fā)布的溝通協(xié)調(diào)上。這對(duì)于它們來(lái)說(shuō)就是一場(chǎng)噩夢(mèng)。

我們將代碼分支規(guī)范、分支開(kāi)發(fā)模式以及分支工作流問(wèn)題歸結(jié)為代碼分支策略問(wèn)題。這件事看起來(lái)簡(jiǎn)單，但我們來(lái)回折騰了一個(gè)月才與技術(shù)團(tuán)隊(duì)達(dá)成一致意見(jiàn)。接下來(lái)就讓我們針對(duì)代碼分支策略的不統(tǒng)一問(wèn)題給出解決方案吧！

1.5.2 適合自己的才是最重要的

這期間的幾周，我們每天都輾轉(zhuǎn)反側(cè)，若這個(gè)事情不能達(dá)成一致意見(jiàn)，代碼質(zhì)量提升還如何推進(jìn)？改進(jìn)期間，我們采用的臨時(shí)策略是：只固定采集develop分支觸發(fā)構(gòu)建的代碼，develop分支默認(rèn)對(duì)應(yīng)開(kāi)發(fā)環(huán)境的構(gòu)建和部署，其他都不限制，先讓工作開(kāi)展下去，再想后續(xù)如何統(tǒng)一策略。

讀到這里大家可能會(huì)想為什么選擇develop分支？因?yàn)閷?duì)于研發(fā)人員來(lái)說(shuō)，他們的編碼和調(diào)試活動(dòng)除了在本地進(jìn)行外，還需要在開(kāi)發(fā)環(huán)境進(jìn)行頻繁構(gòu)建和部署來(lái)驗(yàn)證問(wèn)題。

我們結(jié)合調(diào)研信息，想了一天一夜，終于想清楚了他們的痛點(diǎn)（研發(fā)的要求），并給出解決方案和策略，如表1-1所示。

GitLab平臺(tái)針對(duì)項(xiàng)目分支做如下檢查。（以下數(shù)值和限制不一定適合所有團(tuán)隊(duì)，思路供參考。）

（1）項(xiàng)目分支命名規(guī)范檢查

源碼庫(kù)只接收符合如下項(xiàng)目分支命名規(guī)范的分支。

1）所有分支名稱中只能包含（0-9|A-Z|a-z|-.），不可出現(xiàn)中文或特殊字符，各變量都統(tǒng)一保持小寫；

2）版本號(hào)：A.B.C（AB產(chǎn)品定義，C研發(fā)定義，都必須是數(shù)字），例：V1.2.333；

3）master：主分支；

4）develop：開(kāi)發(fā)分支；

5）develop-1：測(cè)試分支；

6）hotfix：修復(fù)Bug分支，hotfix-yyyyMMdd-{版本號(hào)}；

7）feature功能分支：feature-yyyyMMdd-{版本號(hào)}；

8）release版本分支：release-[v]{版本號(hào)}-{release內(nèi)容描述}；

9）tag分支：release*分支打標(biāo)簽，全大寫或全小寫的項(xiàng)目名稱格式為-[tag|TAG]-[v]{版本號(hào)}。

各分支來(lái)源可按照Git Flow規(guī)范獲取，比如hotfix-*分支來(lái)源于master分支。

（2）限制項(xiàng)目遠(yuǎn)端分支總數(shù)

1）遠(yuǎn)端release-*分支總數(shù)不多于5；

2）遠(yuǎn)端hotfix-*分支總數(shù)不多于5；

3）遠(yuǎn)端feature-*分支總數(shù)，需小于等于團(tuán)隊(duì)寫權(quán)限人數(shù)（忽略繼承Git組中的寫權(quán)限成員），feature分支總數(shù)小于10不做檢查；

4）項(xiàng)目分支總數(shù)需小于“項(xiàng)目寫權(quán)限人數(shù)+21”（21=1個(gè)master分支+5個(gè)release分支+5個(gè)hotfix分支+10個(gè)feature分支）。

（3）限制觸發(fā)分支和環(huán)境綁定

1）生產(chǎn)環(huán)境：在master或者release-*分支上打標(biāo)簽；

2）預(yù)生產(chǎn)環(huán)境：綁定release-*分支；

3）測(cè)試環(huán)境：綁定develop-1分支；

4）開(kāi)發(fā)環(huán)境：綁定develop分支。

同時(shí)，一些特殊分支有如下限制。

1）配置develop和develop-1分支為保護(hù)分支；

2）只允許hotfix-*分支合并到develop、release-*分支。當(dāng)合并到release-*分支時(shí)，需校驗(yàn)提交的代碼已經(jīng)合并到develop和develop-1分支，否則合并失敗；

3）只允許feature-*分支合并到develop和release-*分支。當(dāng)合并到release-*分支時(shí)，需校驗(yàn)提交的代碼同步合并到develop和develop-1分支，否則合并失敗。

分支若不符合規(guī)范，控制臺(tái)會(huì)提示錯(cuò)誤并終止遠(yuǎn)端代碼合并，此時(shí)不會(huì)觸發(fā)流水線執(zhí)行。檢查效果示例如圖1-14所示。

在和研發(fā)團(tuán)隊(duì)達(dá)成一致意見(jiàn)后，之前的問(wèn)題都已得到解決。

1）部署到各環(huán)境中的代碼質(zhì)量都可以進(jìn)行指標(biāo)度量，特別是開(kāi)發(fā)環(huán)境中對(duì)應(yīng)的代碼質(zhì)量。（若平臺(tái)已經(jīng)實(shí)現(xiàn)了一次打包、多次部署功能，部署到后續(xù)環(huán)境的代碼質(zhì)量已經(jīng)在開(kāi)發(fā)環(huán)境度量過(guò)了，無(wú)須重復(fù)度量。）

2）代碼質(zhì)量指標(biāo)的統(tǒng)計(jì)方式已經(jīng)統(tǒng)一（比如平臺(tái)采集所有項(xiàng)目的develop分支代碼進(jìn)行質(zhì)量分析等），意味著各團(tuán)隊(duì)的代碼質(zhì)量指標(biāo)可以在同一個(gè)平臺(tái)進(jìn)行對(duì)比、查看和分析。

3）并行開(kāi)發(fā)分支沖突以及分層部署驗(yàn)證（所有的代碼都要在各環(huán)境中測(cè)試通過(guò)）問(wèn)題，我們將在第3章講述解決方案，不過(guò)也需要基于統(tǒng)一的代碼分支策略。

經(jīng)過(guò)一個(gè)月的苦戰(zhàn)，我們不僅解決了指標(biāo)度量問(wèn)題，也解決了技術(shù)團(tuán)隊(duì)代碼分支策略問(wèn)題，提升了與研發(fā)團(tuán)隊(duì)的溝通協(xié)作效率，同時(shí)增進(jìn)了與研發(fā)團(tuán)隊(duì)的信任。

此時(shí)，效能團(tuán)隊(duì)規(guī)模達(dá)到5人，已處在人強(qiáng)馬未壯階段。

接下來(lái)，讓我們一起把項(xiàng)目運(yùn)轉(zhuǎn)起來(lái)吧！