SemVer 对于持续交付来说是多余的吗？

如何解决SemVer 对于持续交付来说是多余的吗？

我们正在开发持续交付的分布式系统。

正在计划发布，并使用非技术营销版本名称进行标记。每个版本都会聚合一组具有所需功能的更改组件，并通过集成测试管道进行验证。我们不会持续部署到生产环境，但我们会持续部署到测试环境以进行候选发布集成测试。

系统组件包括前端、后端、适配器模块和共享数据库。它们被打包为 docker 容器。我们使用 Docker 注册表作为工件存储库，并使用 docker compose 来集成每个组件的 latest 版本以进行集成测试。有关管道及其依赖项，请参阅以下 DAG 图。上游项目的变化基本上会触发每个下游项目的重建，直到到达叶节点。当叶节点 docker 镜像被推送到注册表时，会触发集成测试。触发器逻辑已编入注册表 webhook 中。

显然，组件需要一些技术版本来将生产版本与组件的特定构建相关联，以进行跟踪和复制。目前，每个主版本都标有语义版本。但是在这种情况下使用 SemVer 和 git 标记是多余的吗？我们可以只使用 git hashes 并构建数字吗？在这种情况下，我没有看到使用语义版本控制的任何额外价值。自动变更日志是一项要求。

此外，通过集成测试管道在以 latest 标记开头的 docker 容器中包含实际版本号的最佳方法是什么？理想情况下，从集成管道结果中，我希望看到用于成功测试运行的实际组件版本。

我也想知道这个解决方案是否包含任何反模式或次优设计。

解决方法

SemVer 对于持续交付来说是多余的吗？

简短的回答是，可能，但可能不是，事实并非如此。 IMO，你问的问题不对。

当问题是：

内部发布和消费是否需要 SemVer？

答案是否定的。您描述的场景可以使用内部版本号和 Git 提交 ID 来实现。您真正需要 SemVer 的唯一时间是向消费者传达风险。在您的场景中，您既是发布者又是消费者，您的消费者的唯一目的是验证或确定候选版本的质量。

你可能想阅读我的一些其他咆哮，在 repo 中维护包或其他输出版本信息：

https://stackoverflow.com/a/66910767/3150445 How does CI affect semantic versioning?

在某些时候，您可能会确定您有一个值得发布的构建产品。如果您的消费者可以选择采用该版本（拉模式），那么您可能应该使用 SemVer 来对最终输出进行版本控制。如果他们别无选择，例如当您发布 Web 应用程序及其附带的客户端代码时，那么您可能可以在没有 SemVer 的情况下继续工作。您的开发人员和管理员需要知道的是，这些位的出处，以及它们的哪个版本或范围应该仍在生产中。您基本上处于推送模式。