1. 程式人生 > >微服務架構下程式碼管理規範

微服務架構下程式碼管理規範

  當下對於程式碼的管理,主要採用GitLab或GitHub,然而使用git進行程式碼管理過程中,一般有四種開發模式,分別為主幹開發主幹釋出,主幹開發分支釋出,分支開發主幹釋出,分支開發分支釋出。四種開發模式各有特色,下面將從針對四種開發模式進行一一說明。

  但是針對微服務體系下,程式碼的管理,一般建議採用分支開發主幹釋出。

1. 程式碼管理模式

1.1.  主幹開發+主幹釋出模式

  

   模式特點:所有的操作都在主幹上進行操作,隨著時間的演進,程式碼只有一個版本,任何修改,均體現在主幹上面,開發過程比較簡單。

  操作許可權:該種模式對於開發人員與專案經理等在程式碼提交方面,許可權相同;

  適用場景:該種模式適用於團隊規模較小,業務模型明確,且人員技能較高的開發團隊。

1.2.  主幹開發+分支釋出模式

  

   模式特點:所有的操作都在主幹上進行操作,隨著時間的演進,程式碼具有多個版本,執行多個版本可並行提供服務。

  操作許可權:該種模式對於開發人員與專案經理等在程式碼提交方面,許可權相同;

  適用場景:該種模式適用於多版本並存,但只維護一個版本的產品,其他版本不進行維護的專案,該種場景較少。

1.3.  分支開發+主幹釋出模式 

  

   模式特點:所有的程式碼提交都在分支上操作,隨著時間的演進,需要構建Release版本時,需要將程式碼提交到主幹上面,平常開發都是在分支上進行,好處可保證主幹程式碼始終可用。

  操作許可權:該種方式開發人員只具有開發分支許可權,無master許可權,程式碼的merge只能由專案經理或有權人完成;

  適用場景:該種模式適用於多功能並行開發,按照業務特性或模組進行在分支進行開發,然後在進行合併後進行Release構建釋出,業務場景較複雜,且人員素質層次不齊,需要程式碼review。

1.4.  分支開發+分支釋出模式 

  

   模式特點:所有的程式碼提交都在分支上操作,隨著時間的演進,需要構建Release版本時,也是直接在分支上進行構建,各分支獨立演進,與主分支關係不大,是主幹開發主幹釋出的一個組合使用。

  操作許可權:該種方式開發人員與專案經理一樣,只具有分支上的操作許可權,不具有master許可權。

  適用場景:該模式適用於需求群/專案群的方式進行開發,大家公用同一個程式碼庫,然後共享部門基礎程式碼,然後各分支獨立進行演進。

2. 程式碼管理規範

  無規矩不成方圓,微服務架構下,程式碼的管理一般採用git進行管控,因此,在使用git進行版本控制時,應遵循一些原則及規範。

2.1.  程式碼管理原則

  程式碼管理的原則,用於確保程式碼管理過程中不出現原則性錯誤,出現原則性錯誤,則會出現許多無用的操作,基本原則如下:

  • 模式確實後,必須嚴格遵循執行;
  • 提交程式碼時,禁止程式碼強制提交;
  • 程式碼提交時,必須進行註釋說明;
  • 程式碼提交時,必須按照規範執行;
  • 出現衝突時,必須進行確認處理;

2.2.  程式碼管理規範

  由於微服務一般建議採用分支開發主幹釋出,因此,本規範主要針對分支開發主幹釋出模式,具體規範如下:

  • 原則上程式碼的開發提交,必須通過建立分支進行開發,特殊情況除外(bug),review同事有責任進行檢查其他同事是否遵循分支規範;
  • 程式碼提交前,必須先進行更新程式碼(git pull),對於有衝突的檔案,必須要進行對比,確認素有修改都是自己修改的,然後在進行提交,防止程式碼回溯(即別人的程式碼被覆蓋);
  • review同事遇到程式碼刪除情況,必須與開發確認,是否為開發同事自己刪除,如果不是,很可能就是程式碼回溯;
  • 在程式碼開發階段,程式碼的提交儘量獨立化,也就是功能模組儘量細分,每個開發負責一個模組,儘量不要修改其他成員模組程式碼;
  • 多人協作時,需要建立一個遠端分支,然後一起在遠端分支裡協作開發,防止程式碼回溯。禁止各自開發,然後線下發送檔案合併;
  • 程式碼提交前,必須進行git pull,且進行git diff進行比對程式碼,確保提交程式碼為自己修改內容,防止出現程式碼回溯;
  • 程式碼出現衝突時,必須 要與衝突程式碼提交者進行確認衝突內容,雙方確認無誤方可處理;
  • 主分支(master)為生產環境分支,除特殊情況(修復bug),禁止在master分支上進行開發;
  • 程式碼提交時,必須描述清楚做了什麼,提交動作有add、update、remove,提交格式為[動作]+[操作的模組資訊,儘量詳細到具體的類名方法名]+[操作描述資訊],例如:git commit –m ‘update aa.java findByName 將精確查詢修改為模糊查詢’,每次提交儘量一個動作,多個動作請多次提交;
  • 在git中,預設空目錄不會提交,如果某個空目錄想提交到版本庫,需要在該目錄下新建一個deleteme.txt的空白檔案;
  • 開發分支(developer)為開發分支,一般作為主要的程式碼提交分支;
  • 修復分支為修復bug分支,命名格式為bugfix-{date},修復分支用於主要分支的bug修復工作;
  • 功能分支為新增功能分支,命名格式為feature-{message},可合併到developer分支;
  • 其他分支,為特殊情況建立的分支,命名應帶有分支相關資訊;