如何配置Azure DevOps YAML流水线，实现合并后构建成功再触发部署

核心思路 #

通过区分构建流水线的触发来源（PR验证/分支合并推送），配合部署流水线的条件判断，实现仅在分支合并后自动触发部署，PR验证时不执行部署。

1. 调整构建流水线配置 #

确保构建流水线同时支持PR验证和分支推送触发，保留构建、测试、发布工件的完整流程：

trigger:
  branches:
    include:
      - master
      - sprint/*

pr:
  branches:
    include:
      - master
      - sprint/*

jobs:
- job: BuildTestPublish
  steps:
  # 构建步骤示例
  - script: dotnet build --configuration Release
    displayName: '执行构建'
  # 测试步骤示例
  - script: dotnet test --configuration Release --no-build
    displayName: '执行测试'
  # 发布工件
  - task: PublishBuildArtifacts@1
    displayName: '发布构建工件'
    inputs:
      PathtoPublish: '$(Build.ArtifactStagingDirectory)'
      ArtifactName: 'drop'
      publishLocation: 'Container'

2. 修正部署流水线配置 #

保留trigger:none避免分支直接触发部署，通过流水线资源关联构建流水线，并添加条件过滤PR触发的构建：

trigger: none

resources:
  pipelines:
  - pipeline: BuildPipeline  # 自定义流水线标识名
    source: '你的构建流水线名称'  # 替换为实际构建流水线的名称
    trigger:
      branches:
        include:
          - master
          - sprint/*

jobs:
- job: Deploy
  # 仅当构建流水线由分支推送/合并触发时，才执行部署
  condition: ne(variables['resources.pipeline.BuildPipeline.runReason'], 'PullRequest')
  steps:
  # 部署步骤示例
  - script: echo "部署到目标环境"
    displayName: '执行部署'
  # 添加实际部署任务（如Azure App Service部署、K8s部署等）

关键说明 #

• 触发来源过滤：resources.pipeline.BuildPipeline.runReason会继承构建流水线的运行原因：
  • PR验证触发的构建，该值为PullRequest，部署任务因条件不满足跳过；
  • 分支合并/推送触发的构建，该值为IndividualCI或BatchedCI，部署任务正常执行。
• 分支范围控制：流水线资源的trigger.branches确保只监听master和sprint/*分支的构建，避免其他分支的构建触发部署。
• 权限检查：确保部署流水线拥有读取构建流水线的权限（默认已配置，若出现问题可在流水线权限设置中确认）。

内容的提问来源于stack exchange，提问作者Paul Pearce