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

【问题标题】：How Do You Create A Separate Build Artifact for Production Release in Azure Devops如何在 Azure Devops 中为生产版本创建单独的构建工件
【发布时间】：2020-09-04 04:14:51
【问题描述】：

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

尽管时间不同，但它在生产版本中如何工作？我计划在手动触发中发布，但我使用什么神器？我只有一个依赖于开发分支的构建。开发团队总是创建一个发布分支，这是否意味着我为发布分支创建一个单独的构建？我知道 DevOps 的口号是“一次构建，部署到多个环境”，实际上，当您有一个单独的生产版本分支时，您如何做到这一点？

【问题讨论】：

正如您所指出的，您不应该为不同的环境使用不同的工件。分支模型不适合 CI/CD，而是尝试使用标签来触发对其他环境的提升。

标签： azure azure-devops

【解决方案1】：

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

Microsoft 关于branching strategy 的文档非常值得一读，重点是让事情尽可能简单。因此，您甚至可以考虑从工作流程中移除生产分支。

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

如果使用multi-stage yaml pipelines，您可以通过生产部署阶段的任务来实现这一点，或者合并到生产分支或标记主分支，例如：

- 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

如果您想要pipeline to be able to perform git commands，可以进行一些权限更改。

【讨论】：

Simon Ness，生产分支不仅仅是产品中部署代码的可视化表示。您提到了在主开发分支中根本无法进行修补程序的修补程序，否则您将在进行修补程序时部署最新的提交。我们正在遵循 git flow 来推广这种分支理念。不过，感谢您提出的方法。