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

Question

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

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

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

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

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

Answer 1

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

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