处理共享库版本控制、部署和使用的最佳方式
Posted
技术标签:
【中文标题】处理共享库版本控制、部署和使用的最佳方式【英文标题】:Best way to handle shared libraries versioning, deployment and usage 【发布时间】:2021-10-08 23:36:30 【问题描述】:我想分享一个我需要解决的问题,但我想不出最好的解决方法。
目前,对于我们的微服务项目(Spring),我们开发了一些内部共享库。这些库使用 Bitbucket 进行版本控制,我们有两种方式来处理部署和使用:
Git 子模块:对于这种情况,我们将共享库作为 git 子模块嵌入到微服务项目中。这种方法的主要问题是,开发人员混合引用并提交指向子模块错误分支的微服务的频率比我预期的要高。
正则依赖:我们将共享库的开发作为一个单独的项目进行,然后用管道编译并部署到artifactory。然后我们像往常一样添加 maven 依赖项。这种方法的主要缺点是库版本控制(maven 版本控制)更难管理,更难追溯用于任何微服务部署的引用。
所以,我很想听听您对这个案例的接洽和建议,您在项目中做了什么?
问候!
【问题讨论】:
关于2的部分。我不明白。如果您制作共享库的新版本,则制作版本(Git 等中的标记)并使用常规版本(如 1.2.3),然后更新微服务中的版本条目。在您的 pom 文件中正确跟踪(在 Git 中)这到底有什么困难?干净、简单、可追溯…… 【参考方案1】:您可以使用选项 2,同时您可以更喜欢使用多模块 maven 项目
https://spring.io/guides/gs/multi-module/
您可以将它保存在框架存储库中,假设它将是您的父存储库,并且您可以将其包含在您的子项目中,这样父级就可以继续维护版本,例如:spring-boot-starter-parent 的工作原理
https://www.springboottutorial.com/spring-boot-starter-parent
What does spring-boot-starter-parent exactly do in pom file?
【讨论】:
以上是关于处理共享库版本控制、部署和使用的最佳方式的主要内容,如果未能解决你的问题,请参考以下文章