Azure DevOps

解決する課題

ソフトウェア開発では、課題管理ツール・ソース管理・ビルド/デプロイ・成果物リポジトリ・テスト管理がばらばらに存在し、ツール間の連携や権限管理が分断されがちです。Azure DevOps は、これらを1つのプラットフォームと統一の ID/権限モデルで束ね、計画から本番配信までを一気通貫で扱えるようにします。

• 課題・作業項目とコード変更・デプロイをひもづけてトレースしたい
• ソース管理から CI/CD までを同じ場所・同じ権限体系で回したい
• ライブラリやコンテナ イメージを社内向け成果物フィードとして共有したい
• ツールを個別に契約・統合する手間を省き、運用を一元化したい

主要概念と用語

• 組織（Organization）/ プロジェクト（Project）: 利用の最上位コンテナが組織で、その中に作業を区切るプロジェクトを作る。プロジェクトが Boards・Repos・Pipelines 等の境界になる
• Azure Boards: 作業項目（エピック・機能・ユーザー ストーリー・バグ・タスク）を管理する計画ツール。スクラム/かんばん/基本などのプロセスを選べる（AWS の CodeCatalyst の Issues 相当）
• Azure Repos: Git と TFVC（集中型）をホストするソース管理。プル リクエスト、ブランチ ポリシー、コード レビューを備える（AWS の CodeCommit 相当）
• Azure Pipelines: ビルドとリリースを担う CI/CD。YAML パイプラインが推奨で、Microsoft ホステッド エージェントと自前のセルフホステッド エージェントを選べる（AWS の CodeBuild と CodePipeline を合わせた相当）
• Azure Artifacts: NuGet・npm・Maven・Python・ユニバーサル パッケージを置く成果物フィード。上流ソースのプロキシ/キャッシュもできる（AWS の CodeArtifact 相当）
• Azure Test Plans: 手動テスト・探索的テストの管理と実行を支援するブラウザー ベースのツール
• エージェント / エージェント プール: パイプラインのジョブを実行する実体と、その集合。Microsoft ホステッドは使い捨て、セルフホステッドは自前環境で常設できる
• サービス接続（Service Connection）: Azure サブスクリプションや外部レジストリへ安全に接続するための資格情報の抽象化

仕様・制限・クォータ

• 2つの提供形態: クラウド版の Azure DevOps Services と、自社で運用するオンプレ版の Azure DevOps Server（旧 TFS）がある。本稿は主にクラウド版を扱う
• ソース管理: Git（分散）と TFVC（集中型）の両方をサポートするが、新規プロジェクトは原則 Git を選ぶ
• パイプラインの並列実行: 同時に実行できるジョブ数は**並列ジョブ（parallel jobs）**の数で決まる。無償枠を超える分は購入が必要で、Microsoft ホステッドとセルフホステッドで枠が分かれる
• エージェントの実行時間: Microsoft ホステッド エージェントには 1 ジョブあたりの実行時間上限があり、長時間ジョブやキャッシュ常設が必要な場合はセルフホステッドを使う
• API/サービス フック: REST API と Webhook（サービス フック）で外部システムと連携できる
• 具体的な無償枠の人数・並列数・容量・時間の上限値は時期やプランで変わり得るため、設計時は最新の公式ドキュメントで確認する

内部の仕組み

Azure DevOps はマネージドな SaaS として提供され、組織 → プロジェクトという階層の中に5つのサービス（Boards・Repos・Pipelines・Artifacts・Test Plans）が同居します。ユーザーの認証は Microsoft Entra ID と連携でき、権限はプロジェクト単位のグループとアクセス レベルで制御されます。

CI/CD の中心である Azure Pipelines は、リポジトリへの push やプル リクエスト、スケジュールなどをトリガーにして YAML で定義したパイプラインを起動します。ジョブはエージェント プールから割り当てられたエージェント上で実行され、Microsoft ホステッドの場合は毎回クリーンな使い捨て環境が用意されます。ビルドで生成した成果物は Azure Artifacts のフィードへ発行したり、後続のデプロイ ステージへ受け渡したりできます。Azure サブスクリプションなど外部リソースへの接続は、資格情報を直接書かずサービス接続を介して行います。

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

• 作業項目とコードの連結: コミットやプル リクエストに作業項目 ID をひもづけ、計画から変更・デプロイまでをトレースできるようにする
• ブランチ ポリシー: main などの保護ブランチに、必須レビュー数・ビルド成功・リンクされた作業項目を必須にして品質ゲートを敷く
• YAML パイプラインのテンプレート化: 共通ステップをテンプレートに切り出し、複数リポジトリ/プロジェクトで再利用する
• 環境と承認: デプロイ先を「環境（Environment）」として定義し、本番には手動承認やチェックを挟んでリリースを統制する
• 成果物の一元管理: 社内ライブラリは Azure Artifacts のフィードに集約し、上流（公開レジストリ）はプロキシ経由でキャッシュして安定供給する
• セルフホステッド エージェントの使い分け: プライベート ネットワーク内のリソースへ接続したい、専用ツールや常設キャッシュが要る場合はセルフホステッドを使う

運用・監視

• パイプラインの可視化: 実行履歴・成功率・所要時間をダッシュボードや分析ビューで把握し、遅いステージやフレーキーなテストを特定する
• エージェントの健全性: セルフホステッドはエージェントのオフライン・ディスク逼迫・ツール バージョン差異が失敗要因になりやすい。プールの状態を定期確認する
• 並列ジョブの枯渇: ビルドがキューで待たされる場合は並列ジョブ数の不足が典型。枠の購入やジョブの最適化を検討する
• 監査ログ: 組織レベルの監査ストリームで、権限変更やパイプライン定義の変更といった操作の証跡を残せる
• 通知: サービス フックや通知設定で、ビルド失敗やプル リクエストのレビュー依頼を Teams 等へ連携する

コスト

課金は主にユーザーのアクセス レベル（基本/関係者など）と、Azure Pipelines の並列ジョブ、Azure Artifacts のストレージ容量で発生します。一定の無償枠が用意され、小規模なら無償で始められますが、並列ビルドを増やす・大量のパッケージを保持するとコストが伸びます。

セキュリティ

• 認証は Microsoft Entra ID と連携でき、条件付きアクセスや多要素認証を組織のポリシーで適用できる
• 権限は最小権限で。プロジェクト/リポジトリ/パイプライン単位のグループとアクセス レベルを使い分け、過剰な管理者権限を避ける
• シークレットを直書きしない: 接続情報はサービス接続やパイプラインのシークレット変数/変数グループ（Key Vault 連携可）で扱い、YAML やコードにハードコードしない
• PAT（個人用アクセス トークン）の管理: スコープと有効期限を絞り、可能なら PAT より Entra ID 認証やマネージド ID を優先する
• ブランチ保護とレビュー: 必須レビューと必須ビルドで、不正・未検証の変更が main に入るのを防ぐ
• エージェントの分離: セルフホステッド エージェントは信頼境界の内側に置き、外部 PR から任意コードが実行されないようトリガーやチェックを設計する

Well-Architected の観点

• 運用上の優秀性（operational）: 計画・ソース管理・CI/CD・成果物・テストを1つの基盤と統一の権限モデルに集約することで、ツール間連携の手間を減らし、変更をトレース可能・自動化可能・反復可能にします。YAML パイプラインによりデプロイ プロセス自体をコードとしてレビュー/履歴管理でき、手作業由来のばらつきを抑えられます。

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# Azure CLI に DevOps 拡張を追加
az extension add --name azure-devops

# 既定の組織とプロジェクトを設定（以降のコマンドで省略可能になる）
az devops configure --defaults \
  organization=https://dev.azure.com/your-org \
  project=demo-project

# 新しいプロジェクトを作成
az devops project create --name demo-project

# Git リポジトリを作成
az repos create --name demo-repo

# 作業項目（ユーザー ストーリー）を作成
az boards work-item create \
  --title "ログイン機能の実装" \
  --type "User Story"

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