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

Azure Service Health と Resource Health の違いとアラート設定ガイド

Service Health と Resource Health の違いと、Azure Monitor でのアラート作成・アクショングループ設定、最新 UI 活用方法をわかりやすく紹介します。

: Azure

Azure AI Builder活用事例と導入手順｜OCR・感情分析・予知保全まで徹底解説

本記事では Azure AI Builder のノーコード AI 機能を中心に、Power Platform との連携方法や Azure AI Search・OpenAI との統合ポイント、請求書 OCR、顧客問い合わせの感情分析、予知保全、売上予測、チャットボット活用といった代表的シナリオを実装手順とともに紹介します。さらにライセンス形態や概算コスト、無料トライアル情報も網羅し、導入時のベストプラクティスまで解説しています。

: Azure

Azure DevOps と GitHub Actions 徹底比較：構成・料金・セキュリティと移行ベストプラクティス

本記事では、Azure DevOps と GitHub Actions の概念モデル・料金体系・セキュリティ機能を比較し、組織に最適な選択とハイブリッド移行のベストプラクティスを提示します。

: Azure

Azure OpenAI の料金体系と見積もり方法 – 2026年最新ガイド

Azure OpenAI の料金は、使用した入力・出力トークン数と選択モデルの単価でシンプルに算出できます。本稿では2026年4月時点の公式価格表、Pricing Calculatorの設定手順、割引オプション、FAQ をまとめました。

: Azure

Japan East と Japan West の概要・サービス比較と最適リージョン選定ガイド

Japan East（埼玉）と Japan West（大阪）のデータセンター概要、サービス対応率、レイテンシ・価格比較から最適リージョン選定までを網羅的に紹介します。

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` の例