Microsoft AZ-400: ソースコントロールとリポジトリ管理 — 学習ガイド

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

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

概要

現代の DevOps プラクティスは、予測可能で協調的なソース管理と、規律あるリポジトリ管理にかかっています。Azure Repos と GitHub は、バージョン管理、ポリシー適用、コラボレーション、セキュリティのための補完的な機能を提供します。ブランチ戦略、プルリクエストのワークフロー、アクセス許可、フック、大規模ファイルの取り扱い、移行パターン、セキュリティスキャン、バージョニングを習得することは、回復力のあるデリバリーパイプラインと監査性を確保するために不可欠です。目標は単にコードを保存することだけでなく、品質を犠牲にすることなくチームのスループットをスケールさせる、強制力のある自動化された管理システムを構築することです。

Azure Repos と GitHub におけるソース管理の基礎

Azure Repos は Git と Team Foundation Version Control (TFVC) をサポートしています。Git は分散型であり、ローカルコミット、容易なブランチ作成、および非中央集権的なワークフローを可能にします。TFVC は集中型で、サーバーサイドでのバージョン管理、ロック付きチェックアウト (任意) を特徴とし、非常に大きなバイナリアセットを持つレガシーソリューションや、集中型ワークフローに慣れたチームに適しています。新規開発ではデフォルトで Git を使用すべきです。TFVC は、増分的な変更管理と中央集権的な権限が最優先され、移行コストが法外に高い場合に依然として有効な選択肢です。

ブランチ戦略を意図的に選択する:

• トランクベース開発は、長期間存続する単一の main ブランチと、非常に短命なフィーチャーブランチ、そして継続的インテグレーションを推奨します。これにより、フローが加速し、マージの負債が減少し、強力なテスト自動化を持つ高頻度リリースチームにとって理想的です。
• GitFlow は、長期間存続する develop ブランチと main (リリース) ブランチを使用し、さらに feature、release、hotfix ブランチを利用します。これは、正式なリリーストレインやバックポートのニーズがある製品に適していますが、調整のオーバーヘッドが増加します。
• GitHub Flow は、単一の main ブランチ、短命なトピックブランチ、継続的デプロイメント、頻繁なリリースを特徴とする、よりシンプルなモデルです。継続的にシップするサービスに効果的です。

モノレポかマルチレポかは、主に組織およびツールに関する選択です:

• モノレポは多くのコンポーネントを1つのリポジトリに統合し、アトミックなサービス横断の変更、統一されたリファクタリング、共通ツールの利用を容易にします。履歴が大きくなるにつれて Git の操作に負荷がかかる可能性があります。緩和策には、スパースチェックアウト、部分クローン、ビルドとテストの範囲を限定するための CI パスフィルターなどがあります。
• マルチレポは、所有権、履歴、権限の境界を分離し、独立したバージョニングとリテンションを容易にします。リポジトリ間の調整や依存関係のドリフトが増加する可能性があり、サブモジュールや依存関係マネージャー、リリースオーケストレーションが重要になります。

所有権と変更のルーティングは、コード所有権の宣言によって改善されます。GitHub の CODEOWNERS ファイルは、パスを必須レビュー担当者に自動的にマッピングします。Azure Repos では、ブランチポリシーのパスベースの必須レビュー担当者 (および CODEOWNERS が有効な場合) を使用して、レビューをコンポーネントチームにルーティングします。所有権を補完するものとして、ブランチの命名規則、明確なコミットメッセージ (例: Conventional Commits)、一貫性を保つためのリポジトリテンプレートなどがあります。

ガバナンス: ポリシー、アクセス許可、プルリクエスト

Azure Repos のブランチポリシーは、品質ゲートを規定します:

• 必須レビュー担当者は、最小レビュー担当者数を強制し、特定の個人/グループやパスベースの自動レビュー担当者を含めることができます。マージ前に実質的なフィードバックが対処されるように、コメントの解決を要求します。
• ビルド検証は、マージ前に1つ以上の CI パイプラインが成功することを要求します。パスフィルターを使用して不要なビルドを避け、新しい更新に対する自動トリガーを設定します。セキュリティスキャンやパフォーマンステストのために、ステータスポリシーを介して外部チェックを統合します。
• マージ戦略は制約することができます: Merge (no fast-forward) はマージ履歴を記録します。Squash は変更を単一のコミットに凝縮し、履歴を直線的に保ちます。Rebase and fast-forward は、main 上でトピックブランチを書き換えて直線的な履歴を作成します。Rebase and merge はコミットをリプレイし、マージコミットなしで個別のコミットを保持します。戦略を監査のニーズや下流のツールと整合させます。
• 追加のチェックには、リンクされた作業項目の必須化、最小成功投票数、アクティブなコメントや保留中のレビュー担当者がいる場合のブロックなどがあります。

プルリクエストは統合に関する対話を調整します:

• ドラフト PR は作業中であることを示し、準備完了とマークされるまで完了をブロックします。ポリシーを早期にトリガーすることなく、早い段階でのフィードバックを奨励します。
• 自動完了は、すべてのポリシーが合格すると自動的にマージを行い、調整の遅延を減らし、フローを向上させます。
• ポリシーのバイパスは、緊急事態や自動化アカウントのために存在します。これを “Bypass policies when completing pull requests” 権限でロックダウンし、承認と変更管理を通じて監査します。
• PR テンプレートは、テストのエビデンス、リスクに関する注記、デプロイ手順、ロールバック計画といったコンテキストを標準化します。Azure Repos では、pull_request_template.md をリポジトリのルートまたは .azuredevops/ に配置します。セキュリティ、パフォーマンス、ドキュメントのチェックリストを提供します。

アクセス許可と保護されたブランチは最後の防衛線です:

• Azure DevOps の RBAC グループ (Project Administrators, Contributors, Readers) と、きめ細かいリポジトリ権限 (Create branch, Create tag, Contribute, Force push, Manage permissions, Bypass policies) を使用します。個人ではなく、グループに対して許可/拒否を設定することを推奨します。
• main ブランチと release ブランチを保護するために、Force push と Delete を拒否し、Contribute を PR マージのみに制限し、ビルドとレビューを要求するブランチポリシーを有効にします。変更を一時的に凍結するために「ロック」(Lock) を検討します。
• ブランチレベルの権限を使用して、機密性の高いブランチに対して PR を作成または完了できるユーザーを制限し、開発者とリリースマネージャーの職務を分離します。

自動化、フック、巨大ファイル、そしてセキュリティ

Gitフックは、エッジでの品質を強化します。

• Pre-commitフックは、開発者がコミットを記録する前に、ローカルでリンティング、フォーマッティング、シークレットチェック、単体テストを強制します。フックは高速かつ決定論的に保ちます。
• Pre-pushフックは、統合テストやポリシーチェックに失敗したコードのプッシュをブロックします。チーム共通のフックスクリプトをツール（例：JavaScript用のHusky）経由で提供し、オプトイン方式を文書化します。
• マネージドサービスにおけるサーバーサイドフックは異なります。GitHubはサーバーのwebhookと必須ステータスチェックをサポートしています。Azure DevOps Servicesではカスタムのサーバーサイドフックは許可されていませんが、ブランチポリシー、ビルド検証、サービスフック、外部システムからのステータスチェックをサポートしています。Azure DevOps Server（オンプレミス）では、サーバーフックが可能です。

Large File Storage (Git LFS)は、Gitのオブジェクトデータベースの外部に大きなバイナリを保存し、リポジトリのパフォーマンスを維持します。

• git lfs track "*.psd" のようにパターンを指定するか、特定のバイナリファイルタイプを追跡します。すべてのコントリビューターが一貫してLFSを適用できるように、.gitattributesファイルをコミットします。
• git lfs migrate import をパスフィルター付きで実行し、履歴を移行して大きなバイナリをポインターに書き換えます。チームと調整してプッシュを一時停止し、注意深くフォースプッシュしてクローンを更新します。
• 不要なsmudging（ポインターから実ファイルへの置換）を避けることで、帯域幅を管理します。GIT_LFS_SKIP_SMUDGE=1 を使用し、git lfs fetch/pull を選択的に実行します。CIでLFSをキャッシュし、Git内に存在する必要のないバイナリについてはアーティファクトリポジトリを検討します。

セキュリティ保証は、シフトレフトかつポリシーベースであるべきです。

• GitHub Advanced Security (GHAS)は、シークレットスキャン（プッシュ保護を含む）、CodeQLによるコードスキャン、依存関係レビューを提供し、漏洩した認証情報、コードの脆弱性、サプライチェーンリスクを検出します。PRの必須チェックとして強制します。Azure Reposの場合、Advanced Security for Azure DevOpsを使用して、同様のシークレットスキャン、CodeQLによるSAST、依存関係のインサイトを実現します。
• シークレットスキャンは、信頼度の高いシークレットを含むプッシュをブロックし、セキュリティ担当者にアラートを送信するように設定する必要があります。組織固有のパターンに対応するカスタム検出機能をサポートします。
• CodeQLのコードスキャンは、pull_requestとscheduleトリガーで実行し、SARIF形式の結果をステータスチェックとしてアップロードする必要があります。クエリパックを調整してノイズを減らし、クリティカルパスのカバレッジを強制します。
• 依存関係レビューは、PRレビュー中にバージョンの変更や既知の勧告を表面化させます。これを修正SLAやライセンスガバナンスに活用します。

移行、バージョニング、およびリリース管理

TFVCからGitへの移行には、リスク許容度に応じた戦略とツールが必要です。

• 詳細な履歴と作業項目リンクを含む完全な移行には、git-tfsを使用してTFVCのパスをGitにクローンし、変更セットを保持してユーザーをマッピングします。Gitリポジトリを扱いやすく保つために、アプリケーションまたはブランチごとに分割します。移行中または移行後に、LFSを使用して大きなバイナリをクリーンアップします。
• 現在の状態のみを軽量に移行する場合は、Azure DevOpsのインポートツールを使用して、TFVC（または他のGitホスト）から新しいGitリポジトリを作成し、オプションで履歴を制限します。これにより、期間とリスクは削減されますが、詳細な履歴の粒度は失われます。
• タグ/ラベルを移行し、TFVCブランチをGitブランチにマッピングし、監査用に読み取り専用のTFVCミラーを保持することで、トレーサビリティを維持します。パイロットで検証し、切り替え中はソースを凍結し、検証マトリックス（ビルド、テスト、デプロイ）を実行します。

明確性と自動化のためにセマンティックバージョニングを採用します。

• SemVer 2.0.0を使用します: MAJOR.MINOR.PATCHに、オプションのプレリリース（例: -rc.1）とビルドメタデータ（+build.45）を付けます。注釈付きタグ（git tag -a v1.4.2 -m “Release 1.4.2”）でリリースにタグを付け、監査のためにタグに署名します。
• CI/CDでバージョンの自動インクリメントを行います。
  • Conventional Commitsとリリースツール（例: GitVersion、semantic-release）を使用してコミットからバージョンを決定し、コミットのタイプとスコープに基づいて次のバージョンを計算します。
  • ビルド番号とパッケージバージョンを自動的に更新し、バージョンのずれやタグの競合が発生した場合はビルドを失敗させます。
• バージョニングをブランチ戦略と連携させます。
  • トランクベース: mainは常にリリース可能。mainからリリースタグを作成し、安定化のためだけに短期的なリリースブランチを使用します。
  • GitFlow: release/* ブランチは凍結されたマイナーバージョンを持ちます。緊急パッチのためにmainからhotfix/* ブランチを作成し、developとmainの両方にマージバックして、マージ完了時にタグを付けます。
  • GitHub Flow: デプロイ時にmainにタグを付けます。カナリアリリースにはプレリリースタグを使用します。

リポジトリポリシーとリリース自動化を統合します。リリースパイプラインでのビルド成功を必須とし、コミットから生成された更新済みチェンジログがないマージをブロックし、規制された環境では署名付きのコミット/タグを要求します。

実践的な問題シナリオ

Starbucksは、TFVCで管理されている複数のレガシーアプリケーションをAzure Repos Gitに統合し、サービスとモバイルアプリの両方に対して、統一されたガバナンス、セキュリティスキャン、スケーラブルなワークフローを確立する必要があります。

1. ブランチ戦略とリポジトリトポロジの選択

• アクション: 共有ライブラリ用のモノレポと、独立してリリースされるサービス用のいくつかの焦点を絞ったサービスリポジトリで、トランクベース開発を採用します。開発者のオンボーディングスクリプトでモノレポのスパースチェックアウトを有効にします。
• 理由: トランクベースはマージの負債を減らし、統合を加速します。モノレポは共有コードを一元化し、アトミックなリファクタリングを可能にします。一方、スパースチェックアウトは、サブセットのみを扱うチームにとって、完全な履歴と作業ツリーのオーバーヘッドを回避します。

2. 価値のある履歴を保持しつつ、TFVCプロジェクトをGitに移行

• アクション: git-tfsを使用して、主要なWebおよびモバイルのコードベースを完全な履歴とともに移行し、移行中に大きなアセットパスをGit LFSにマッピングします。小規模なユーティリティについては、Azure DevOpsのインポートツールを使用して現在の状態のみを移行します。
• 理由: git-tfsは主要なアプリケーションの重要なトレーサビリティを保持します。インポートツールを選択的に使用することで、低リスクの移行を加速し、プロジェクト期間を短縮します。

3. 保護ブランチとブランチポリシーの確立

• アクション: mainとrelease/*を強制プッシュ/削除を拒否する設定で保護します。2人のレビュー担当者、すべてのコメントの解決、作業項目のリンク、パスフィルター付きのビルド検証を必須とします。マージは、サービスリポジトリではSquashに、モノレポでは線形履歴を維持するためにRebase and fast-forwardに制約します。「Bypass policies」は、小規模なリリースエンジニアリンググループを除き無効にします。
• 理由: Policy-as-codeは品質ゲートと監査可能性を強化します。マージ戦略はチームの好みを反映します。Squashはサービスのリバートとチェリーピックを簡素化し、モノレポの線形履歴はblameとbisect操作を高速化します。

4. プルリクエストプラクティスの標準化

• アクション: .azuredevops/配下にpull_request_template.mdを追加し、リスク、テストエビデンス、パフォーマンスへの影響、ロールバックのセクションを設けます。早期のドラフトPRを奨励し、すべてのPRでAuto-completeを有効にします。パスベースの必須レビュー担当者を設定してコードオーナーシップを模倣し、GitHubでホストされているリポジトリにはCODEOWNERSを追加します。
• 理由: テンプレートはレビュー品質の底上げをします。ドラフトPRは早期のコラボレーションを促進します。Auto-completeはアイドル時間をなくします。オーナーシップルーティングは、適切なレビュー担当者を適切な差分に割り当てます。

5. フックとCIゲートの実装

• アクション: リポジトリのツールを介してpre-commit/pre-pushフックを配布し、リンティング、シークレットチェック、ユニットテストを強制します。実行は高速に保ちます。Azure Pipelinesのビルド検証を正規の強制手段として使用し、セキュリティスキャナーからのステータスチェックを追加します。カスタムのサーバーサイドフックは避け、サービスフックを使用して外部システムに通知します。
• 理由: ローカルフックはコラボレーションを妨げることなく問題を早期に発見します。Azure DevOpsでのサーバーサイドの強制は、信頼性と監査のためにブランチポリシーとステータスチェックで実現するのが最善です。

6. Git LFSによる大規模アセットの管理

• アクション: git lfs trackでバイナリパターン（画像、デザインアセット、テストメディア）を追跡します。git lfs migrate importでレガシーバイナリを移行します。CIでGIT_LFS_SKIP_SMUDGE=1を設定し、帯域幅を削減するために選択的にフェッチするように構成します。ビルドエージェントでLFSアーティファクトをキャッシュします。
• 理由: 再現性のあるビルドを維持しつつ、リポジトリを高速に保ち、過剰なネットワーク使用を回避します。

7. Advanced Securityの統合

• アクション: GitHubリポジトリでGitHub Advanced Securityを、Azure ReposでAdvanced Security for Azure DevOpsを有効にします。プッシュ保護付きのシークレットスキャンをオンにし、PRおよび夜間にCodeQLを実行し、依存関係レビューチェックを有効にします。重大度の高い検出結果がある場合はPRの完了をブロックします。
• 理由: セキュリティを左にシフトさせ、認証情報の漏洩や悪用可能なパターンがmainに入るのを防ぎ、レビュー中に実用的な洞察を提供します。

8. セマンティックバージョニングとタグ付けの自動化

• アクション: Azure PipelinesでGitVersionを使用して、ブランチとコミット履歴からSemVerを計算します。リリースパイプラインで注釈付きタグに署名してプッシュします。Conventional Commitsからリリースノートを生成します。release/*ブランチは安定化のためだけに使用し、タグ付けされたmainからhotfixを作成します。
• 理由: 決定論的で自動化されたバージョンは、トレーサビリティとデプロイの再現性を向上させ、署名付きタグはコンプライアンスをサポートします。

この一連の手順は、移行リスクを低減し、一貫した品質とセキュリティを強制し、デリバリーを合理化します。これにより、リポジトリ管理をスケーラブルなDevOpsオペレーションと正確に連携させることができます。

すべてのドメイン · Azure Pipelines による CI →

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

Microsoftを閲覧 →