多Azure Repos场景下如何配置统一共享YAML CI/CD流水线

完全可以实现，核心通过Azure DevOps YAML模板、多仓库资源触发、参数化映射三个能力组合完成，不需要在每个业务仓库单独维护流水线文件。

具体落地步骤 #

• 第一步：在共享仓库抽离公共模板
  在专门存放公共流水线的共享Azure Repos中，创建统一的模板文件，把所有项目通用的ASP.NET Core构建、部署逻辑全部封装为可传参的模板，仅把项目名、目标Web App、部署环境这类差异化内容作为入参。
  核心模板示例（存为templates/build-deploy.yml）：

  parameters:
  - name: projectRepoAlias
    type: string
  - name: projectEntryName
    type: string
  - name: targetWebApp
    type: string
  - name: deployEnv
    type: string
    values: ['dev', 'staging', 'prod']
  
  stages:
  - stage: Build
    displayName: 构建项目
    jobs:
    - job: BuildPublish
      pool:
        vmImage: 'windows-latest'
      steps:
      - checkout: ${{ parameters.projectRepoAlias }}
      - task: DotNetCoreCLI@2
        displayName: 还原依赖
        inputs:
          command: 'restore'
          projects: '**/${{ parameters.projectEntryName }}.csproj'
      - task: DotNetCoreCLI@2
        displayName: 发布项目
        inputs:
          command: 'publish'
          projects: '**/${{ parameters.projectEntryName }}.csproj'
          arguments: '-c Release -o $(Build.ArtifactStagingDirectory)'
      - publish: $(Build.ArtifactStagingDirectory)
        artifact: webpackage
  
  - stage: Deploy
    displayName: 部署到Azure Web App
    dependsOn: Build
    jobs:
    - deployment: DeployWeb
      environment: ${{ parameters.deployEnv }}
      strategy:
        runOnce:
          deploy:
            steps:
            - task: AzureWebApp@1
              inputs:
                azureSubscription: '你的Azure服务连接名称'
                appName: ${{ parameters.targetWebApp }}
                package: $(Pipeline.Workspace)/webpackage
  

• 第二步：配置多仓库触发规则
  在共享仓库创建流水线入口文件universal-pipeline.yml，关闭共享仓库本身的提交触发，把所有业务项目的Azure Repos声明为流水线资源，给每个资源配置对应分支的提交触发规则——只要业务仓库指定分支有代码提交，就会自动启动这条统一流水线。
  入口文件的资源配置示例：

  trigger: none # 共享仓库自身改动不触发业务部署
  pr: none
  
  resources:
    repositories:
    - repository: ServiceA # 仓库别名，后续映射用
      type: git
      name: 你的DevOps项目名/ServiceA仓库名
      trigger:
        branches:
          include:
          - main
          - develop
    - repository: ServiceB
      type: git
      name: 你的DevOps项目名/ServiceB仓库名
      trigger:
        branches:
          include:
          - main
          - develop
    # 后续新增项目只需在此追加仓库配置即可
  

• 第三步：配置项目与部署目标的自动映射
  利用Azure DevOps的预定义变量resources.triggeringAlias（自动获取触发本次流水线的仓库别名），在入口文件中维护一份仓库与部署目标的映射表，流水线启动时会自动匹配当前提交对应的项目信息、要部署的Web App、对应环境，不需要人工传参。
  映射逻辑示例：

  variables:
    - name: isProdTrigger
      value: $[eq(variables['Build.SourceBranch'], 'refs/heads/main')]
    # 项目配置映射表
    - name: projectConfigMap
      value: |
        {
          "ServiceA": {"entryProject": "ServiceA.Web", "devApp": "svc-a-dev", "prodApp": "svc-a-prod"},
          "ServiceB": {"entryProject": "ServiceB.Web", "devApp": "svc-b-dev", "prodApp": "svc-b-prod"}
        }
    - name: currentConfig
      value: $[convertToJson(projectConfigMap[resources.triggeringAlias])]
  
  stages:
  - template: ./templates/build-deploy.yml
    parameters:
      projectRepoAlias: ${{ resources.triggeringAlias }}
      projectEntryName: $[variables.currentConfig.entryProject]
      targetWebApp: $[iif(variables.isProdTrigger, variables.currentConfig.prodApp, variables.currentConfig.devApp)]
      deployEnv: $[iif(variables.isProdTrigger, 'prod', 'dev')]
  

• 第四步：权限配置
  给这条统一流水线所在的项目授予所有业务代码仓库的读取权限，以及所有目标Azure Web App对应服务连接的使用权限即可，不需要给每个业务项目单独配置服务连接和流水线权限。

方案补充说明 #

• 所有公共逻辑只需要维护一份，后续要加单元测试、安全扫描、镜像构建这类通用步骤，只需要修改共享仓库里的模板，所有接入的项目会自动生效，不需要逐个仓库修改YAML。
• 如果个别项目有定制化步骤需求，只需要给模板增加可选参数，给定制步骤加条件判断即可，不需要拆分统一流水线。
• 新增项目接入时，只需要在资源列表追加仓库配置、在映射表加一行项目对应关系，10分钟内即可完成接入，不需要重新搭建整条流水线。

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