★★ 中級

04. Azure でチーム開発(Azure DevOps)

Azure 環境では Azure DevOps(Repos / Pipelines / Boards / Artifacts / Test Plans)が伝統的に使われてきました。近年は GitHub Enterprise + Actions に移行する組織も多い。両者の役割と使い分けを整理します。

Azure DevOps 全体図

Azure DevOps:Repos / Pipelines / Boards / Artifacts / Test Plans
Repos でコード、Pipelines で CI/CD、Boards で計画、Artifacts で成果物、Test Plans で手動テスト。Microsoft 系の組織で長く使われてきた構成。

Azure Repos(Git)

Azure Repos は Git ホスティング。GitHub と機能はほぼ同等ですが、Entra ID と統合された権限管理が強みです。

新規プロジェクトは GitHub Enterprise を選ぶケースが増加。Azure DevOps 既存ユーザは引き続き Repos を使うことも多い。

Azure Pipelines(CI/CD)

Azure Pipelines は YAML で定義する CI/CD。GitHub Actions と発想は似ています。

# azure-pipelines.yml
trigger:
  branches:
    include: [main]

pool:
  vmImage: 'ubuntu-latest'

variables:
  - group: prod-secrets   # Library に登録した変数グループを参照

stages:
  - stage: Build
    jobs:
      - job: BuildJob
        steps:
          - task: NodeTool@0
            inputs:
              versionSpec: '20.x'
          - script: |
              npm ci
              npm test
              npm run build
            displayName: 'Build and test'
          - publish: $(System.DefaultWorkingDirectory)/dist
            artifact: drop

  - stage: Deploy
    dependsOn: Build
    condition: succeeded()
    jobs:
      - deployment: DeployJob
        environment: 'production'   # approval を環境側で設定
        strategy:
          runOnce:
            deploy:
              steps:
                - download: current
                  artifact: drop
                - task: AzureWebApp@1
                  inputs:
                    azureSubscription: 'azure-prod-sc'
                    appName: 'myapp'
                    package: '$(Pipeline.Workspace)/drop'

Artifacts / Container Registry

サービス用途
Azure Artifactsnpm / NuGet / Maven / Python / Universal feed
Azure Container Registry (ACR)Docker / OCI イメージ
Storage Account (Blob)汎用成果物

Boards / Test Plans

GitHub Issues + Projects との大きな差は「Test Plans」と「Entra ID とのきめ細かな統合」。新規組織は GitHub Issues で十分なことが多いです。

GitHub Actions → Azure の OIDC

GitHub Actions から Azure リソースを操作する場合も OIDC が使えます。AWS 同様、Azure 側に Federated Credential を作って、サービスプリンシパルを Actions にひも付けます。

# Terraform で Federated Credential を作る
resource "azuread_application" "github" {
  display_name = "github-actions-myapp"
}

resource "azuread_service_principal" "github" {
  client_id = azuread_application.github.client_id
}

resource "azuread_application_federated_identity_credential" "github_main" {
  application_id = azuread_application.github.id
  display_name   = "github-main"
  description    = "GitHub Actions main branch"
  audiences      = ["api://AzureADTokenExchange"]
  issuer         = "https://token.actions.githubusercontent.com"
  subject        = "repo:myorg/myapp:ref:refs/heads/main"
}

# ロール割当
resource "azurerm_role_assignment" "github_contributor" {
  scope                = data.azurerm_subscription.current.id
  role_definition_name = "Contributor"
  principal_id         = azuread_service_principal.github.object_id
}
# .github/workflows/deploy.yml の側
permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
      - run: terraform apply -auto-approve

Azure DevOps vs GitHub Actions

項目Azure DevOps PipelinesGitHub Actions
YAML 形式独自独自
料金同時実行ジョブ単位分単位(プライベートで分課金)
GitHub 連携外部接続ネイティブ
Boards との統合強いProjects で代替可
新規採用率低下傾向増加中

結論:新規プロジェクトは GitHub Actions、既存の Azure DevOps 環境は引き続き Pipelines。Azure に閉じない開発を想定する場合は GitHub Actions が無難です。