Azure DevOpsでのCI/CDパイプライン構築ガイド（2026年版）

2026年5月9日

Contents

1 1️⃣ 前提条件と環境準備
2 2️⃣ パイプライン作成方法 ― Classic UI と YAML の比較
3 3️⃣ 推奨マルチステージ YAML パイプライン例
- 3.1 主要ポイントの解説
4 4️⃣ トラブルシューティング・よくあるエラー
5 5️⃣ ベストプラクティスと次のステップ
6 6️⃣ まとめ
- 6.1 参考文献

スポンサードリンク

1️⃣ 前提条件と環境準備

手順	内容	主な参照元
1	Azure DevOps にサインアップし、組織 (`myorg`) を作成	Microsoft Docs: Create an organization
2	組織内にプロジェクト (`WebApp‑CI‑CD`) を作成	同上
3	プロジェクトの Repos タブで Git リポジトリを作成し、ローカルコードをプッシュ	Microsoft Docs: Create a repo
4	Pipelines → Agent pools を確認し、`ubuntu‑latest` が利用可能かチェック	Microsoft Docs: Agent pools
5	必要な権限 (Project Collection Build Service) をプロジェクトに付与	同上

ポイント
組織・プロジェクト・リポジトリが整ったら、次はパイプライン本体の作成へ進みます。

2️⃣ パイプライン作成方法 ― Classic UI と YAML の比較

項目	Classic UI	YAML
操作性	GUI だけで構築でき、初心者に優しい	テキストエディタで記述し、コードとして管理
保守性	手動変更が中心で履歴が残りにくい	Git にコミットできるため変更履歴が明確
再利用性	テンプレートは UI から選択する程度	`templates` 機能で共通ロジックを切り出し可能
推奨シナリオ	小規模・短期プロトタイプ	中〜大規模、長期間運用する案件

実務的アドバイス
まず Classic UI で全体像を掴み、基本が動いたら同等の YAML に置き換える流れが多く見られます（Microsoft Docs のベストプラクティス参照）[^4]。

3️⃣ 推奨マルチステージ YAML パイプライン例

以下は .NET 7 アプリを対象とした、ビルド・テスト・成果物公開・デプロイの 4 ステージ構成です。
※実行環境は ubuntu‑latest（Microsoft‑hosted）を想定しています。

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

variables:
  buildConfiguration: 'Release'
  artifactName: 'drop'

stages:
# ── Build &amp; Test ───────────────────────
- stage: Build
  displayName: ビルド・テスト
  jobs:
  - job: RestoreBuildTest
    pool:
      vmImage: 'ubuntu-latest'
    steps:
    # .NET SDK の取得
    - task: UseDotNet@2
      inputs:
        packageType: 'sdk'
        version: '7.x'

    # NuGet パッケージ復元
    - script: dotnet restore
      displayName: NuGet restore

    # ビルド
    - script: |
        dotnet build --configuration $(buildConfiguration) --no-restore
      displayName: Build

    # テスト (XPlat Code Coverage 取得)
    - script: |
        dotnet test --configuration $(buildConfiguration) \
          --collect:&quot;XPlat Code Coverage&quot; \
          --results-directory $(Agent.TempDirectory)/test-results
      displayName: Test

    # テスト結果の公開
    - task: PublishTestResults@2
      inputs:
        testResultsFiles: '**/TEST-*.xml'
        mergeTestResults: true
        testRunTitle: Unit Tests

    # カバレッジ結果の公開
    - task: PublishCodeCoverageResults@1
      inputs:
        codeCoverageTool: 'Cobertura'
        summaryFileLocation: '$(Agent.TempDirectory)/**/coverage.cobertura.xml'
        reportDirectory: '$(Agent.TempDirectory)/test-results'

    # アーティファクトの保存
    - task: PublishBuildArtifacts@1
      inputs:
        PathtoPublish: '$(Build.SourcesDirectory)'
        ArtifactName: $(artifactName)
        publishLocation: 'Container'

# ── Deploy to Azure Web App ───────────────────────
- stage: Deploy
  displayName: Azure Web App デプロイ
  dependsOn: Build
  condition: succeeded()
  jobs:
  - deployment: DeployWebApp
    environment: Production
    pool:
      vmImage: 'ubuntu-latest'
    strategy:
      runOnce:
        deploy:
          steps:
          # Key Vault からシークレット取得 (オプション)
          - task: AzureKeyVault@2
            inputs:
              azureSubscription: 'MyServiceConnection'
              KeyVaultName: 'my-keyvault'
              SecretsFilter: '*'

          # ビルド成果物のダウンロード
          - download: current
            artifact: $(artifactName)

          # Web App へデプロイ
          - task: AzureWebApp@1
            inputs:
              azureSubscription: 'MyServiceConnection'
              appType: 'webAppLinux'   # .NET 7 on Linux の例
              appName: 'my-webapp-prod'
              package: $(Pipeline.Workspace)/$(artifactName)/**/*.zip
              runtimeStack: 'DOTNETCORE|7.0'

# azure-pipelines.yml

trigger:

branches:

include: [ main, develop ]

variables:

buildConfiguration: 'Release'

artifactName: 'drop'

stages:

# ── Build & Test ───────────────────────

- stage: Build

displayName: ビルド・テスト

jobs:

- job: RestoreBuildTest

pool:

vmImage: 'ubuntu-latest'

steps:

# .NET SDK の取得

- task: UseDotNet@2

inputs:

packageType: 'sdk'

version: '7.x'

# NuGet パッケージ復元

- script: dotnet restore

displayName: NuGet restore

# ビルド

- script: |

dotnet build --configuration $(buildConfiguration) --no-restore

displayName: Build

# テスト (XPlat Code Coverage 取得)

- script: |

dotnet test --configuration $(buildConfiguration) \

--collect:"XPlat Code Coverage" \

--results-directory $(Agent.TempDirectory)/test-results

displayName: Test

# テスト結果の公開

- task: PublishTestResults@2

inputs:

testResultsFiles: '**/TEST-*.xml'

mergeTestResults: true

testRunTitle: Unit Tests

# カバレッジ結果の公開

- task: PublishCodeCoverageResults@1

inputs:

codeCoverageTool: 'Cobertura'

summaryFileLocation: '$(Agent.TempDirectory)/**/coverage.cobertura.xml'

reportDirectory: '$(Agent.TempDirectory)/test-results'

# アーティファクトの保存

- task: PublishBuildArtifacts@1

inputs:

PathtoPublish: '$(Build.SourcesDirectory)'

ArtifactName: $(artifactName)

publishLocation: 'Container'

# ── Deploy to Azure Web App ───────────────────────

- stage: Deploy

displayName: Azure Web App デプロイ

dependsOn: Build

condition: succeeded()

jobs:

- deployment: DeployWebApp

environment: Production

pool:

vmImage: 'ubuntu-latest'

strategy:

runOnce:

deploy:

steps:

# Key Vault からシークレット取得 (オプション)

- task: AzureKeyVault@2

inputs:

azureSubscription: 'MyServiceConnection'

KeyVaultName: 'my-keyvault'

SecretsFilter: '*'

# ビルド成果物のダウンロード

- download: current

artifact: $(artifactName)

# Web App へデプロイ

- task: AzureWebApp@1

inputs:

azureSubscription: 'MyServiceConnection'

appType: 'webAppLinux' # .NET 7 on Linux の例

appName: 'my-webapp-prod'

package: $(Pipeline.Workspace)/$(artifactName)/**/*.zip

runtimeStack: 'DOTNETCORE|7.0'

主要ポイントの解説

項目	内容
トリガー	`main` と `develop` のプッシュで自動実行。不要なブランチは `exclude` に列記可。
変数活用	ビルド構成やアーティファクト名を変数化し、ステージ間で再利用。
テスト・カバレッジ	`dotnet test --collect:"XPlat Code Coverage"` でプラットフォーム横断のカバレッジ取得。
シークレット管理	`AzureKeyVault@2` により、コードに埋め込まず安全に環境変数へ注入。
デプロイ条件	`condition: succeeded()` で前ステージが成功したときのみ実行。

出典
- Azure Pipelines の基本構成 – Microsoft Docs[^5]
- AzureWebApp@1 タスクの最新仕様 – Microsoft Docs[^6]

4️⃣ トラブルシューティング・よくあるエラー

エラー	主な原因	解決策
Agent pool is not authorized	プロジェクトがプライベートプールを使用しているが、ビルドサービスに権限が付与されていない	Project Settings → Agent pools で Project Collection Build Service に `Use` 権限を付与
NuGet restore failed (404)	フィード URL が古い・認証トークン切れ	Azure Artifacts の最新フィード URL を取得し、`nuget.config` を更新
Code coverage file not found	`dotnet test` にカバレッジオプションが付いていない	必ず `--collect:"XPlat Code Coverage"` を付与
Deployment to Azure Web App failed: 403 Forbidden	Service Connection のロール不足、または Key Vault のアクセスポリシー未設定	Azure Portal → IAM で対象リソースに `Contributor` 権限を付与し、Key Vault に同一サービスプリンシパルを追加

ポイント
権限系のミスが最も多く報告されます。パイプライン実行前に Service Connection と Agent pool の権限だけは必ず検証しておきましょう。

5️⃣ ベストプラクティスと次のステップ

5.1 YAML のテンプレート化

共通ロジック（ビルド・テスト・デプロイ）を templates/ 配下に切り出すことで、複数リポジトリで再利用可能です。

# azure-pipelines.yml (メイン)
trigger:
  - main

stages:
- template: templates/build-test.yml
- template: templates/deploy-prod.yml

# azure-pipelines.yml (メイン)

trigger:

- main

stages:

- template: templates/build-test.yml

- template: templates/deploy-prod.yml

`templates/build-test.yml` の例

parameters:
  vmImage: 'ubuntu-latest'

stages:
- stage: Build
  jobs:
  - job: RestoreBuildTest
    pool:
      vmImage: ${{ parameters.vmImage }}
    steps:
    # （前述のビルド・テスト手順を流用）

parameters:

vmImage: 'ubuntu-latest'

stages:

- stage: Build

jobs:

- job: RestoreBuildTest

pool:

vmImage: ${{ parameters.vmImage }}

steps:

# （前述のビルド・テスト手順を流用）

参考：Microsoft の「YAML templates」ガイド[^7]。

5.2 IaC（Infrastructure as Code）との統合

Bicep または ARM テンプレートをパイプラインに組み込むと、インフラとアプリケーションの構成がコードで一元管理できます。

- stage: Infra
  displayName: インフラデプロイ
  jobs:
  - job: DeployBicep
    pool:
      vmImage: 'ubuntu-latest'
    steps:
    - task: AzureResourceManagerTemplateDeployment@3
      inputs:
        deploymentScope: 'Resource Group'
        azureResourceManagerConnection: 'MyServiceConnection'
        resourceGroupName: 'rg-prod-webapp'
        location: 'East US'
        templateLocation: 'Linked artifact'
        csmFile: 'infra/main.bicep'
        deploymentMode: 'Incremental'

- stage: Infra

displayName: インフラデプロイ

jobs:

- job: DeployBicep

pool:

vmImage: 'ubuntu-latest'

steps:

- task: AzureResourceManagerTemplateDeployment@3

inputs:

deploymentScope: 'Resource Group'

azureResourceManagerConnection: 'MyServiceConnection'

resourceGroupName: 'rg-prod-webapp'

location: 'East US'

templateLocation: 'Linked artifact'

csmFile: 'infra/main.bicep'

deploymentMode: 'Incremental'

効果
- 環境ごとの構成差分がコードレビューで可視化できる。
- ロールバックや再現性が向上する。

5.3 継続的改善のサイクル

メトリクス収集 – ビルド時間、テストカバレッジ、デプロイ成功率を Azure DevOps の Analytics で可視化。
フィードバックループ – PR ごとにパイプラインが走り、結果をコメントとして自動投稿（Pull Request Comment タスク活用）。
スケールアウト – ビルドが頻繁にキューイングされる場合は、Microsoft‑hosted の ubuntu‑latest からセルフホストプールへ移行し、キャッシュやカスタムツールを事前インストール。

6️⃣ まとめ

環境準備 → 組織・プロジェクト・リポジトリを作成し、エージェントプールと権限を確認。
パイプライン作成は Classic UI で概念把握→YAML に移行するのが実務的。
マルチステージ YAMLでビルド・テスト・成果物公開・デプロイを一括管理し、Key Vault 等でシークレットを安全に扱う。
トラブルは権限系が多いので、Service Connection と Agent pool の設定は最優先で検証。
テンプレート化と IaCで保守性・再利用性を高め、Analytics による継続的改善サイクルを構築する。

これらの手順とベストプラクティスに沿って実装すれば、堅牢かつ拡張性のある Azure DevOps CI/CD パイプラインが構築できます。

参考文献

[^1]: Create an organization – Microsoft Docs. https://learn.microsoft.com/azure/devops/organizations/accounts/create-organization
[^2]: Create a repo – Microsoft Docs. https://learn.microsoft.com/azure/devops/repos/git/create-new-repo
[^3]: Agent pools – Microsoft Docs. https://learn.microsoft.com/azure/devops/pipelines/agents/pools-queues
[^4]: Choose between Classic pipelines and YAML pipelines – Microsoft Docs. https://learn.microsoft.com/azure/devops/pipelines/yaml/get-started?view=azure-devops#classic-vs-yaml-pipelines
[^5]: First pipeline – Microsoft Docs. https://learn.microsoft.com/azure/devops/pipelines/create-first-pipeline
[^6]: AzureWebApp@1 task – Microsoft Docs. https://learn.microsoft.com/azure/devops/pipelines/tasks/deploy/azure-web-app?view=azure-devops
[^7]: YAML templates – Microsoft Docs. https://learn.microsoft.com/azure/devops/pipelines/process/templates

スポンサードリンク

-Azure

comment コメントをキャンセル

: Azure

2026年版 Azure 無料トライアルで AI リソースをすぐ始める方法

Azure の無料トライアルと $200 クレジットを活用し、Japan East リージョンで AI 用リソースグループ・ワークスペースを作成し、OpenAI と Functions で API をすぐにデプロイする手順を紹介します。

: Azure

Azure Service Health の概要と活用方法｜ポータル・API・自動監視

Azure Service Health の機能と利用シナリオを紹介し、ポータルでの確認手順やREST API活用例、スクリプトによる自動監視設定まで網羅的に解説します。

: Azure

Azure AIサービスと料金モデル：中小企業向け従量課金と活用事例

Azure AI の従量課金と無料枠、チャットボットや文書要約など5つの具体的活用事例、導入ステップとROI測定方法を解説します。

: Azure

Azure Cost Management と Advisor活用術：2026年版最適化ガイド

本ガイドでは、2026年刷新されたAzure Cost Managementダッシュボードの使い方からAdvisorによる未使用リソース削減、Savings PlansとRIの選択基準、Spot VMとサーバーレスでのコスト削減事例、AI Insightsを活用した継続的最適化までを網羅しています。

: Azure

Maia 200 と ND96asr_v4 の概要と Azure VM デプロイ手順

Maia 200 と ND96asr_v4 の概要と、Azure ポータル・CLIでの VM 作成方法、ML デプロイ手順を紹介。

2025年以降のSIer導入市場と大手・中小SIer比較 – コスト最適化とリスク低減

Google Cloud 無料トライアル $300 クレジット活用ガイド：設定・管理・Always Free移行

Azure DevOpsでのCI/CDパイプライン構築ガイド（2026年版）

1️⃣ 前提条件と環境準備

2️⃣ パイプライン作成方法 ― Classic UI と YAML の比較

3️⃣ 推奨マルチステージ YAML パイプライン例

主要ポイントの解説

4️⃣ トラブルシューティング・よくあるエラー

5️⃣ ベストプラクティスと次のステップ

5.1 YAML のテンプレート化

templates/build-test.yml の例

5.2 IaC（Infrastructure as Code）との統合

5.3 継続的改善のサイクル

6️⃣ まとめ

参考文献

`templates/build-test.yml` の例