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

Posted 2023-03-07

【中文标题】SemVer 对于持续交付来说是多余的吗？

【英文标题】：Is SemVer redundant for continuous delivery?

【发布时间】：2021-06-29 21:07:39

【问题描述】：

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

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

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

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

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

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

【参考方案1】：

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

简短的回答是，也许，但可能不，不是。 IMO，您问的问题不正确。

当问题是：

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

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

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

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

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