軟件多分支開發(fā)代碼漏合問題及解決途徑①

王曉龍,董玉雪

（中國海洋大學 基礎教學中心,青島 266100）

代碼管理在軟件發(fā)展過程中扮演者至關重要的角色,也是衡量軟件開發(fā)過程的一個重要指標,已經(jīng)被越來越多的企業(yè)所重視.隨著軟件需求和功能越來越復雜,對于代碼管理的要求也越來越高,良好的代碼管理可以提高整體開發(fā)效率,及時暴露問題[1,2].

分支管理是代碼管理過程中最常用的操作,也是最容易出錯的環(huán)節(jié)[3,4],目前的代碼分支管理更多的是利用Git或者SVN等成熟的版本控制工具進行維護,隨著軟件的功能和版本越來越復雜,代碼分支的數(shù)量日益增多,開發(fā)人員在代碼提交過程中難以保證分支代碼的一致性,日趨復雜的軟件開發(fā)活動給代碼分支管理帶來巨大的挑戰(zhàn),多分支代碼漏合[5,6]問題也應運而生,嚴重影響了軟件開發(fā)效率[2,7].為了更好的推動代碼分支管理,支撐軟件開發(fā)過程的快速有序進行,越來越多的公司已經(jīng)對代碼分支管理進行了深入的研究,伴隨著出現(xiàn)了許多代碼分支管理模型[3],例如FaceBook采用的主干開發(fā),主干發(fā)布模型,以單一主干分支支撐開發(fā)過程; Qunar、豬齒魚、阿里云效平臺采用的分支開發(fā),主干發(fā)布模型,將代碼的開發(fā)與發(fā)布過程通過分支進行劃分.代碼分支管理模型制定了代碼管理規(guī)范,優(yōu)化了代碼提交過程,對于提高軟件開發(fā)效率具有重要的作用.

雖然已有的代碼分支管理模型可以提高軟件開發(fā)的效率,但如果在實際應用中缺乏系統(tǒng)的管理,依然會存在很多問題.本文以Git版本管理工具作為研究對象[8],對開發(fā)過程中常用的代碼分支管理模式進行了研究分析,并基于分支開發(fā)、分支發(fā)布模式對多分支開發(fā)過程中的分支代碼漏合問題進行了解決途徑研究.本文的研究問題來源于實際應用場景,解決措施經(jīng)過了實踐的驗證,可以為多分支代碼管理的研究提供一定的參考.

1 多分支代碼漏合問題

多分支代碼管理是軟件開發(fā)過程中的重要活動,對于提高軟件開發(fā)效率和軟件質(zhì)量有重要的作用[9],做好代碼分支管理是軟件開發(fā)過程正常進行的有效保障[1,6].由于代碼開發(fā)過程的日趨復雜,多分支并行開發(fā)過程容易出現(xiàn)分支間代碼漏合問題且不易排查,代碼漏合問題主要是由如下幾個方面導致的.

1.1 分支操作權限混亂

代碼分支的操作權限缺乏統(tǒng)一的管理,分支的創(chuàng)建、刪除、合并等權限如果沒有按照等級分類進行分配,開發(fā)人員在自主創(chuàng)建代碼分支時容易導致多個重復分支的出現(xiàn),致使分支管理過程中出現(xiàn)代碼相互覆蓋、分支操作混亂等問題[5,10],最終導致未經(jīng)驗證的代碼直接流入生產(chǎn)環(huán)境.

1.2 分支管理缺乏規(guī)范

分支管理缺乏規(guī)范的指導,包括分支命名存在二義性、分支與代碼版本缺少對應關系,容易導致代碼提交過程混亂,出現(xiàn)代碼提交分支錯誤[6,10]和無法對歷史代碼及版本進行追溯等問題,增加了分支維護的難度[2,4,11].

1.3 分支合并流程混亂

分支代碼漏合主要是多分支并行開發(fā)過程中對于分支合并操作缺乏規(guī)范的操作流程,導致代碼合并時出現(xiàn)遺漏的現(xiàn)象,致使發(fā)布到生產(chǎn)環(huán)境中的軟件功能不全.常見的多分支開發(fā)場景及分支合并流程如圖1所示,代碼開發(fā)過程中新分支的創(chuàng)建可能來源于master分支上,也可能來源于已有的feature分支,每個分支負責一個feature功能開發(fā),進行版本發(fā)布時需要將該分支的代碼合入到master分支中,版本發(fā)布后需要將master分支的最新代碼合入到其他的feature分支中,以保證feature分支中的代碼最全,可以避免后續(xù)分支版本發(fā)布時的代碼遺漏現(xiàn)象.

圖1 多分支并行開發(fā)場景

2 代碼分支管理模式

軟件開發(fā)過程中的代碼管理一般是基于代碼分支管理模式進行的,代碼分支管理模式可以規(guī)范代碼分支的管理過程,在一定程度上減少分支管理和維護的成本,有利于保證代碼分支管理的有序進行.

不同的軟件開發(fā)場景所采用的代碼分支管理模式不盡相同,本文就以下幾種常用的代碼分支管理模式進行了調(diào)研和分析,并闡述了各個模式的優(yōu)缺點和適用的開發(fā)場景.

2.1 主干開發(fā),主干發(fā)布:M-M

主干開發(fā)、主干發(fā)布模式只有一條主干分支,所有的代碼提交和Bug修復都在主干分支上進行,提交的內(nèi)容可以從主干分支上直接發(fā)布到生產(chǎn)環(huán)境,如圖2所示.

圖2 主干開發(fā)、主干發(fā)布模式

主干提交、主干發(fā)布的模式只有一個分支,在實際開發(fā)實踐中存在如下幾點優(yōu)勢:1）迭代極快,隨時可發(fā)布; 2）沒有分支合并的麻煩,不用擔心分支合并出錯.同時該模式的缺點也比較明顯:1）版本迭代過程中開發(fā)人員的協(xié)同難度大; 2）版本發(fā)布頻率取決于主干分支的代碼質(zhì)量和穩(wěn)定性; 3）頻繁的代碼提交使得主干分支的壓力較大,需要具備較為完備的代碼提交標準.

該模式對于分支的維護較為簡潔,可以減少多分支管理的成本,避免分支間代碼漏合的現(xiàn)象,但對于開發(fā)人員的能力要求較高,開發(fā)人員本身要具備保證分支版本一致性的能力和意識.

2.2 主干開發(fā),分支發(fā)布:M-B

主干開發(fā)、分支發(fā)布模式要求項目團隊都在一個主干上進行版本開發(fā),只有在需要發(fā)布時拉取新的分支,并在新分支上進行缺陷的修復,如圖3所示.

圖3 主干開發(fā)、分支發(fā)布模式

主干開發(fā),分支發(fā)布模式是以發(fā)布為目的創(chuàng)建短期分支,新創(chuàng)建的分支僅僅用來版本發(fā)布,生命周期比較短,發(fā)布結束之后都要回歸主干分支.其優(yōu)勢主要有:1）只有一條主干分支,保證了代碼的唯一性; 2）主干分支永久存在,開發(fā)過程比較平穩(wěn); 3）版本發(fā)布過程以版本號來規(guī)范分支創(chuàng)建,便于統(tǒng)計維護.同時該模式也存在如下缺點:1）對主干分支要求很高,主干分支不穩(wěn)定容易導致發(fā)布分支難產(chǎn); 2）主干分支質(zhì)量決定版本發(fā)布頻率; 3）頻繁的代碼提交容易導致版本發(fā)布的節(jié)點不易把控.

M-B模式可以看作是M-M模式的延伸,可以保證主干開發(fā)的延續(xù)性和版本的正常發(fā)布,適用于頻發(fā)發(fā)布為主的代碼開發(fā)模式.

2.3 分支開發(fā),主干發(fā)布:B-M

分支開發(fā),主干發(fā)布模式允許系統(tǒng)工程師根據(jù)系統(tǒng)功能創(chuàng)建分支,并在功能開發(fā)完成后合并到主分支,最后將特性分支刪除,如圖4所示.

圖4 分支開發(fā)、主干發(fā)布模式

分支開發(fā),主干發(fā)布模式的優(yōu)勢主要有:1）特性分支相互獨立,開發(fā)過程互不干擾; 2）分支和功能特性相對應,版本功能迭代方便,便于維護和追溯.其缺點主要有:1）分支按照功能特性創(chuàng)建,一個特性只關聯(lián)一個分支,考驗開發(fā)人員的特性拆分能力; 2）分支命名規(guī)范嚴格,否則不利于分支的統(tǒng)一管理.

B-M管理模式是基于軟件的功能特性,以快速交付為目的,適用于版本迭代快速的敏捷開發(fā)場景.

2.4 分支開發(fā),分支發(fā)布:B-B

分支開發(fā),分支發(fā)布模式中開發(fā)人員在特性分支上進行功能開發(fā),并從中發(fā)布版本,然后在發(fā)布后將代碼合并回主線分支,如圖5所示.

圖5 分支開發(fā)、分支發(fā)布模式

分支開發(fā)、分支發(fā)布模式的優(yōu)勢包括:1）主干分支長期穩(wěn)定存在,代碼維護較為統(tǒng)一; 2）特定分支單獨維護,不同分支的版本發(fā)布相對獨立.其缺點為:1）特性分支過多,不同分支的版本維護比較混亂,容易出現(xiàn)分支漏合的現(xiàn)象; 2）各個分支單獨維護,很難做到分支的統(tǒng)一管理.

B-B模式中主干分支用于代碼同步,多條特性分支并存,不同分支的代碼迭代相對獨立,適用于多項目、多版本的并行開發(fā)場景.

2.5 分支管理模式選擇

每種分支管理模式都有其特點和應用場景,就通用特點而言,M-M模式適用于需求功能較為簡單且版本發(fā)布有先后順序開發(fā)場景; M-B模式適用于單一功能版本的串行開發(fā)場景; B-M模式適用于功能緊湊、版本迭代快速的敏捷開發(fā)場景; B-B模式適用于功能相對獨立的多版本的并行開發(fā)場景.

相對于其他3種分支管理模式而言,B-B模式中分支單獨維護,相互間的影響較小,分支的生命周期維護清晰明確,對于版本并行開發(fā)和發(fā)布以及功能的追溯比較容易實現(xiàn),可以更好的支持多項目、多版本的并行開發(fā)[8],所以本文主要基于B-B模式對多分支代碼漏合問題進行了解決途徑的研究.

3 多分支代碼漏合的解決途徑

本文結合了企業(yè)工作中的代碼管理經(jīng)驗,基于分支開發(fā)、分支發(fā)布管理模式對分支代碼漏合問題進行了解決途徑研究,主要包括分支操作權限規(guī)范、分支管理規(guī)范和多分支代碼合并規(guī)范3個方面的內(nèi)容.

B-B模式中分支管理過程如圖6所示,所有分支的創(chuàng)建都以master分支為來源,不同分支單獨開發(fā)維護,當master分支有新版本代碼合入時需要同步將maser分支最新代碼merge到其他特性分支中,以保證特性分支的代碼是最新的,可以避免后續(xù)的版本發(fā)布過程出現(xiàn)代碼遺漏現(xiàn)象; 任意特性分支在版本發(fā)布之后將當前分支代碼合入到master分支中并將當前分支刪除,保證master分支始終包含所有的功能代碼;master分支代碼更新之后同步將當前最新代碼merge到其他的特性分支中,并繼續(xù)開展后續(xù)的版本開發(fā)工作.

圖6 分支開發(fā)、主干發(fā)布管理模式

3.1 規(guī)范分支操作權限

對于分支操作的權限分配應該由配置管理團隊統(tǒng)一管理,不同級別的開發(fā)人員具有不同的分支操作權限,普通開發(fā)者只有分支代碼提交和代碼評審權限,系統(tǒng)工程師負責分支的具體維護,包括分支的創(chuàng)建、刪除、合并等操作[12].

分支操作權限的分配可以規(guī)范開發(fā)人員的代碼操作過程,權限的合理分配可以減少分支合并過程中的問題,保證分支管理的有序進行.

3.2 規(guī)范分支管理過程

分支管理規(guī)范的制定可以標準化分支管理過程,降低分支維護的難度,主要包括分支命名、分支創(chuàng)建來源和分支生命周期維護等幾個方面.

1）分支命名.分支命名采用版本化處理,與代碼版本進行邏輯綁定,確保分支與代碼功能的可追溯性.分支的命名可以采用“分支類型_版本號”的形式,例如版本1.0.0的開發(fā)分支可命名為:dev_1.0.0,既可以實現(xiàn)分支和版本的對應關系,又使得分支維護更加清晰.

2）分支創(chuàng)建來源.根據(jù)B-B分支管理模式,所有的分支的創(chuàng)建都來源于master分支,并且需要系統(tǒng)工程師根據(jù)版本功能進行分支整體規(guī)劃,以保證分支代碼來源的一致性和規(guī)范性,避免后續(xù)分支代碼合入的過程中出現(xiàn)混亂情況[13].以master分支創(chuàng)建特性分支dev_1.0.0為例,具體實現(xiàn)過程如下:

//將project項目clone到本地

git clone project

//切換到項目的master分支

git checkout master

//創(chuàng)建本地dev_1.0.0分支

git branch dev_1.0.0

//將本地分支推送到遠程倉庫中

git push-u origin dev_1.0.0

3）分支生命周期維護.代碼開發(fā)之前系統(tǒng)工程師提前規(guī)劃代碼版本并創(chuàng)建特性分支,將代碼提交分支通知到開發(fā)人員,避免代碼提交時分支選擇錯誤; 版本發(fā)布時系統(tǒng)工程師進行分支合并及tag版本發(fā)布; 代碼發(fā)布上線之后,系統(tǒng)工程師將對應的特性分支刪除,避免歷史遺留分支影響代碼提交過程.

3.3 規(guī)范多分支代碼合并過程

代碼分支間漏合問題主要是分支合并時操作不規(guī)范導致分支代碼遺漏,在B-B模式中主要的漏合場景是master分支已經(jīng)合入了新的功能代碼,而未將master分支最新代碼merge到其他特性分支中,導致后續(xù)特性分支在進行版本發(fā)布時代碼不全,出現(xiàn)分支代碼漏合現(xiàn)象,主要的解決措施有如下幾個.

3.3.1 增加分支漏合檢測機制

在B-B模式中,由于所有的特性分支都來源于master分支,所以針對代碼分支間漏合問題,增加代碼一致性檢測機制,在分支代碼開發(fā)過程中通過命令git merge-base判斷當前分支與master分支的最新代碼是否同步.

1）分支同步檢測機制

開發(fā)人員進行提交代碼時,觸發(fā)分支代碼同步檢測算法,檢測當前分支的來源commitid是否和master分支最新的commitid保持同步,如果不同步則代表master分支的代碼優(yōu)先于當前開發(fā)分支,即master分支合入了新的代碼,需要將master分支的代碼merge到當前分支之后再進行后續(xù)的開發(fā),否則版本發(fā)布時容易出現(xiàn)代碼漏合現(xiàn)象.

2）分支同步檢測算法

以master分支和dev_1.0.0分支為例,分支同步檢測算法的執(zhí)行過程如下所示.

分支同步檢測過程分為3個步驟:

（1）執(zhí)行命令git rev-parse HEAD分別獲取dev_1.0.0分支和master分支最新的commitid.

（2）利用git merge-base命令獲取分支同步檢測結果.例如:dev_1.0.0分支最新的commtid是 f5c67f88fc,master分支最新的commtid是a1e2dee286,執(zhí)行命令git merge-base f5c67f88fc a1e2dee286查看返回結果.

（3）判斷分支代碼是否同步,如果git merge-base命令返回的是master的commitid:a1e2dee286,則表示當前分支已經(jīng)同步了master分支的最新代碼,否則代表分之間代碼尚未同步.

3.3.2 規(guī)范多分支并行開發(fā)流程

代碼開發(fā)過程中由于版本迭代頻繁,開發(fā)人員通常需要在多個分支上進行功能開發(fā),且每次代碼提交的Patch在review階段需要一定的周期,根據(jù)實際的開發(fā)經(jīng)驗,多分支開發(fā)過程可以按照如圖7所示的流程進行,以避免分支代碼提交過程混亂.

圖7 多分支開發(fā)流程圖

1）master分支只用來同步分支代碼,開發(fā)過程中不進行任何代碼提交操作.

2）版本功能的開發(fā)在特性分支上完成,分支A進行A功能的開發(fā),分支B進行B功能的開發(fā).

3）分支A進行代碼review時暫停A功能的開發(fā),然后同步在B分支上進行功能B的開發(fā); A分支代碼review結束之后,暫存B分支的開發(fā)任務,結合分支A的review結果進行代碼修改及后續(xù)的代碼開發(fā);同樣的在B分支進行代碼review時,暫停B功能的開發(fā)并同步進行A分支的代碼開發(fā)工作,以此不斷交替進行.

4）當分支A代碼合入到master分支后即可刪掉,同步更新master分支最新代碼到B分支上.

5）以此循環(huán)往復不斷重復以上步驟.

4 解決途徑結果驗證

多分支代碼漏合問題的解決措施已經(jīng)基于分支開發(fā)、分支發(fā)布模式應用到了實踐中,本文主要就分支操作權限和多分支漏合檢測機制兩個方面進行了驗證結果的相關描述.

4.1 分支操作權限驗證

分支權限管理依托Gerrit開源工具的支持,所有代碼及分支的操作權限都通過Gerrit權限機制實現(xiàn).如圖8所示的部分權限規(guī)劃內(nèi)容,通過對不同的人員進行分組,然后對組實現(xiàn)權限劃分.分支創(chuàng)建權限交由Project Owners群組; 代碼review權限按照操作權限等級分配給不同的開發(fā)者,從而達到權限控制的效果.

圖8 部分權限規(guī)劃內(nèi)容

以代碼review操作為例,普通的開發(fā)者只有提交代碼和代碼review+1的權限,代碼+2和分支合并等權限由更高級別的系統(tǒng)工程師完成,Gerrit中的實現(xiàn)效果如圖9所示.

圖9 代碼review權限劃分效果

4.2 多分支漏合檢測機制驗證

分支漏合檢測機制在每次代碼提交之后執(zhí)行,可以及早的發(fā)現(xiàn)問題,縮小問題的影響范圍.本文的分支漏合檢測機制通過Jenkins調(diào)度執(zhí)行,Jenkins的CI流程通過監(jiān)聽Git倉庫的代碼變更,然后從遠程倉庫中克隆代碼并執(zhí)行對應的檢測算法.Jenkins的具體執(zhí)行效果如圖10所示,分別獲取當前分支和master分支的commit_id,然后通過判斷git merge-base的檢測結果來驗證分支代碼是否同步.

圖10 Jenkins分支合并檢測

5 小結

本文針對常見的代碼分支管理模式進行了研究與分析,并基于分支開發(fā)、分支發(fā)布模型對多分支代碼漏合問題進行了解決途徑的探討和研究.本文探討的問題源于實踐開發(fā)經(jīng)驗,具有實際的解決意義,同時解決措施也進行了實踐的驗證,可以為代碼分支管理的研究提供一定的參考; 但相對于分支管理功能較為完善的大公司來說,尚缺乏統(tǒng)一直觀的管理平臺對分支進行跟蹤與維護,仍需要進行不斷的完善和改進.