关于使用 CI / CD 管道的语义版本控制发布的一般问题

Posted 2023-03-07

【中文标题】关于使用 CI / CD 管道的语义版本控制发布的一般问题

【英文标题】：General question on semantic versioning releases using CI / CD pipeline

【发布时间】：2019-05-08 16:05:45

【问题描述】：

我还没有找到关于使用 Azure DevOps（服务器）CI/CD 对软件版本进行语义版本控制的明确指南。

我的基本理解是，我将为我们的团队建立一个 CI 管道，以便我们获得构建失败通知、测试执行、代码覆盖、静态代码分析甚至更多好处的好处。

CD 管道接续 CI 管道，完成后在不同环境中推出工件。

使用这种方法对我来说似乎没有意义。由于开发人员没有注意或团队想要丢弃而失败的构建怎么办？此类构建不会进入生产环境，但可能会用完版本号，从而导致我们的版本控制方案出现空白。

您对使用 CI/CD 管道对软件版本进行语义版本控制的经验或方法是什么？你会挑选建筑吗？您是否有用于构建版本的单独构建管道？

【参考方案1】：

不会部署失败的构建。对于在部署到较低环境时成功但未通过 QA 或集成测试的构建，您可以设置审批门，以便在发布到较高环境之前必须有人批准。

如果您构建应用程序的 1.0.1 版本并将其部署到 dev 并且效果不佳，这并不意味着 1.0.1 版本不存在。它存在。它由特定的代码资产组成。这很糟糕，您的用户永远不会看到它，但那很好。如果用户看到版本 1.0.1 跳转到 1.0.94，这有什么关系？

【讨论】：

所以我从您的回答中得出的主要结论是：失败的构建无关紧要，应该跳过低质量的版本，转而使用更强大的版本。版本差距并不重要，只要它在补丁级别。主要和次要版本应该仍然有些连续。也许你可以确认后者？

@RenéSchindhelm，版本中的差距是经常和预期的，包括主要和次要序列，而不仅仅是补丁。间隙数是 MajorGaps