在微服务产品中应用 SemVer 是否有最佳实践/模式?每个微服务是否应该有 SemVer,整个产品是否应该有 SemVer?
示例 - 我有一个名为 SuperDatabase
的产品,其中包含 3 个名为 SuperDatabaseCore
、SuperDatabaseReports
和 SuperDatabaseSearch
的微服务。
初始版本:
super 数据库v1.0.0
SuperDatabaseCore v1.0.0
SuperDatabaseReports v1.0.0
SuperDatabaseSearch v1.0.0
报告的小更新:
SuperDatabaseReport v1.1.0
产品现在应该是SuperDatabase v1.1.0
吗?
如果以后有搜索补丁怎么办:
SuperDatabaseSearch v1.0.1
是否应该再次更改产品版本?产品版本是否应该完全独立于微服务?它到底应该使用 SemVer 吗?或者它不应该有任何版本控制?
最佳答案
我知道这是一个迟到的回复,但我想我会分享它。
我们有许多微服务,每个微服务都有自己的 semver。我们使用 docker 容器来部署,甚至发布到客户端(我们发布 docker 镜像)。 docker 有一个 list 来指定包含的微服务的版本...这是一项人工工作,因为我们需要选择兼容的版本。我们的开发人员计划使用kubernetes我认为它有很好的依赖管理。
产品的版本(营销版本)完全不同。开发并不关心营销版本......他们根据总体主要/次要变化来提高版本。这实际上是我们发布的docker镜像的版本。
回到微服务,我们正在使用自动版本控制...因此开发人员必须通过指定更改类型并基于构建过程提升版本(无论是它是次要的、主要的或补丁)。一旦更改合并到主分支中,该分支就会自动标记该版本。所以基本上我们是持续发布的。
在共享库方面,我们也在遵循 semver。我们正在利用 Maven 范围版本来获取最新的兼容版本,如果有主要版本,则需要开发人员参与升级相关应用程序。
我还找到了这两篇文章:
using a core to plug microsevices in和 having multiple concurrent instances
=== 更新
这是我的答案的更新。由于我们的开发过程中发生了很多更改,因此开发人员很难提供更改的类型(向后兼容的错误修复、BC 增强或非向后兼容的更改)。想象一下,每个存储库(微服务)每天最多进行 10 次合并,我们最终可能会得到像 125.5455.0
这样的版本。因此,我们决定放弃这种方式的微服务版本控制,并使用 git commit id 来作为版本。它是独一无二的,它是自动的。我知道这看起来有点奇怪,但我无法告诉你这种方法在 CI/CD 自动化和发布过程中对我们有多大帮助。
我们创建一个如下所示的版本 list :
microservice-one:
imageTag: "49e6f0f164324a314a475f483fcd9bd98e0e08ab"
microservice-two:
imageTag: "57e272c44eb9dd6302617a3b5fe0baf82fa61617"
microservice-three:
imageTag: "004dea68c4d4121d77cc4742f6b5702d7307d510"
但是我们交付给客户端的版本类似于 v1.2.0
并且该版本链接到上述版本 list ,这有助于我们找到我们交付的实际提交。我们用这个提交 ID 标记所有 docker 镜像。
关于architecture - SemVer 和微服务,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/43350278/