建站
咨詢
售后
建站咨詢
新聞中心
大家好，我是飄渺。今天繼續(xù)更新DDD&微服務專欄，本篇主要與大家分享一下在多人團隊中如何更好地組織代碼和版本控制。
十年的東乃網(wǎng)站建設經(jīng)驗，針對設計、前端、開發(fā)、售后、文案、推廣等六對一服務，響應快，48小時及時工作處理。成都營銷網(wǎng)站建設的優(yōu)勢是能夠根據(jù)用戶設備顯示端的尺寸不同，自動調整東乃建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設計，從而大程度地提升瀏覽體驗。成都創(chuàng)新互聯(lián)從事“東乃網(wǎng)站設計”,“東乃網(wǎng)站推廣”以來，每個客戶項目都認真落實執(zhí)行。
代碼倉庫分離
首先，看看在多模塊多團隊的情境下，應該如何合理組織代碼。
以Dailymart項目為例，目前的代碼組織方式是將所有的業(yè)務模塊和基礎組件都存放在一個代碼倉庫中，這種做法在小團隊中較為常見，而且許多開源微服務腳手架也采用了這種組織結構。
然而，遺憾的是，這種代碼組織方式只適合小團隊的使用。在涉及多個團隊的大型項目中，每個團隊負責獨立的開發(fā)模塊時，這樣的代碼組織結構很可能會引發(fā)問題。
在多模塊多團隊的開發(fā)中，每個模塊的發(fā)布日期和上線范圍可能各不相同。為了解決這個問題，通常需要在開發(fā)過程中創(chuàng)建多個分支，這導致多個分支版本并存的情況。
這樣的情況下，每次上線都需要協(xié)調各團隊進行分支代碼合并。例如，從各自的特性Feature分支合并到一個統(tǒng)一的測試分支，然后從測試分支構建部署鏡像進行發(fā)布。然而，合并過程中一旦出現(xiàn)代碼沖突，就需要找相關人員進行代碼合并，這不僅耗時耗力，而且容易出錯。（我曾參與過一個多團隊項目開發(fā)，每次上線都是雞飛狗跳）
因此，在多團隊開發(fā)時，我們建議按照業(yè)務模塊進行代碼拆分，將每個業(yè)務模塊的代碼存放在獨立的代碼倉庫中。
這樣，盡管各自團隊可能仍然存在多分支開發(fā)的情況，但不再需要進行統(tǒng)一的合并，從而極大地提高了開發(fā)部署的效率。
同時，需要將所有公共組件也放置于一個單獨的代碼倉庫中，業(yè)務模塊按需引入即可。
接下來以Dailymart為例，介紹一下代碼如何拆分：
1、DailyMart項目中包含了用戶、訂單、購物車、庫存、商品等多個模塊，這些模塊按照普通SpringBoot項目的形式組織代碼，并存放在不同的代碼倉庫中。
2、將基礎組件模塊dailymart-starter和dailymart-dependencies模塊共同放置到另外一個單獨的倉庫中，業(yè)務模塊根據(jù)需要引入各自需要的組件。
組件版本的統(tǒng)一管理
在大型項目中，需要統(tǒng)一規(guī)劃依賴組件的版本，在Maven項目中通常通過BOM（Bill Of Materials）來實現(xiàn)。
BOM全稱是Bill Of Materials，譯作材料清單。BOM本身并不是一種特殊的文件格式，而是一個普通的POM文件，只是在這個POM中，我們羅列的是一個工程的所有依賴和其對應的版本。該文件一般被其它工程使用，當其它工程引用BOM中羅列的jar包時，不用顯示指定具體的版本，會自動使用BOM對應的jar版本。
在Dailymart項目中，dailymart-dependencies就是一個BOM，在該文件中定義了項目所需組件的版本。其他模塊只需在pom文件的dependencyManagement中引入bom依賴，后面引入定義好的組件時就不再需要指定版本了。
com.jianzh5
dailymart-dependencies
${revision}
pom
import
com.google.guava
guava
公共組件升級
當項目中有多個公共組件時會出現(xiàn)這樣一個問題，每個公共組件定義的版本可能不一樣。比如dailymart-common-spring-boot-starter的版本是1.0.0，dailymart-cache-spring-boot-starter的版本是1.0.1，這樣就導致項目的依賴管理變得比較混亂。
推薦的解決辦法是使用 revision 占位符統(tǒng)一管理基礎組件版本。
1、在pom文件中定義屬性
2024.0.0-SNAPSHOT
2、定義組件時直接使用revision變量作為版本號
com.jianzh5
dailymart-boot
${revision}
dailymart-starter 3、在bom文件中通過revision占位符引入公共組件
com.jianzh5
dailymart-common-spring-boot-starter
${revision}
com.jianzh5
dailymart-ddd-spring-boot-starter
${revision}
這樣，若公共組件需要修改版本，只需修改 revision 變量的值，各組件版本就會統(tǒng)一變更，非常方便。
不過使用這種方式在公共組件模塊執(zhí)行 maven install 或 maven deploy 時會出現(xiàn)問題，推送到maven倉庫中的pom文件仍然使用 revision 變量，業(yè)務模塊無法直接引用。
此時我們需要借助Maven插件 flatten-maven-plugin，使其在 install 或 deploy 時自動將 revision 替換成具體的版本號。
org.codehaus.mojo
flatten-maven-plugin
${maven-flatten.version}
true
resolveCiFriendliesOnly
flatten
flatten
process-resources
flatten.clean
clean
clean
在pom文件添加此插件后，執(zhí)行 install 時會生成一個名為 .flattened-pom.xml 的文件，打開文件后可以看到 revision 變量已經(jīng)全部替換成了具體的版本號。
圖片
Maven版本的選擇
在將自定義組件推送到maven倉庫時，可以選擇兩種不同版本：Release版本和Snapshot版本。這兩者應該如何選擇呢？
兩者區(qū)別的區(qū)別如下：
- 如果是Snapshot版本，在mvn deploy時會自動發(fā)布到快照版本庫中。引入使用快照版本的模塊，在不更改版本號的情況下，直接編譯打包時，Maven會自動從倉庫下載最新的快照版本。
- 如果是Release版本，那么在mvn deploy時會自動發(fā)布到正式版本庫中。引入正式版本的模塊，在不更改版本號的情況下，編譯打包時，如果本地已經(jīng)存在該版本的模塊則不會主動去鏡像服務器上下載。
簡而言之：Release版本是正式版，有bug不能再繼續(xù)使用這個版本號，需要配合開發(fā)方修改版本號；Snapshot版本是快照版，有bug可以繼續(xù)使用同一版本號，可以自動升級。
如果是內部開發(fā)項目，推薦使用Snapshot版本，即定義組件時在版本號后面加上 -SNAPSHOP 標識符，這樣搭配上DevOps會非常方便；如果是需要對外發(fā)布的組件，還是需要使用Release版本發(fā)布。
小結
本文介紹了在多人團隊協(xié)作中更有效地組織代碼和進行版本控制的方法，希望對你有所幫助！
- 代碼倉庫優(yōu)化： 建議按業(yè)務模塊分離代碼至獨立倉庫，提高開發(fā)效率。
- 組件版本統(tǒng)一管理： 引入BOM，通過 revision 占位符簡化組件版本管理。
- 公共組件版本升級： 推薦使用 revision 占位符集中管理基礎組件版本，借助 flatten-maven-plugin 解決版本問題。
- Maven版本選擇： 內部項目使用Snapshot版本，外部發(fā)布使用Release版本，確保靈活性和穩(wěn)定性。
當前標題：多人多團隊應該如何實施微服務？版本如何管理？
分享網(wǎng)址：http://m.5511xx.com/article/dphcooe.html
