SemVer 和微服务

Question

在微服务产品中应用 SemVer 是否有最佳实践/模式？每个微服务是否应该有 SemVer，整个产品是否应该有 SemVer？

示例 - 我有一个名为 的产品，SuperDatabase包含 3 个微服务SuperDatabaseCore，分别为SuperDatabaseReports、 和SuperDatabaseSearch。

初始发行： SuperDatabase 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 吗？或者它不应该有任何版本控制？

Answer 1

我知道这是一个迟到的回复，但我想我会分享它。

我们有许多微服务，每个微服务都有自己的 semver。我们使用 docker 容器来部署，甚至发布到客户端（我们发布 docker 镜像）。docker 有一个清单来指定包含的微服务的版本...这是一项人工工作，因为我们需要选择兼容的版本。我们的开发人员计划使用kubernetes，我认为它具有良好的依赖管理功能。

产品的版本（营销版本）完全不同。开发并不关心营销版本......他们根据总体主要/次要变化来提高版本。这实际上是我们发布的docker镜像的版本。

回到微服务，我们正在使用自动版本控制......因此开发人员必须通过指定其更改类型并基于构建过程提升版本（无论是次要版本，主要或补丁）。一旦更改合并到主分支中，该分支就会自动标记该版本。所以基本上我们是持续发布的。

在共享库方面，我们也在遵循semver。我们正在利用 Maven 范围版本来获取最新的兼容版本，如果有主要版本，则需要开发人员参与升级相关应用程序。

我还找到了这两篇文章：

使用核心插入微服务并 拥有多个并发实例

===更新

这是我的答案的更新。由于我们的开发过程中发生了很多更改，因此开发人员很难提供更改的类型（向后兼容的错误修复、BC 增强或非向后兼容的更改）。想象一下，每个存储库（微服务）每天最多进行 10 次合并，我们125.5455.0最终可能会得到一个类似的版本。所以我们决定以这种方式放弃微服务的版本控制，而将其用作git commit id版本。它是独一无二的，它是自动的。我知道这看起来有点奇怪，但我无法告诉你这种方法在 CI/CD 自动化和发布过程中对我们有多大帮助。

我们创建一个如下所示的版本清单：

microservice-one:
  imageTag: "49e6f0f164324a314a475f483fcd9bd98e0e08ab"
microservice-two:
 imageTag: "57e272c44eb9dd6302617a3b5fe0baf82fa61617"
microservice-three:
 imageTag: "004dea68c4d4121d77cc4742f6b5702d7307d510"

但是我们交付给客户端的版本是这样的v1.2.0，这个版本链接到上面的版本清单，这有助于我们找到我们交付的实际提交。我们用这个提交 ID 标记所有 docker 镜像。