将Visual Studio 2022 .NET测试项目从Bitbucket流水线迁移至Azure DevOps

一、迁移后的Azure DevOps YAML配置示例 #

以下是对应原Bitbucket流水线逻辑的azure-pipelines.yml配置：

trigger:
  branches:
    include:
      - '*'  # 触发所有分支，对应Bitbucket的default流水线
      - staging  # 单独指定staging分支触发

resources:
  containers:
    - container: customTestContainer
      image: <你的自定义Docker镜像地址>  # 替换为原Bitbucket中使用的<dockerContainerName>地址
      options: --user root  # 若镜像需要权限操作，可根据实际情况添加

jobs:
- job: RunTests_Testing
  displayName: '在Testing环境运行测试'
  container: customTestContainer
  condition: ne(variables['Build.SourceBranch'], 'refs/heads/staging')  # 非staging分支执行此任务
  variables:
    - name: ENV
      value: 'testing'
    - name: CHROME_BIN
      value: '/usr/bin/google-chrome'  # 直接指定路径，也可在脚本中用`which google-chrome`动态获取

  steps:
  - script: |
      echo $CHROME_BIN
      echo $(PROFILE_TYPE)
      echo $(FEATURE_TYPE)
      dotnet restore
      dotnet test
    displayName: '执行测试脚本'
    env:
      PROFILE_TYPE: $(PROFILE_TYPE)
      FEATURE_TYPE: $(FEATURE_TYPE)

  # 保存测试截图工件，对应Bitbucket的artifacts配置
  - task: PublishBuildArtifacts@1
    displayName: '发布Testing环境测试截图'
    inputs:
      PathtoPublish: '$(Build.SourcesDirectory)/<projectName>/bin/Debug/Screenshots'
      ArtifactName: 'TestingTestScreenshots'
      publishLocation: 'Container'

# Staging分支专属测试任务
- job: RunTests_Staging
  displayName: '在Staging环境运行测试'
  container: customTestContainer
  condition: eq(variables['Build.SourceBranch'], 'refs/heads/staging')  # 仅staging分支执行此任务
  variables:
    - name: ENV
      value: 'staging'
    - name: CHROME_BIN
      value: '/usr/bin/google-chrome'

  steps:
  - script: |
      echo $CHROME_BIN
      echo $(PROFILE_TYPE)
      echo $(FEATURE_TYPE)
      dotnet restore
      dotnet test
    displayName: '执行Staging环境测试脚本'
    env:
      PROFILE_TYPE: $(PROFILE_TYPE)
      FEATURE_TYPE: $(FEATURE_TYPE)

  - task: PublishBuildArtifacts@1
    displayName: '发布Staging环境测试截图'
    inputs:
      PathtoPublish: '$(Build.SourcesDirectory)/<projectName>/bin/Debug/Screenshots'
      ArtifactName: 'StagingTestScreenshots'
      publishLocation: 'Container'

二、关键配置对应说明 #

• 镜像引用：原Bitbucket的image对应Azure DevOps的resources.containers，需确保自定义镜像已推送到Azure容器注册表（ACR）、Docker Hub等可访问仓库，且流水线有权限拉取。
• 分支触发与任务区分：通过trigger.branches配置分支触发规则，用condition判断分支，实现原Bitbucket中default和staging分支的差异化任务。
• 环境变量：原Bitbucket的export命令可直接在Azure的script块执行，也可通过variables提前定义；PROFILE_TYPE、FEATURE_TYPE这类流水线变量，Azure会自动从流水线变量配置中注入。
• 工件保存：原Bitbucket的artifacts对应Azure的PublishBuildArtifacts@1任务，$(Build.SourcesDirectory)等效于Bitbucket的$BITBUCKET_CLONE_DIR。

三、自定义Docker镜像适配说明 #

现有Dockerfile可继续使用，需注意两点：

1. 镜像推送：将镜像推送到Azure可访问的仓库，以ACR为例：

# 登录ACR
az acr login --name <你的ACR名称>
# 标记镜像
docker tag <本地镜像名> <你的ACR名称>.azurecr.io/<镜像名>:<版本号>
# 推送镜像
docker push <你的ACR名称>.azurecr.io/<镜像名>:<版本号>

2. SDK版本兼容：若项目基于Visual Studio 2022（对应.NET 6+），可将Dockerfile基础镜像替换为mcr.microsoft.com/dotnet/sdk:6.0-focal或更高版本，确保环境兼容。

四、额外注意事项 #

• 私有镜像仓库需在Azure DevOps中配置服务连接，确保流水线有权限拉取镜像。
• dotnet test可指定测试项目路径（如dotnet test ./<测试项目名>.csproj），避免多项目解决方案中的歧义。
• 可将重复的测试步骤提取为YAML模板，减少配置冗余。

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