如何在Azure Devops中为生产版本创建单独的构建工件

我在Azure Devops中有一个构建管道，并将其设置为在“开发”分支更新时触发。在我的发布管道中，我在登台和QA环境中使用相同的构建工件，使用管道变量在每个环境中设置配置

虽然时间不同，但它在生产版本中是如何工作的？我计划在手动触发器中发布，但是我使用什么工件呢？我只有一个构建依赖于开发分支。开发团队总是创建一个发布分支，这是否意味着我要为发布分支创建一个单独的构建？

---

我知道DevOps的口号是“一次构建，部署到多个环境”，实际上，当您有一个单独的分支用于生产版本时，如何做到这一点？

创建一个新的工件会带来一个风险，即引入意外更改，并且应用程序的未经测试的版本投入生产

微软的文档非常值得一读，主要的一点是让事情尽可能简单。因此，您甚至可以考虑从工作流程中删除生产分支。

我可以看到保留一个生产分支的一些优点，它提供了一个即时的可视化表示，从您的git客户端可以看到生产中的内容，因此很容易为修补程序选择一个分支点。如果您想保留您的生产分支，我建议您改变理念，而不是在计划部署到生产时手动合并到分支，而是在部署到生产后自动合并到生产分支，如果可能的话

如果使用，您可以通过生产部署阶段中的任务实现这一点，可以合并到生产分支，也可以标记主任务，例如：

- script: |
      git --version
      git -c http.extraheader="AUTHORIZATION: bearer $(system.accesstoken)" tag $(build.buildNumber)
      git -c http.extraheader="AUTHORIZATION: bearer $(system.accesstoken)" push origin $(build.buildNumber)
    displayName: Git Tag

---

如果您需要更改权限，可以执行一些更改。

如您所述，您不应该为不同的环境使用不同的工件。分支模型不适合CI/CD，而是尝试使用标记触发升级到其他环境。Simon Ness，production branch不仅仅是prod中已部署代码的可视化表示。您已经提到了修补程序，在主开发分支中根本无法进行修补程序，否则，您将在执行修补程序时部署最新提交。我们正在遵循git flow，它促进了这种分支哲学。不过，谢谢你提出的方法。