我还没有找到有关使用Azure DevOps（服务器）CI / CD进行语义版本控制的明确指南。
我的基本理解是，我将为我们的团队建立一条CI管道，以便我们从构建故障通知，测试执行，代码覆盖率，静态代码分析以及更多好处中受益。
CD管道将在CI管道上启动，并在完成后在不同环境中推出工件。
使用这种方法对我来说似乎没有意义。那些由于开发人员没有注意或团队想放弃而失败的构建又如何呢？这样的版本无法投入生产，但可能会用完版本号，从而导致我们的版本控制体系中存在空白。
您使用CI / CD管道对软件版本进行语义版本控制的经验或方法是什么？你会挑剔吗？您是否有用于构建发行版的单独构建管道？
答案 0 :(得分：2)
失败的构建不会被部署。对于成功部署但在较低环境中部署但未通过质量检查或集成测试的构建，您可以放置审批门，以便有人在发布到更高环境之前必须批准发布。
如果您构建应用程序的1.0.1版并将其部署到dev中，那并不好，这并不意味着1.0.1版不存在。它存在。它由特定的代码资产组成。太糟糕了，您的用户将永远看不到它，但这很好。如果用户看到版本1.0.1跳至1.0.94，为什么有关系？