Microsoft AZ-400: Azure Pipelines による CI/CD パイプライン — 学習ガイド

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

こちらの一部です： Microsoft DevOps Engineer Expert AZ-400 — 学習ガイド. 検証済みの解答で練習： Microsoft試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Azure Pipelinesは、コードとしてのエンドツーエンドCI/CDを提供し、ビルド、テスト、リリースを統合しつつ、エンタープライズレベルの統制を維持するマルチステージYAMLパイプラインを備えています。スケーラブルでセキュア、かつ再現性のあるデリバリーシステムを構築するには、YAMLのオーサリング、トリガー、エージェント、変数、テンプレート、デプロイメントジョブ、成果物、キャッシュ、サービス接続を習得することが不可欠です。

YAMLとテンプレートによるオーサリング

YAMLパイプラインは、ステージ、ジョブ、ステップで構成されます。ステージはビルド、テスト、リリースなどのライフサイクルの境界をモデル化し、ジョブはエージェント上で実行され並列実行も可能で、ステップはジョブ内で実行されるタスクやスクリプトです。依存関係は dependsOn を介して明示的に定義され、きめ細かいオーケストレーションと条件付き実行を可能にします。マルチステージYAMLはCIとCDを統合し、ファンイン/ファンアウトパターンをサポートし、承認を独立したリリース構成ではなく環境に紐付けます。

テンプレートは、さまざまな粒度での構成と再利用を可能にします。

• ステップテンプレート：タスクのシーケンス（例：ツールセットアップ、リストア、ビルド、テスト）をカプセル化し、リポジトリ間で再利用します。
• ジョブテンプレート：特定のエージェント仕様と戦略（例：テストマトリックスジョブ）を持つステップをバンドルします。
• ステージテンプレート：承認、条件、環境ターゲティングを含むステージ全体をパッケージ化し、一貫したプロモーションフローを実現します。
• Extendsテンプレート：パイプラインの継承を強制します。トップレベルの extends は、必須のステージ/ジョブ/ステップとガバナンスを規定する中央テンプレートを参照します。これは組織全体のポリシーに強力で、すべてのチームがセキュリティスキャン、コンプライアンスチェック、命名規則を継承することを保証します。

テンプレートの評価は、ランタイム実行前のコンパイル時に行われます。コンパイル時にパイプライン構造を分岐させる（例えば、main ブランチの場合のみ特定のジョブを含める）には、テンプレート式に ${{ }} を使用します。マクロ構文 $(var) とランタイム式 $[ ] はランタイムに解決されるため、シークレットや変数グループがいつ利用可能になるかに影響します。共有テンプレートは中央リポジトリに保存し、resources repositories を介してインポートします。決定論的なビルドのために、ブランチやタグにピン留めします。

トリガー、エージェント、変数、式

トリガーは自動化のエントリーポイントを管理します。

• CIトリガー：追跡対象のブランチにコードがプッシュされるとパイプラインの実行を開始します。パスフィルターの include と exclude で不要な実行を減らします。batch を使うと複数のプッシュをまとめることができます。
• PRトリガー：プルリクエストを検証します。ターゲットブランチとパスフィルターを設定し、古い実行の自動キャンセルを有効にします。
• スケジュールトリガー：cron 式で実行され、タイムゾーン制御付きの夜間ビルドや定期的な検証をサポートします。
• パイプラインリソースを宣言し、ブランチフィルター付きの trigger: true を設定することで、リポジトリやプロジェクトをまたいでパイプラインを連鎖させます。

エージェントとエージェントプールは、ジョブがどこで実行されるかを決定します。

• Microsoft-hosted agents：ubuntu-latest、windows-latest、または macOS イメージ上に、ツールセットがプリインストールされた一時的なVMをプロビジョニングします。弾力性があり、メンテナンスが最小限で済むため理想的です。並列ジョブを購入してコンカレンシーを計画し、キャッシュのウォームアップ制限を考慮してください。
• Self-hosted agents：カスタムツールチェーン、プライベートネットワークアクセス、予測可能なパフォーマンスのために、自社のインフラストラクチャ上で実行します。ホストを強化し、必要に応じてアウトバウンド通信を制限し、エージェント登録に使用されるPATをローテーションします。弾力性のためにスケールセットやコンテナ化されたエージェントを使用します。
• エージェントプール：エージェントを論理的にグループ化し、権限を委任するために使用されます。プールに対してプロジェクトレベルの「使用」権限を付与し、専用プールによって機密性の高いワークロードを分離します。ジョブはプールを指定し、オプションで demands を使用して必要な機能を持つエージェントを選択します。

変数とパラメーターは設定の柔軟性を高めます。

• パイプライン変数：キーと値のペアで、環境変数として、また $(name) マクロを通じてタスクで利用できます。シークレット変数はログでマスクされ、コンパイル時のテンプレート式では決して公開されません。ライブラリまたはパイプラインでシークレットとしてマークします。
• 変数グループ：共有の値とシークレットをライブラリで一元管理します。Azure Key Vaultにリンクしてランタイムにシークレットを取得することで、値がパイプラインに保存されないようにします。どのパイプラインがグループを利用できるかを制限するために、パイプラインの権限を制御します。
• ランタイムパラメーター：キュー投入時に厳密に型付けされた入力（string, number, boolean, object）を定義し、コンパイル時に ${{ parameters.* }} を介して評価され、パイプラインの形状を決定します（例：ステージの有効化/無効化）。パイプラインの構造を変更する必要がある場合はパラメーターを、ステップ内でランタイムの値が必要な場合は変数を優先します。
• 式：コンパイル時のテンプレートロジックには ${{ }} を、マクロ置換には $(var) を、プロパティのランタイム条件には $[condition()] を使用します。ロギングコマンドを介してタスクから変数を設定し、isOutput 変数を使用してジョブ間で出力を伝播させます。

デプロイ、環境、戦略、ゲート

デプロイジョブは、第一級のCDセマンティクスを提供します。デプロイジョブは、環境をターゲットとし、ロールアウトとライフサイクルフックを制御する戦略の下で実行されます。

• 環境は、デプロイターゲット（例：dev、test、prod）を表し、Kubernetesクラスター、仮想マシン、またはプラットフォームに依存しないデプロイのための汎用的な「none」リソースなどのリソースを含むことができます。環境は、テレメトリ、承認、およびチェックを統合します。
• 承認とチェックは、環境とサービス接続にアタッチされます。承認では、デプロイを進める前に指定された承認者が必要です。チェックは、営業時間、必須の作業項目、Azure Monitorのシグナル、REST APIやAzure Functionsの呼び出し、ブランチ保護などの条件を評価するゲートとして機能します。これらは、パフォーマンスのベースラインやコンプライアンスの条件が満たされない場合に、昇格を防ぎます。
• 戦略は、更新がどのようにロールアウトされるかを決定します。
  • runOnceは、preDeployおよびpostDeployフックを使用して、単一のウェーブで変更を適用します。
  • rollingは、安全な進行のためにmaxParallelと失敗のしきい値を設定し、インスタンス全体にバッチでデプロイします。
  • canaryは、routeTrafficおよびpostRouteTrafficフェーズで、完全なロールアウトの前に検証を行いながら、増分的にトラフィックを徐々にシフトします。
  • blue-green（red/blackとも呼ばれる）は、並列環境またはスロットにデプロイし、ロードバランサーまたはApp Serviceのスロットスワップでトラフィックを切り替えることによって実装されます。blue-greenは名前付きのYAML戦略ではありませんが、環境、ルーティング、およびスワップタスクを介して実現され、トラフィックを元に戻すことで高速なロールバックを提供します。

デプロイロジックは、環境ステージごとにデプロイジョブとしてエンコードします。堅牢なゲートのためには、アドホックなスクリプトポーリングではなく、環境のチェックを活用してください。シークレットが必要な場合は、変数に埋め込むのではなく、サービス接続を介してAzure Key Vaultから取得してください。

アーティファクト、キャッシュ、サービス接続

アーティファクトとキャッシュは、再利用性とパフォーマンスを向上させます。

• パイプラインアーティファクトは、ビルドの出力を発行および消費するためのネイティブな方法です。名前付きアーティファクトを公開するにはPublishPipelineArtifactを使用し、現在または特定の実行から取得するにはDownloadPipelineArtifactを使用します。これらは、YAMLでの信頼性とステージ間の共有に最適化されています。別のパイプラインから消費する場合は、パイプラインリソースを宣言し、そのアーティファクトリソース名を使用して正確に取得します。
• ユニバーサルパッケージは、言語に依存しないアセット（例：CLIツール、データファイル）のために、Azure Artifactsを介してバージョン管理された不変のバイナリ配布を提供します。Universal Packagesタスクで公開およびダウンロードし、フィードビュー（例：prerelease vs release）を介して整理し、フィードでの保持期間を管理します。
• パイプラインキャッシュは、依存関係の復元を高速化します。Cacheタスクは、キーとパスを使用します。キーには、正確な無効化のために、ロックファイル（package-lock.json、Pipfile.lock、packages.lock.json、go.sum）に加えて、OSとツールのバージョンをハッシュ化する必要があります。復元キーは、部分的なキャッシュヒットのためのフォールバックマッチを提供します。キャッシュパスにシークレットを埋め込むことを避け、キャッシュサイズの制限を遵守し、ロックファイルが不安定な場合は一時的なツールのキャッシュを無効にしてください。タスクの動作を分岐させるためにcacheHitVarを監視します。

サービス接続は、Azure Pipelinesが外部システムにアクセスするために使用するIDを定義します。

• 種類には、Azure Resource Manager（Azureサブスクリプションおよびリソースグループ用）、GitHub（リポジトリの読み取り/書き込み、ステータスレポート）、Docker/Container Registry（Docker Hub、ACR）などがあります。その他に、AWS、GCP、汎用サービスエンドポイント、およびパッケージレジストリ用があります。
• OIDCフェデレーション（ワークロードIDフェデレーション）は、Azure DevOpsとクラウドIDプロバイダー間の信頼関係を確立することにより、長期間有効なシークレットを排除します。ARMの場合、Azure DevOpsの発行者とリポジトリ/パイプラインのクレームにバインドされたフェデレーション資格情報を持つEntra IDアプリケーションを構成します。実行時に、Azure DevOpsは短期間有効なトークンをクラウドアクセストークンと交換し、サービスプリンシパルのシークレットを排除し、資格情報漏洩のリスクを低減します。
• スコープ設定とガバナンスは非常に重要です。ARM接続のスコープは、最小権限（理想的にはカスタムRBACを使用したリソースグループレベル）に設定します。「すべてのパイプラインにアクセス許可を付与する」を無効にし、代わりにパイプラインを明示的に承認します。サービス接続に承認とチェックをアタッチして、使用前に人間のレビューやポリシーの検証を要求します。

クラシック vs YAML と移行

クラシックパイプラインは、Build と Release の概念が分離されたビジュアルデザイナーを使用します。タスクベースのオーサリング、変数管理、リリース環境、ゲートを提供します。YAML パイプラインは、pipeline-as-code、マルチステージの統合、テンプレート、そしてリポジトリとの連携による堅牢なバージョン管理を提供します。機能的な同等性（パリティ）はほぼ達成されています。環境の承認とチェックがリリースゲートを置き換え、デプロイメントジョブが環境をモデル化し、パイプライン成果物がビルド成果物に取って代わり、テンプレートと extends が大規模な中央集権的ガバナンスを実装します。残っている違いは、主に UI ベースの手動介入や、一部のニッチなリリースデザイナー機能に関するものですが、これらは YAML では手動検証 (Manual Validation) タスクや環境チェックによってカバーされます。

現実的な移行パスは次のとおりです。

1. クラシックのビルド定義とリリース定義、タスク、変数、環境、承認、ゲートのインベントリを作成します。
2. アシスタントを使用するか YAML にエクスポートしてビルドを YAML に変換し、再利用性と保守性のためにテンプレートにリファクタリングします。
3. 各リリース環境を、環境をターゲットとするデプロイメントジョブを持つ YAML ステージとしてモデル化します。リリースゲートを環境の承認とチェック（例：Azure Monitor クエリチェック、作業項目クエリチェック）に変換します。
4. 共有変数を変数グループに外部化し、シークレットのために Key Vault をリンクします。サービスプリンシパルのシークレットを OIDC ベースのサービス接続に置き換えます。
5. リリース成果物トリガーをパイプラインリソーストリガーに置き換えます。CI でパイプライン成果物を発行し、CD ステージでそれらを使用します。
6. 両方のパイプラインを一時的に実行して同等性を検証し、その後、適切なロールバック計画とともに切り替えを行い、クラシック定義を廃止します。

実践的な問題シナリオ

Starbucks は、マイクロサービスプラットフォームのデリバリーを標準化しており、パフォーマンスゲートを強制し、認証情報のリスクを低減し、ビルドを高速化しながら、クラシックリリースから YAML に移行する必要があります。

1. extends テンプレートを使用したマルチステージ YAML の作成

• アプローチ: 静的解析、SCA、セキュリティチェックのための共通ステージと標準的な通知を注入する、組織レベルの中央 extends テンプレートを作成します。各サービスパイプラインはこのテンプレートを extends し、サービス固有のビルドおよびデプロイステージを定義します。
• 論理的根拠: extends はガバナンスを均一に強制し、必要なコンプライアンス手順を保証しながら、サービスパイプラインをスリムに保ちます。

2. CI、PR、スケジュール、パイプラインのトリガーを実装

• アプローチ: 各サービスに対してパスフィルター付きの CI および PR トリガーを設定します。長時間実行される統合テストのために夜間スケジュールを追加します。パッケージングパイプラインを連鎖させ、パイプラインリソースを介してデプロイメントパイプラインをトリガーします。
• 論理的根拠: コード変更に対する迅速なフィードバック、定期的なヘルスチェック、既知の成果物の決定論的なプロモーションを保証します。

3. エージェントプールを使用した混合エージェント戦略の採用

• アプローチ: ビルドジョブは弾力性のために Microsoft-hosted の ubuntu-latest で実行します。デプロイジョブは、内部クラスターにアクセスできる Starbucks VNet 内のセルフホストエージェントで実行します。環境ごとにプールでエージェントを分離し、プールの使用を制限します。
• 論理的根拠: ホストエージェントは CI のメンテナンスを最小化し、セルフホストエージェントは CD のための安全なネットワーク到達性を提供します。プールのスコープ設定により、最小権限が強制されます。

4. 変数グループとランタイムパラメータによる変数管理

• アプローチ: 共有される非シークレット値を変数グループに配置し、リンクされた変数グループを介して Azure Key Vault からシークレットを取得し、非本番ブランチでパフォーマンスゲートを切り替えるためのブール値パラメータ enablePerfGate を公開します。
• 論理的根拠: 一元化された構成は重複を避け、Key Vault はシークレットを保護し、パラメータはコンパイル時の構造選択を駆動します。

5. 環境、承認、チェックを含むデプロイメントジョブの定義

• アプローチ: dev、staging、prod を環境としてモデル化します。staging と prod に承認を追加します。チェックを追加します：prod のための営業時間、およびステージングのレイテンシがベースラインを超えた場合にプロモーションをブロックする Azure Monitor クエリチェック。
• 論理的根拠: 環境レベルの承認とチェックは、制御されたプロモーションを実装し、本番デプロイメント前に SLO を強制します。

6. カナリー戦略、次にブルーグリーン戦略の適用

• アプローチ: ステージングでカナリー戦略を使用して増分を検証します。本番環境では、並列のスロット/環境にデプロイし、即時ロールバック機能を持つトラフィックスワップ（blue-green/red-black）を実行します。
• 論理的根拠: カナリーは検証中のリスクを低減し、ブルーグリーンはデプロイ時間を最小化し、最速のロールバックを提供します。

7. パイプライン成果物とキャッシュによる最適化

• アプローチ: ビルド出力をパイプライン成果物として発行し、デプロイメントステージでそれらを使用します。依存関係の復元をキャッシュするには、ロックファイルでハッシュ化されたキーを使用し、フォールバック用に restoreKeys を設定します。
• 論理的根拠: 成果物は不変で追跡可能なプロモーションを保証し、キャッシュは正確性を犠牲にすることなくビルド時間を大幅に削減します。

8. OIDC とスコープ付き権限によるサービス接続の保護

• アプローチ: workload identity federation を使用して、リソースグループにスコープを限定した ARM サービス接続を作成します。サービス接続の承認とチェックを要求し、「Grant access to all pipelines」を無効にします。
• 論理的根拠: 有効期間の長いシークレットを排除し、監査可能な承認により最小権限を強制します。

このエンドツーエンドの設計は、YAML-as-code によるガバナンスをエンタープライズグレードの承認やチェックと連携させ、キャッシュと成果物を通じてデリバリーを加速し、OIDC とスコープ付きサービス接続を介してセキュリティを強化します。

← ソースコントロールとリポジトリ管理 · すべてのドメイン · コードとしてのインフラストラクチャと構成管理 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Microsoftを閲覧 →