Spring微服务内部共享库版本管理、部署及使用最优方案咨询

如果团队内部共享库迭代频率较低、微服务数量多，优先选择优化后的Maven依赖管控方案，整体改造成本最低、维护成本最小；如果共享库迭代频率极高，大部分微服务开发场景都需要同步调整共享库代码，可选择加固后的Git Submodule方案，调试效率更高。

• 强制所有内部共享库遵循语义化版本规则（主版本号.次版本号.修订号），生产环境部署禁止引用SNAPSHOT版本，仅允许使用RELEASE正式版本。
• 共享库的发布流水线自动处理版本号递增：每次代码合入主分支后自动递增修订号，无需开发者手动修改版本配置，从根源避免版本号冲突、错配问题。
• 解决依赖追溯问题：在所有微服务的编译打包流水线中新增步骤，将本次构建用到的全部依赖GAV坐标导出为dependencies.json文件，和微服务构建产物一同上传到制品库对应目录，同时和微服务的部署记录做绑定，需要追溯时直接查询对应部署版本的依赖清单即可。
• 可选优化：新增统一的公共父POM，所有微服务继承该父POM，共享库的版本统一在父POM的<dependencyManagement>节点中定义，微服务引入共享库时无需填写版本号，父POM更新后所有微服务下次构建自动生效，无需逐个修改微服务配置。

• 先在共享库的Bitbucket仓库中设置分支保护规则，仅允许微服务的子模块引用共享库的主分支、正式release分支的提交，禁止指向开发分支的子模块提交合入微服务的正式分支。
• 在微服务的代码提交pre-commit钩子、PR合入流水线中新增校验逻辑：自动检查子模块指向的commit是否属于允许的合规分支、是否为已合入的正式提交，不符合要求直接阻塞提交/合入，从流程上杜绝引用错配问题。
• 新增轻量化辅助脚本，开发者执行./sync-shared-lib.sh即可自动将本地子模块切换到最新的合规分支版本，无需手动操作git子模块命令，降低人为出错概率。

内容的提问来源于stack exchange，提问作者pablo lamberti