盧偉冰長文解析K60至尊版 對Redmi有著里程碑式的意義
在今天的Redmi后性能時代戰略發布會結束之后，Redmi總經理盧偉冰又帶來了一篇長文，詳解了為什么 Redmi 要開啟后性能時代？為什么選擇和 MediaTek、Pixelworks 深度合作？以及后性
大家好，我是飄渺。今天繼續更新DDD&微服務專欄，本篇主要與大家分享一下在多人團隊中如何更好地組織代碼和版本控制。
首先，看看在多模塊多團隊的情境下，應該如何合理組織代碼。
以Dailymart項目為例，目前的代碼組織方式是將所有的業務模塊和基礎組件都存放在一個代碼倉庫中，這種做法在小團隊中較為常見，而且許多開源微服務腳手架也采用了這種組織結構。
然而，遺憾的是，這種代碼組織方式只適合小團隊的使用。在涉及多個團隊的大型項目中，每個團隊負責獨立的開發模塊時，這樣的代碼組織結構很可能會引發問題。
在多模塊多團隊的開發中，每個模塊的發布日期和上線范圍可能各不相同。為了解決這個問題，通常需要在開發過程中創建多個分支，這導致多個分支版本并存的情況。
這樣的情況下，每次上線都需要協調各團隊進行分支代碼合并。例如，從各自的特性Feature分支合并到一個統一的測試分支，然后從測試分支構建部署鏡像進行發布。然而，合并過程中一旦出現代碼沖突，就需要找相關人員進行代碼合并，這不僅耗時耗力，而且容易出錯。（我曾參與過一個多團隊項目開發，每次上線都是雞飛狗跳）
因此，在多團隊開發時，我們建議按照業務模塊進行代碼拆分，將每個業務模塊的代碼存放在獨立的代碼倉庫中。
這樣，盡管各自團隊可能仍然存在多分支開發的情況，但不再需要進行統一的合并，從而極大地提高了開發部署的效率。
同時，需要將所有公共組件也放置于一個單獨的代碼倉庫中，業務模塊按需引入即可。
接下來以Dailymart為例，介紹一下代碼如何拆分：
1、DailyMart項目中包含了用戶、訂單、購物車、庫存、商品等多個模塊，這些模塊按照普通SpringBoot項目的形式組織代碼，并存放在不同的代碼倉庫中。
2、將基礎組件模塊dailymart-starter和dailymart-dependencies模塊共同放置到另外一個單獨的倉庫中，業務模塊根據需要引入各自需要的組件。
在大型項目中，需要統一規劃依賴組件的版本，在Maven項目中通常通過BOM（Bill Of Materials）來實現。
BOM全稱是Bill Of Materials，譯作材料清單。BOM本身并不是一種特殊的文件格式，而是一個普通的POM文件，只是在這個POM中，我們羅列的是一個工程的所有依賴和其對應的版本。該文件一般被其它工程使用，當其它工程引用BOM中羅列的jar包時，不用顯示指定具體的版本，會自動使用BOM對應的jar版本。
在Dailymart項目中，dailymart-dependencies就是一個BOM，在該文件中定義了項目所需組件的版本。其他模塊只需在pom文件的dependencyManagement中引入bom依賴，后面引入定義好的組件時就不再需要指定版本了。
<dependencyManagement> <dependencies> <dependency> <groupId>com.jianzh5</groupId> <artifactId>dailymart-dependencies</artifactId> <version>${revision}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement><dependencies> <dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> </dependency></dependencies>當項目中有多個公共組件時會出現這樣一個問題，每個公共組件定義的版本可能不一樣。比如dailymart-common-spring-boot-starter的版本是1.0.0，dailymart-cache-spring-boot-starter的版本是1.0.1，這樣就導致項目的依賴管理變得比較混亂。
推薦的解決辦法是使用 revision 占位符統一管理基礎組件版本。
1、在pom文件中定義屬性
<properties> <revision>2024.0.0-SNAPSHOT</revision></properties>2、定義組件時直接使用revision變量作為版本號
<parent> <groupId>com.jianzh5</groupId> <artifactId>dailymart-boot</artifactId> <version>${revision}</version> </parent> <artifactId>dailymart-starter</artifactId>3、在bom文件中通過revision占位符引入公共組件
<dependencyManagement> <dependencies> <!-- Internal dependencies Start--> <dependency> <groupId>com.jianzh5</groupId> <artifactId>dailymart-common-spring-boot-starter</artifactId> <version>${revision}</version> </dependency> <dependency> <groupId>com.jianzh5</groupId> <artifactId>dailymart-ddd-spring-boot-starter</artifactId> <version>${revision}</version> </dependency> </dependencies> </dependencyManagement>這樣，若公共組件需要修改版本，只需修改 revision 變量的值，各組件版本就會統一變更，非常方便。
不過使用這種方式在公共組件模塊執行 maven install 或 maven deploy 時會出現問題，推送到maven倉庫中的pom文件仍然使用 revision 變量，業務模塊無法直接引用。
此時我們需要借助Maven插件 flatten-maven-plugin，使其在 install 或 deploy 時自動將 revision 替換成具體的版本號。
<build> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>flatten-maven-plugin</artifactId> <version>${maven-flatten.version}</version> <configuration> <updatePomFile>true</updatePomFile> <flattenMode>resolveCiFriendliesOnly</flattenMode> </configuration> <executions> <execution> <id>flatten</id> <goals> <goal>flatten</goal> </goals> <phase>process-resources</phase> </execution> <execution> <id>flatten.clean</id> <goals> <goal>clean</goal> </goals> <phase>clean</phase> </execution> </executions> </plugin> </plugins> </build>在pom文件添加此插件后，執行 install 時會生成一個名為 .flattened-pom.xml 的文件，打開文件后可以看到 revision 變量已經全部替換成了具體的版本號。
圖片
在將自定義組件推送到maven倉庫時，可以選擇兩種不同版本：Release版本和Snapshot版本。這兩者應該如何選擇呢？
兩者區別的區別如下：
簡而言之：Release版本是正式版，有bug不能再繼續使用這個版本號，需要配合開發方修改版本號；Snapshot版本是快照版，有bug可以繼續使用同一版本號，可以自動升級。
如果是內部開發項目，推薦使用Snapshot版本，即定義組件時在版本號后面加上 -SNAPSHOP 標識符，這樣搭配上DevOps會非常方便；如果是需要對外發布的組件，還是需要使用Release版本發布。
本文介紹了在多人團隊協作中更有效地組織代碼和進行版本控制的方法，希望對你有所幫助！
本文鏈接：http://www.tebozhan.com/showinfo-26-54996-0.html多人多團隊應該如何實施微服務？版本如何管理？
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號