版本如何治理 多人多团队应该如何实施微服务

大家好，我是飘渺。当天继续更新DDD&微服务专栏，本篇关键与大家分享一下在多人团队中如何更好地组织代码和版本控制。

代码仓库分别

首先，看看在多模块多团队的情境下，应该如何正当组织代码。

以Dailymart名目为例，目前的代码组织方式是将一切的业务模块和基础组件都寄存在一个代码仓库中，这种做法在小团队中较为经常出现，而且许多开源微服务脚手架也驳回了这种组织结构。

但是，遗憾的是，这种代码组织方式只适宜小团队的经常使用。在触及多个团队的大型名目中，每个团队担任独立的开发模块时，这样的代码组织结构很或许会引发疑问。

这样的状况下，每次上线都须要协调各团队启动分支代码兼并。例如，从各自的个性Feature分支兼并到一个一致的测试分支，而后从测试分支构建部署镜像启动颁布。但是，兼并环节中一旦出现代码抵触，就须要找关系人员启动代码兼并，这不只耗时耗力，而且容易出错。（我曾介入过一个多团队名目开发，每次上线都是鸡飞狗跳）

因此，在多团队开发时，咱们倡导依照业务模块启动代码拆分，将每个业务模块的代码寄存在独立的代码仓库中。

这样，虽然各自团队或许依然存在多分支开发的状况，但不再须要启动一致的兼并，从而极大地提高了开发部署的效率。

同时，须要将一切公共组件也搁置于一个独自的代码仓库中，业务模块按需引入即可。

接上去以Dailymart为例，引见一下代码如何拆分：

1、DailyMart名目中蕴含了用户、订单、购物车、库存、商品等多个模块，这些模块依照普通SpringBoot名目标方式组织代码，并寄存在不同的代码仓库中。

2、将基础组件模块dailymart-starter和dailymart-dependencies模块独特搁置到另外一个独自的仓库中，业务模块依据须要引入各自须要的组件。

组件版本的一致治理

在大型名目中，须要一致布局依赖组件的版本，在Maven名目中通常经过BOM（Bill Of Materials）来成功。

在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><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版本的选用

在将自定义组件推送到maven仓库时，可以选用两种不同版本：Release版本和Snapshot版本。这两者应该如何选用呢？

两者区别的区别如下：

简而言之：Release版本是正式版，有bug不能再继续经常使用这个版本号，须要配合开发方修正版本号；Snapshot版本是快照版，有bug可以继续经常使用同一版本号，可以智能更新。

假设是外部开发名目，介绍经常使用Snapshot版本，即定义组件时在版本号前面加上 -SNAPSHOP 标识符，这样搭配上DevOps会十分繁难；假设是须要对外颁布的组件，还是须要经常使用Release版本颁布。

小结

本文引见了在多人团队单干中更有效地组织代码和启动版本控制的方法，宿愿对你有所协助！