问SemVer和Microservices

EN

我知道这是一个迟来的反应，但我想我会分享它。

我们有许多微型服务，每个服务都有自己的服务。我们使用docker容器进行部署，甚至发布到客户端(我们发布了对接映像)。有一个清单供码头者指定包含什么微服务的版本.这是一个男人的工作，因为我们需要选择兼容的版本。我们的开发人员正计划使用库伯奈特斯，我认为它具有良好的依赖性管理。

产品的版本(市场版)完全不同。开发不关心营销版本..。它们根据总体上的重大/次要变化而增加它们的版本。这实际上是我们发布的对接者图像的版本。

回到微服务器，我们使用的是自动版本控制.因此，开发人员必须通过指定更改的类型，并在此基础上将版本(无论是次要的、主要的还是修补程序)添加到更改日志文件中。一旦将更改合并到主分支中，分支就会自动使用该版本进行标记。所以基本上我们不断地释放。

在共享库方面，我们也在跟踪semver。我们正在利用maven范围版本获取最新的兼容的版本，如果有主要版本，则需要开发人员来升级依赖的应用程序。

我还发现了以下两篇文章：

使用核心来插入微缝和具有多个并发实例

=== 更新

这是我回答的最新情况。由于我们的开发中有许多更改，所以开发人员很难提供更改的类型(向后兼容的bug修复、BC增强或非向后兼容的更改)。想象一下，每个存储库(microservice)每天最多合并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标记所有对接者的图像。

您应该独立地对您的服务进行版本化，微服务体系结构的好处之一是您可以在不需要任何停机时间的情况下更新和部署系统的小部分(理论上)。如果在对组件C进行更新时对组件A和B进行版本化，那么当只有一个组件更改时，您将不得不部署所有组件。