Azure DevOps是否可通过发布流水线自动完成关联PR合并

现有流程与问题 #

当前部署到Azure App Service的Azure DevOps项目工作流如下：

• PR创建时自动触发Build构建
• 构建完成后触发CD流水线，将应用部署到staging暂存槽
• CD流水线第二阶段执行staging与prod生产环境槽交换，该步骤需人工审批
• 关联PR需手动完成合并

该流程的设计初衷是让所有提交变更的开发者，在真实环境的暂存槽完成验证后再将变更推送到生产。目前流程可正常运行，但变更收尾阶段需要审批人同时完成两项操作：审批流水线中的生产槽交换任务、手动合并关联PR，实际使用中频繁出现PR漏合并的情况，最终导致已部署生效的变更未合入代码主干。

核心诉求：

• 确认是否可以在PR构建触发的发布流水线中，将完成关联PR合并设置为发布阶段的内置步骤
• 不希望调整为PR合并完成后再触发部署的模式：该模式下代码先合入主干，若出现破坏性变更只能执行回滚操作，无法保证合入主干的代码就是当前部署生效的代码
• 已构思备选方案：
  1. PR创建时触发验证构建与发布流水线，将应用部署到dev开发槽
  2. PR完成合并后触发发布流水线，将对应PR的构建产物部署到生产环境
     该方案会小幅调整审批流程，但可以更好保障PR被正确合入。

解答 #

完全可以在PR触发的发布流水线中把关联PR合并设为内置步骤，不需要切换到「PR合并后再触发生产部署」的模式，具体实现方式和注意事项如下：

前置权限配置 #

先给流水线使用的服务账号配置足够的仓库操作权限：进入代码仓库的权限设置页，给项目构建服务账号授予Contribute（参与贡献）、Contribute to pull requests（处理拉取请求）权限。如果目标分支设置了强制审批、工作项关联等分支策略，可按需给服务账号配置对应策略的绕过权限，或者提前把服务账号加入PR默认审批人列表，保证流水线能正常调用PR合并接口。

流水线步骤配置 #

在生产环境槽交换执行成功的节点之后，新增PR合并步骤即可：

• 优先使用Azure DevOps官方提供的拉取请求合并任务，不需要自行编写脚本。PR触发构建时，系统会自动注入System.PullRequest.PullRequestId（PR编号）、System.PullRequest.TargetBranch（目标分支）、System.PullRequest.RepositoryId（仓库ID）这几个系统变量，直接把变量传入任务参数即可，无需手动维护PR和流水线的关联关系。
• 如果需要自定义合并规则，比如指定合并方式为压缩合并、合并后自动删除源分支、自动关联对应工作项，直接在任务配置页勾选对应选项即可，合并逻辑和手动合并PR的规则保持一致。
• 必须增加合并前置校验：执行合并操作前先检查PR是否处于可合并状态，如果存在代码冲突、PR审批未通过、源分支被删除等情况，直接终止步骤并抛出告警，通知对应开发人员处理，避免出现生产部署完成但代码无法合入主干的问题。

流程优化建议 #

• 可以把PR的代码变更详情、暂存槽验证地址直接配置到槽交换的审批页上，审批人在审批槽交换时就能直接看到所有需要确认的信息，不需要跨多个页面跳转，从操作流程上减少漏合并的可能。
• 你提到的备选方案不建议优先采用：该方案中dev槽的环境配置和生产环境很难做到完全一致，无法达到最初设计的「真实暂存环境验证后再上生产」的效果，还是会出现dev环境验证通过但生产出问题的风险，和核心诉求不符。
• 增加兜底检查逻辑：每次执行生产槽交换前，先校验当前构建对应的PR是否处于有效打开状态，如果PR已经被关闭或者合并，直接终止流水线，避免重复部署或者部署无效代码版本。

内容的提问来源于stack exchange，提问作者Chris Bardon