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

王曉龍,董玉雪

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

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

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

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

1 多分支代碼漏合問題

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

1.1 分支操作權限混亂

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

1.2 分支管理缺乏規范

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

1.3 分支合并流程混亂

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

圖1 多分支并行開發場景

2 代碼分支管理模式

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

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

2.1 主干開發,主干發布:M-M

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

圖2 主干開發、主干發布模式

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

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

2.2 主干開發,分支發布:M-B

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

圖3 主干開發、分支發布模式

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

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

2.3 分支開發,主干發布:B-M

分支開發,主干發布模式允許系統工程師根據系統功能創建分支,并在功能開發完成后合并到主分支,最后將特性分支刪除,如圖4所示.

圖4 分支開發、主干發布模式

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

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

2.4 分支開發,分支發布:B-B

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

圖5 分支開發、分支發布模式

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

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

2.5 分支管理模式選擇

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

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

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

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

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

圖6 分支開發、主干發布管理模式

3.1 規范分支操作權限

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

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

3.2 規范分支管理過程

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

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

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

//將project項目clone到本地

git clone project

//切換到項目的master分支

git checkout master

//創建本地dev_1.0.0分支

git branch dev_1.0.0

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

git push-u origin dev_1.0.0

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

3.3 規范多分支代碼合并過程

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

3.3.1 增加分支漏合檢測機制

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

1）分支同步檢測機制

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

2）分支同步檢測算法

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

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

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

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

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

3.3.2 規范多分支并行開發流程

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

圖7 多分支開發流程圖

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

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

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

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

5）以此循環往復不斷重復以上步驟.

4 解決途徑結果驗證

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

4.1 分支操作權限驗證

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

圖8 部分權限規劃內容

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

圖9 代碼review權限劃分效果

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

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

圖10 Jenkins分支合并檢測

5 小結

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