Azure Pipelines

解決する課題

• コードをプッシュするたびに手作業でビルド・テストするのをやめたい（自動化したい）
• ビルド環境を自分で管理せず、すぐに使えるクリーンな実行環境がほしい
• テストに通ったものだけを自動でステージング・本番へデプロイしたい
• 本番反映の前に承認や検査ゲートを挟んで安全に制御したい
• パイプライン定義を**コードとしてリポジトリで管理（バージョン管理）**したい

主要概念と用語

• パイプライン（Pipeline）: ビルド・テスト・デプロイの一連の自動化を定義したもの。通常はリポジトリ内の YAML ファイルで記述する
• ステージ（Stage）: パイプラインを区切る大きな論理単位（例: ビルド、テスト、デプロイ）。順序や依存関係を指定できる
• ジョブ（Job）: 1 つのエージェント上でまとめて実行される処理の単位。ステージは複数のジョブを持てる
• ステップ（Step）/ タスク（Task）: ジョブ内の最小の実行単位。タスクはビルドやテストなどの再利用可能な処理部品
• エージェント（Agent）: 実際に処理を実行する計算環境。Microsoft が用意する「Microsoft ホステッド」と、自分で用意する「セルフホステッド」がある
• エージェントプール（Agent Pool）: エージェントをまとめた割り当て先のグループ
• トリガー（Trigger）: パイプラインを起動するきっかけ。コードのプッシュ、プルリクエスト、スケジュール（cron）など
• 環境（Environment）: デプロイ先を表す論理的な対象。承認や検査などのデプロイ制御を紐づけられる
• アーティファクト（Artifact）: ビルドで生成された成果物。後続のステージやデプロイで受け渡す
• 承認とチェック（Approvals and checks）: 環境への反映前に人手の承認や自動検査を必須にするゲート機能

仕様・制限・クォータ

• マルチプラットフォーム対応: Linux、Windows、macOS のエージェントが使え、多くの言語・フレームワークをビルドできる
• YAML パイプラインが基本: 定義をリポジトリ内のファイルとして管理し、コードと一緒にレビュー・バージョン管理できる（コードとしてのパイプライン）
• 並列実行（Parallel jobs）: 同時に動かせるジョブ数は契約・購入した並列数に依存する。無料枠は限られ、必要に応じて追加購入する
• 実行時間の上限: 1 ジョブあたりの最大実行時間には上限があり、Microsoft ホステッドとセルフホステッドで条件が異なる。長時間ジョブはセルフホステッドが向く
• Microsoft ホステッドエージェント: 毎回クリーンな仮想環境が割り当てられ、ビルドのたびに使い捨てられる。あらかじめ多くのツールがプリインストールされている
• 具体的な無料並列数・実行時間・ストレージ量などは変動するため、最新の公式情報で確認する

内部の仕組み

Azure Pipelines は、リポジトリにある YAML 定義を読み取り、トリガー（プッシュやプルリクエストなど）をきっかけに実行（Run）を作成します。実行はステージ・ジョブ・ステップへと展開され、各ジョブがエージェントプールから割り当てられたエージェント上で順に処理されます。

Microsoft ホステッドエージェントでは、ジョブごとに新しいクリーンな仮想マシンが用意され、処理が終わると破棄されます。環境がビルド間で汚れないため再現性が高い一方、独自ソフトの常駐やキャッシュの持ち越しはしにくくなります。セルフホステッドエージェントは自分の VM やコンテナにエージェントを常駐させ、専用ツールや社内ネットワークへの到達、ビルドキャッシュの活用ができます。

ビルドで生成したアーティファクトは実行内に保存され、後続のステージやデプロイジョブへ受け渡されます。デプロイ先は環境として表現し、環境に承認とチェックを設定しておくと、本番反映の直前に人手の承認や自動検査ゲートを通過しないと先へ進めないように制御できます。

設計パターン / ベストプラクティス

• パイプラインは YAML でコード管理し、変更をプルリクエストでレビューしてから反映する
• ステージを分割（ビルド／テスト／デプロイ）し、テストに通った成果物だけを後続へ流す
• 本番環境には承認とチェックを設定し、無人デプロイでも人手のゲートを通す
• 秘密情報はパイプラインに直書きせず、変数グループや Key Vault 連携、サービス接続で安全に渡す
• テンプレート化して共通処理を再利用し、複数リポジトリ・複数チームで定義の重複を避ける
• キャッシュ（依存パッケージなど）を活用してビルド時間を短縮する

運用・監視

• 各実行のログとステージ・ジョブの状態はパイプラインの実行画面で確認でき、失敗箇所を追跡できる
• テスト結果やコードカバレッジを取り込み、実行ごとに品質の傾向を可視化する
• 失敗時は通知（メールや Teams、サービスフック）で関係者に知らせる
• ビルドが遅い・詰まるときは並列数の不足やエージェントプールの空き、依存解決やテストのボトルネックを確認する
• セルフホステッドエージェントはOS パッチやツール更新、ディスク容量を自分で運用する必要がある

コスト

セキュリティ

• **サービス接続（Service connection）**で外部リソース（Azure、レジストリ、クラウド）への資格情報を一元管理し、パイプラインに平文で埋め込まない
• Azure への接続は**ワークロード ID フェデレーション（OIDC）**を使い、長期保管のシークレットを持たないパスワードレス構成にできる（AWS の IAM ロール引き受けに近い発想）
• 秘密変数や Key Vault 連携で機密値を保護し、ログに出力されないよう扱う
• 承認とチェックで本番デプロイに人手の関門を設け、誤った反映を防ぐ
• パイプラインやサービス接続へのアクセス権は最小権限で付与し、誰がどの環境にデプロイできるかを制御する

Well-Architected の観点

• オペレーショナルエクセレンス: パイプラインを YAML でコード管理し、ビルド・テスト・デプロイを自動化することで、手作業による反映ミスを減らし、変更を素早く安全に届けられる
• セキュリティ: サービス接続とワークロード ID フェデレーション、承認ゲートで、資格情報の保護とデプロイ制御を仕組み化する
• 信頼性: テストに通った成果物だけを段階的にデプロイし、承認とチェックで本番反映の品質を担保する
• コスト最適化: 必要な並列数だけを購入し、ピークに合わせて枠を調整することでムダを抑える

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# Azure DevOps CLI 拡張を追加し、組織・プロジェクトの既定を設定
az extension add --name azure-devops
az devops configure --defaults \
  organization=https://dev.azure.com/myorg \
  project=demo-project

# リポジトリ内の azure-pipelines.yml を指定してパイプラインを作成
az pipelines create \
  --name demo-ci \
  --repository my-repo \
  --repository-type tfsgit \
  --branch main \
  --yml-path azure-pipelines.yml

# パイプラインを手動で実行
az pipelines run --name demo-ci --branch main

# 実行一覧を確認して状態を追跡
az pipelines runs list --output table