Azure Repos

解決する課題

• ソースコードをプライベートな Git リポジトリで安全にホスティングしたい（公開したくない）
• 直接 main へのプッシュを禁止し、プルリクエストとレビューを経たコードだけを取り込みたい
• 取り込み前にビルドやテストの成功を必須にして品質を担保したい
• 誰がどのブランチに変更できるかをきめ細かいアクセス権で制御したい
• コードの変更を作業項目（Issue やバグ）と紐づけ、追跡可能にしたい

主要概念と用語

• リポジトリ（Repository）: コードとその変更履歴を保管する単位。1 つのプロジェクト内に複数のリポジトリを持てる
• Git: 分散型のバージョン管理システム。Azure Repos が標準で提供する形式で、各開発者が完全な履歴を手元に持てる
• TFVC（Team Foundation Version Control）: 集中型のバージョン管理方式。Azure Repos は Git に加えてこの方式もサポートするが、新規は Git が推奨される
• ブランチ（Branch）: 並行して作業を進めるための分岐。main（既定ブランチ）から派生して作業し、後で統合する
• プルリクエスト（Pull Request, PR）: あるブランチの変更を別のブランチへ取り込む提案。レビュー・コメント・承認・マージをここで行う
• ブランチポリシー（Branch Policy）: 特定ブランチへの取り込み条件。必須レビュー数、ビルド検証、作業項目リンク必須などを強制できる
• マージ（Merge）: PR の変更を対象ブランチへ統合する操作。マージ方式（マージコミット、スカッシュ、リベースなど）を選べる
• 作業項目リンク（Work Item Link）: コミットや PR を Azure Boards の作業項目に関連付ける仕組み。変更の背景を追跡できる
• フォーク（Fork）: リポジトリを複製して独立に作業し、後で PR で本流へ提案する開発スタイル

仕様・制限・クォータ

• 無制限のプライベートリポジトリ: 1 つの組織・プロジェクト内に多数のプライベート Git リポジトリを作成できる
• Git と TFVC の両対応: 分散型の Git と集中型の TFVC を選べる。新規プロジェクトでは Git が標準的な選択肢
• 大容量ファイルの扱い: 巨大なバイナリは Git LFS（Large File Storage）で管理する。1 ファイルやプッシュのサイズには上限がある
• きめ細かいアクセス制御: 組織・プロジェクト・リポジトリ・ブランチの各レベルで権限を設定できる
• 統合: Azure Pipelines（CI/CD）、Azure Boards（作業項目）、Azure Artifacts と同じ Azure DevOps 内で連携する
• リポジトリ容量やファイルサイズの具体的な上限値は変動するため、最新の公式情報で確認する

内部の仕組み

Azure Repos は、Azure DevOps のプロジェクト配下にホストされるマネージドな Git サーバーです。開発者は手元でクローン・コミットし、リモートへプッシュします。プッシュやプルは認証（Microsoft Entra ID 連携、個人用アクセストークン、SSH キーなど）を経て行われ、サーバー側で履歴が一元管理されます。

変更を main などの保護ブランチへ取り込むときは、直接プッシュではなくプルリクエストを経由します。PR にはレビュー担当者がコメント・承認を付け、ブランチポリシーが満たされて初めてマージできます。ポリシーには「最低 N 人のレビュー承認」「ビルド検証（CI）の成功」「作業項目のリンク必須」「コメント解決必須」などがあり、これらが品質ゲートとして機能します。

ビルド検証は Azure Pipelines と連携し、PR を作成・更新するたびに自動でパイプラインを走らせ、テストが通ったものだけをマージ可能にできます。コミットや PR は Azure Boards の作業項目と双方向にリンクし、「どの変更がどの要件・バグに対応したか」を追跡できます。

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

• main を保護し、直接プッシュを禁止して必ずプルリクエスト経由で取り込む
• ブランチポリシーで必須レビューとビルド検証を設定し、レビューと CI を通過した変更だけをマージする
• 小さく頻繁な PR にして、レビューしやすく取り込みやすい変更単位を保つ
• 作業項目リンクを必須にして、変更の背景（要件・バグ）を追跡可能にする
• 巨大なバイナリは Git LFS で管理し、リポジトリの肥大化を避ける
• ブランチ戦略（trunk-based や GitHub Flow など）を統一し、チーム内で運用を揃える

運用・監視

• 各リポジトリのコミット履歴・ブランチ・PR の状態は Web UI で確認でき、変更を追跡できる
• PR のアクティビティ（承認、コメント、ポリシー充足状況）を一覧で把握し、滞留している PR を見つける
• **通知（メールやサービスフック）**で PR の作成・更新・承認待ちを関係者に知らせる
• ポリシー違反でマージできないときは、未充足のポリシー項目（レビュー不足、ビルド失敗など）を確認する
• 大きくなったリポジトリは、不要な大容量ファイルの混入や履歴の肥大化を点検する

コスト

セキュリティ

• Microsoft Entra ID と連携したユーザー認証で、組織のアイデンティティ基盤に統合できる
• 個人用アクセストークン（PAT）や SSH キーでアクセスし、PAT は有効期限とスコープを最小限に絞る
• ブランチレベルの権限で、誰がどのブランチへ変更・マージできるかを最小権限で制御する
• 必須レビューとビルド検証ポリシーにより、未レビューや未検証のコードが取り込まれるのを防ぐ
• シークレットのコミットを防止する。資格情報や鍵をリポジトリに直接コミットしないよう運用とスキャンで対策する

関連サービス・比較

ハンズオン / CLI例

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

# 新しい Git リポジトリを作成
az repos create --name my-repo

# リポジトリ一覧を確認
az repos list --output table

# main ブランチに必須レビュー数のポリシーを設定（最低 2 人の承認を必須化）
az repos policy approver-count create \
  --repository-id <repository-id> \
  --branch main \
  --blocking true \
  --enabled true \
  --minimum-approver-count 2 \
  --creator-vote-counts false \
  --reset-on-source-push true