能否用纯YAML创建Azure DevOps发布管道？需合并构建发布吗？

完全可以创建纯YAML的发布管道，也可以选择将构建与发布合并到同一管道，两种方案都能满足需求，具体怎么选看你的场景：

1. 多阶段YAML管道：合或分都可行 #

合并构建与发布到同一管道 #

把构建、测试、部署都写在一个YAML文件里，用阶段条件控制流程触发逻辑，适合小型项目或构建发布逻辑绑定紧密的场景：

stages:
- stage: Build
  jobs:
  - job: Build_App
    steps:
    - script: dotnet build --configuration Release
      displayName: "编译应用"
    - publish: $(Build.ArtifactStagingDirectory)
      artifact: AppPackage # 上传构建产物为工件

- stage: Deploy_Staging
  condition: succeeded('Build') # 仅构建成功后执行
  jobs:
  - deployment: Deploy_To_Staging
    environment: '测试环境' # 关联已配置的环境（可设置审批）
    strategy:
      runOnce:
        deploy:
          steps:
          - download: current
            artifact: AppPackage
          - task: AzureWebApp@1
            inputs:
              azureSubscription: 'Azure订阅'
              appName: '测试环境App服务'
              package: '$(Pipeline.Workspace)/AppPackage/*.zip'

- stage: Deploy_Production
  condition: succeeded('Deploy_Staging') # 测试环境部署成功后触发
  jobs:
  - deployment: Deploy_To_Prod
    environment: '生产环境'
    strategy:
      runOnce:
        deploy:
          steps:
          - download: current
            artifact: AppPackage
          - task: AzureWebApp@1
            inputs:
              azureSubscription: 'Azure订阅'
              appName: '生产环境App服务'
              package: '$(Pipeline.Workspace)/AppPackage/*.zip'

分离构建与发布为独立YAML管道 #

如果需要构建和发布逻辑解耦（比如不同团队维护构建和发布），可以单独写一个YAML发布管道，通过引用构建管道的工件触发：

# 发布管道YAML
resources:
  pipelines:
  - pipeline: MyBuildPipeline
    source: '你的构建管道名称' # 关联已有的构建管道
    trigger:
      branches:
        include:
        - main # 当构建管道的main分支有新构建时触发发布

stages:
- stage: Deploy_Prod
  jobs:
  - deployment: Prod_Deployment
    environment: '生产环境'
    strategy:
      runOnce:
        deploy:
          steps:
          - download: MyBuildPipeline
            artifact: AppPackage # 下载构建管道的产物
          - task: AzureWebApp@1
            inputs:
              azureSubscription: 'Azure订阅'
              appName: '生产环境App服务'
              package: '$(Pipeline.Workspace)/MyBuildPipeline/AppPackage/*.zip'

2. 经典发布管道迁移到YAML的步骤 #

• 梳理现有逻辑：把经典管道里的部署阶段、任务、环境配置（审批、变量、部署组）都列出来，理清每个环节的作用。
• 任务转YAML：把每个经典任务替换成对应的YAML任务，比如文件复制、Azure部署、数据库脚本执行等，官方大部分任务都有YAML版本，直接复用任务的YAML代码即可。
• 配置环境与审批：在Azure DevOps门户里创建对应的环境并设置审批规则，然后在YAML的deployment任务里引用这个环境即可。
• 变量与机密复用：把经典管道里的变量组直接引用到YAML中，机密变量会自动加密，无需额外处理：

variables:
- group: '生产环境变量组' # 引用已有的变量组

3. 方案选择建议 #

• 选合并管道：小型项目、构建发布流程简单，想一键完成全流程，便于追踪整个链路状态的场景。
• 选分离管道：大型项目、多团队协作（构建和发布由不同团队维护）、需要基于同一个构建版本多次触发发布的场景，灵活性更高。

4. 注意点 #

• 少数自定义任务如果没有官方YAML支持，也可以用task: 任务ID@版本号的方式直接引用，和经典管道里的任务ID对应。
• 部署策略除了runOnce，还支持rolling、canary等，适合复杂的发布场景，按需选择。
• 可以在YAML里加入条件判断，比如根据分支选择不同的部署环境，比如main分支部署生产，develop分支部署测试。

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