Azure DevOps中Angular分支差异化构建部署方案咨询

嗨，我来帮你搞定这个Azure DevOps的流水线配置问题！完全不用在dev和master分支分别维护azure-pipelines.yml，一个文件就能实现你的所有需求，还能避免合并分支时的配置冲突，这才是最优方案～

核心思路是利用分支触发规则+多阶段条件判断，让同一个流水线根据触发分支自动切换构建命令和部署目标，既简化维护又避免冲突。

具体配置步骤 #

1. 定义分支触发规则 #

先指定只有dev和master分支的代码提交才会触发流水线：

trigger:
  branches:
    include:
      - dev
      - master

2. 构建阶段：根据分支自动选择build命令 #

通过条件判断，让流水线识别当前分支，自动执行对应的Angular构建命令，同时将构建产物发布为Azure DevOps制品：

stages:
  - stage: Build
    jobs:
      - job: Build_Job
        pool:
          vmImage: 'ubuntu-latest' # 也可根据项目需求选windows-latest
        steps:
          - task: NodeTool@0
            inputs:
              versionSpec: '18.x' # 替换为你的项目兼容的Node版本
            displayName: '安装Node.js'

          - script: |
              npm install -g @angular/cli
              npm install
            displayName: '安装依赖包'

          # dev分支执行测试环境构建
          - script: ng build --dev
            displayName: '构建测试环境包'
            condition: eq(variables['Build.SourceBranchName'], 'dev')

          # master分支执行生产环境构建
          - script: ng build --prod
            displayName: '构建生产环境包'
            condition: eq(variables['Build.SourceBranchName'], 'master')

          # 发布构建产物为Azure DevOps制品
          - task: PublishBuildArtifacts@1
            inputs:
              PathtoPublish: 'dist' # Angular默认构建输出目录
              ArtifactName: 'angular-app-artifact'
              publishLocation: 'Container'

3. 部署阶段：分环境精准部署 #

同样通过条件判断，让不同分支的构建产物部署到对应环境：

- stage: Deploy_Test
    displayName: '部署到测试环境'
    dependsOn: Build
    condition: eq(variables['Build.SourceBranchName'], 'dev')
    jobs:
      - job: Deploy_Test_Job
        steps:
          # 下载之前发布的构建制品
          - task: DownloadBuildArtifacts@0
            inputs:
              buildType: 'current'
              downloadType: 'single'
              artifactName: 'angular-app-artifact'
              downloadPath: '$(System.ArtifactsDirectory)'

          # 替换为你实际的测试环境部署任务（比如Azure App Service部署）
          - task: AzureWebApp@1
            inputs:
              azureSubscription: '<你的Azure订阅连接>'
              appType: 'webApp'
              appName: '<你的测试环境App Service名称>'
              package: '$(System.ArtifactsDirectory)/angular-app-artifact/dist/**'
              deploymentMethod: 'auto'

  - stage: Deploy_Production
    displayName: '部署到生产环境'
    dependsOn: Build
    condition: eq(variables['Build.SourceBranchName'], 'master')
    jobs:
      - job: Deploy_Prod_Job
        steps:
          - task: DownloadBuildArtifacts@0
            inputs:
              buildType: 'current'
              downloadType: 'single'
              artifactName: 'angular-app-artifact'
              downloadPath: '$(System.ArtifactsDirectory)'

          # 替换为你实际的生产环境部署任务
          - task: AzureWebApp@1
            inputs:
              azureSubscription: '<你的Azure订阅连接>'
              appType: 'webApp'
              appName: '<你的生产环境App Service名称>'
              package: '$(System.ArtifactsDirectory)/angular-app-artifact/dist/**'
              deploymentMethod: 'auto'

为什么不建议用两个YAML文件？ #

如果在dev和master各放一个azure-pipelines.yml，确实能实现功能，但会带来两个明显问题：

• 维护成本高：两个文件大部分内容重复，每次修改构建逻辑（比如Node版本、依赖安装命令）都要改两次，容易出错。
• 合并冲突：当你把dev合并到master时，如果两个YAML有差异，必然会产生冲突，需要手动解决，非常麻烦。

而单YAML文件的方式，所有配置集中维护，分支逻辑通过条件判断实现，完全不会有合并冲突的问题，是更高效的选择。

额外优化建议 #

• 添加生产环境审批：在Azure DevOps流水线设置中给生产部署阶段添加人工审批，避免误提交直接部署到生产。
• 缓存依赖包：添加Cache@2任务缓存node_modules，大幅加快后续构建速度：

- task: Cache@2
  inputs:
    key: 'npm | "$(Agent.OS)" | package-lock.json'
    restoreKeys: |
       npm | "$(Agent.OS)"
    path: $(npm_config_cache)
  displayName: '缓存npm依赖'

• 变量组管理：把环境相关配置（比如App Service名称、订阅ID）放到Azure DevOps变量组中，避免硬编码在YAML里，更安全灵活。

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