ブランチ ポリシーの設定と管理

Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022

ブランチ ポリシーを使用して、変更のマージ前にプル要求、レビュー担当者、ビルド、およびその他のチェックを要求することで、重要な ブランチ を保護します。 この記事では、Azure DevOps Web ポータルと Azure DevOps CLI でブランチ ポリシーを構成および管理する方法について説明します。 使用可能なブランチ ポリシーとブランチ ガイダンスの概要については、「 ブランチとブランチ ポリシーについて」を参照してください。

ブランチ ポリシー、リポジトリのアクセス制御、コミット署名、および実際の実装シナリオに関する包括的なセキュリティ ガイドについては、 リポジトリとプル要求のセキュリティ保護に関するページを参照してください。

必要なポリシーが構成されたブランチを削除することはできません。また、すべての変更がプル要求 (PR) を通過する必要があります。

ヒント

この記事の後半でAI を使用してこのタスクに役立てる方法をご説明します。または、Azure DevOps MCP Server で AI サポートを有効にする方法を参照して作業を開始できます。

前提条件

Requirement 詳細情報
Permissions Project Administrators セキュリティ グループのメンバーであるか、リポジトリ レベルの編集ポリシーのアクセス許可を持っている。 詳細については、「Git リポジトリのアクセス許可を設定する」を参照してください。
Azure DevOps CLI のセットアップ (省略可能) Azure DevOps CLI の az repos policy コマンドを使用するには、Azure DevOps CLI の使用を開始する を完了してください。
CLI を対象とするリポジトリ (省略可能) CLI でポリシーを作成または更新する前に、 az repos listを実行してリポジトリ ID を特定します。 --orgと--projectの繰り返しを回避するには、az devops configure --defaultsで既定値を設定します。
ポリシーの依存関係 ビルド検証を構成する前に、ビルド パイプラインを準備しておく必要があります。 状態チェックを構成する前に、外部サービスまたは組み込みの統合が pull request 状態を既にポストできることを確認します。
AI アシスタンスのセットアップ (省略可能) Azure DevOps MCP Server で AI アシスタンスを使用するには、Azure DevOps サービスを使用し、AI アシスタントでエージェント モードを有効にして、20.0 以降Node.js インストールします。 詳細については、「Azure DevOps MCP Server で AI サポートを有効にする」を参照してください。
Requirement 詳細情報
Permissions Project Administrators セキュリティ グループのメンバーであるか、リポジトリ レベルの編集ポリシーのアクセス許可を持っている。 詳細については、「Git リポジトリのアクセス許可を設定する」を参照してください。

ブランチ ポリシー設定を開く

Web ポータルでブランチ ポリシー設定を開くには:

  1. [Repos>Branches] を選択します。
  2. 管理したいブランチを見つけてください。
  3. ブランチの横にある [その他のオプション ] アイコンを選択し、[ ブランチ ポリシー] を選択します。

[ブランチ] メニュー項目を示すスクリーンショット。

ブランチ ポリシー設定は、Project設定>Repository>Policies>Branch Policies><Branch 名>から開くこともできます。

ポリシーがあるブランチには、ポリシー アイコンが表示されます。 アイコンを選択して、ブランチのポリシー設定に直接移動します。

一覧を参照するか、[ブランチ名の検索] ボックスで ブランチを検索 できます。

コンテキスト メニューからブランチ ポリシーを開く様子を示すスクリーンショット。

ブランチの設定ページでポリシーを構成します。 次のセクションを使用して、各ポリシーを有効にするか、既存のポリシーを更新します。

レビュー担当者の最小ポリシーを設定する

pull request が完了する前に、レビュー担当者の最小数からの承認を要求します。

ポリシーを設定するには、[ブランチ ポリシー] で、[レビュー担当者の最少数が必要です] を [オン] に設定します。 必要なレビュー担当者数を入力し、次のいずれかのオプションを選択します。

コード レビューを要求するポリシーを有効にすることを示すスクリーンショット。

  • PR の作成者がその承認に投票できるようにするには、[要求者が自分の変更を承認することを許可する] を選択します。 それ以外の場合、作成者は引き続き PR に対して 承認 に投票できますが、その投票はレビュー担当者の最小数にはカウントされません。

  • 職務の分離を適用するには、[最新のプッシュ元が自分の変更を承認することを禁止する] を選択します。 既定では、ソース ブランチに対するプッシュ アクセス許可を持つすべてのユーザーは、コミットを追加し、PR 承認に投票できます。 このオプションを選択すると、通常は自身の変更を承認できる場合でも、最新のプッシュ元の投票はカウントされません。

  • 一部のレビュー担当者が承認に反対の投票をする場合であっても PR 完了を可能にするには、[一部のレビュー担当者が待機中または拒否と投票した場合でも完了を許可する] を選択します。 最少数のレビュー担当者が、引き続き承認する必要があります。

  • [新しい変更がプッシュされたとき] で、以下を選択します。
    • 最後のソース ブランチの変更に少なくとも 1 つの承認投票を要求するには、[各イテレーションで少なくとも 1 つの承認を必要とする] を選択します。 ユーザーの承認は、そのユーザーによってプッシュされた過去の未承認のイテレーションに対してカウントされません。 そのため、最後のイテレーションに対する追加の承認は、別のユーザーが行う必要があります。 Azure DevOps Server 2022.1 以降で、[各イテレーションで少なくとも 1 つの承認を必要とする] をご利用になれます。
    • 最後のソース ブランチの変更に少なくとも 1 つの承認投票を要求するには、[最後のイテレーションで少なくとも 1 つの承認が必要です] を選択します。
    • ソース ブランチが変更されるたびに、すべての承認投票を削除するが、拒否または待機の投票は保持するには、[すべての承認投票をリセット (投票は拒否または待機にはリセットされません)] を選択します。
    • 承認、拒否、待機の投票を含めて、ソース ブランチが変更されるたびにすべてのレビュー担当者の投票を削除するには、[すべてのコード レビュー担当者の投票をリセットします] を選択します。

他のすべてのポリシーが合格した場合、作成者は、必要な数のレビュー担当者が承認したときに PR を完了できます。

リンクされた作業項目が必要

作業項目管理の追跡では、PR と作業項目との関連付けを要求できます。 作業項目をリンクすると、変更にさらなるコンテキストを提供し、更新が作業項目の追跡プロセスを確実に通過するようにします。

ポリシーを設定するには、[ブランチ ポリシー] で [リンクされた作業項目を確認します] を [オン] に設定します。 この設定では、PR がマージされるように作業項目を PR にリンクする必要があります。 設定を[省略可能]にして、リンクされた作業項目がない場合でも警告を表示しつつ、プルリクエストの完了を許可します。

pull request でリンクされた作業項目を必須にするスクリーンショット。

コメントの解決が必要です

[コメント解決の有無を確認する] ポリシーでは、すべての PR コメントが解決されているかどうかを確認します。

ブランチ のコメント解決 ポリシーを構成するには、[コメント解決の確認] を [オン] に 設定します。 次に、ポリシーを [必須] にするか、[省略可能] にするかを選択します。

コメント解決の確認のスクリーンショット。

pull request コメントの操作の詳細については、「 プル要求の確認」を参照してください。

マージの種類を制限する

Azure Reposでは複数のマージ戦略がサポートされており、既定では、すべてのマージ戦略が許可されます。 一貫性のあるブランチ履歴を保持するには、PR 完了のためのマージ戦略を適用します。

リポジトリで許可されるマージの種類を制限するには、[ マージの種類 の制限] を [オン] に 設定します。

マージの種類の制限のスクリーンショット。

  • 基本マージ (早送りなし) では、親がターゲット ブランチとソース ブランチであるターゲットにマージ コミットが作成されます。
  • スカッシュ マージ では、ソース ブランチからの変更を含む 1 つのコミットを含む線形履歴がターゲット ブランチに作成されます。 スカッシュ マージとそのブランチ履歴への影響について詳しく学ぶ。
  • リベースと早送りでは、マージ コミットなしで、ターゲット ブランチに対してソース コミットを再生することで、線形履歴を作成します。
  • マージ コミットによるリベースでは、ターゲットに対してソース コミットを再生し、マージ コミットも作成します。

ビルド検証を設定する

PR を完了する前に、PR の変更が正常にビルドされる必要があるポリシーを設定します。 ビルド ポリシーは、中断を減らし、テスト結果が合格し続けるようにします。 開発ブランチで継続的インテグレーション (CI) を使用して問題を早期に検出する場合であっても、ビルド ポリシーは役立ちます。

ポリシー トリガーを [自動] に設定すると、新しい PR を作成したり、ブランチを対象とする既存の PR に変更をプッシュしたりすると、ビルド検証ポリシーによって新しいビルドがキューに入れられます。 ポリシー トリガーを [手動] に設定した場合、ユーザーはビルド自体をキューに登録する必要があります。 どちらの場合も、ポリシーはビルド結果を評価して、PR を完了できるかどうかを判断します。

重要

ビルド検証ポリシーを指定する前に、ビルド パイプラインを作成します。 パイプラインがない場合は、ビルド パイプラインの作成に関するページを参照してください。 お使いのプロジェクトの種類に一致するビルドの種類を選択します。

ビルド検証ポリシーを追加するには

  1. +の横にあるを選択します。

    [ビルドの検証] の横にある [追加] ボタンを示すスクリーンショット。

  2. [Set build policy] (ビルド ポリシーの設定) フォームに入力します。

    ビルド ポリシー設定のスクリーンショット。

    • [ビルド パイプライン] を選択します。

  • 必要に応じて、[パス フィルター] を設定します。 ブランチ ポリシーにおけるパス フィルターの詳細を参照してください。

  • [トリガー] の下で、[自動 (ソース ブランチの更新時)] または [手動] を選択します。

  • [ポリシー要件] の下で、[必須] または [省略可能] を選択します。 [必須] を選択した場合、PR を完了するにはビルドが正常に完了する必要があります。 [省略可能] を選択すると、ビルド エラーの通知が表示されますが、PR の完了は引き続き可能です。

  • ビルドの有効期限を設定して、保護されたブランチの更新が、開いている PR の変更を中断しないようにします。

    • <branch name> が更新されたらすぐ: このオプションは、ブランチが更新されるたびに PR ビルド ポリシーの状態を "失敗" に設定し、ビルドを再度キューに入れます。 この設定により、保護されたブランチが変更された場合でも PR の変更が正常にビルドされます。

      このオプションは、重要なブランチに変更がほとんどないチームに最適です。 ビジー状態の開発ブランチで作業しているチームにとっては、ブランチが更新されるたびにビルドを待機すると混乱を招く場合があります。

    • <ブランチ名> が更新されてから <n> 時間後: このオプションは、合格したビルドが入力したしきい値より古い場合、保護されたブランチが更新されたときに現在のポリシーの状態の有効期限が切れます。 このオプションは、保護されたブランチが更新されたときにビルドを常に要求するか、要求しないかの間の妥協を表しています。 この選択により、保護されたブランチが頻繁に更新される場合のビルド数が減ります。

    • なし: 保護されたブランチを更新しても、ポリシーの状態は変わりません。 この値によりビルド数が減りますが、最近更新されていない PR の完了時に問題が生じる可能性があります。

  • このビルド ポリシーの表示名 (省略可能) を入力します。 この名前は、[ブランチ ポリシー] ページでポリシーを識別します。 表示名を指定しない場合、ポリシーではビルド パイプライン名が使用されます。

  1. [保存] を選択します。

PR の所有者が正常にビルドされた変更をプッシュすると、ポリシーの状態が更新されます。

<[branch name> が更新されたらすぐ] または [<branch name> が更新されてから <n> 時間後] ビルド ポリシーがある場合、以前のビルドが有効でなくなった場合、保護されたブランチが更新されるとポリシーの状態が更新されます。

状態チェックが必要

外部サービスでは、PR Status API を使用して、詳細な状態を PR に投稿できます。 追加サービスのブランチ ポリシーにより、外部のサービスが PR ワークフローに参加し、ポリシー要件を確立できるようになります。

[外部サービスに承認を求める] のスクリーンショット。

状態チェック ポリシーを構成するには:

  1. サービスがプル要求の状態をAzure Reposに投稿できることを確認します。
  2. ブランチ ポリシーの[状態チェック] で、+を選択します。
  3. [チェックするステータス] で、一覧から転記済みのチェックを選択します。 サービスがまだ状態を転記していない場合は、 genre/name 値を直接入力します。
  4. [ポリシー要件] を [必須] または [省略可能] に設定します。
  5. 必要に応じて、 承認された ID、 リセット条件、 ポリシーの適用可能性、および パス フィルターを構成します。
    • プル要求が作成されるとすぐにポリシーを適用する必要がある場合は、 既定で [適用] を使用します。
    • 最初の状態が投稿された後にのみポリシーを適用する必要がある場合は、[ 条件付き] を使用します。
  6. ブランチを対象とするプル要求を作成または更新し、ポリシーが PR の [ ポリシー ] セクションに表示されることを確認します。

組み込みのAzure DevOps サービス チェックとそのgenre/name識別子については、「使用可能なプル要求の状態チェック」を参照してください。 外部サービスのセットアップの完全なチュートリアルについては、「 外部サービスのブランチ ポリシーを構成する」を参照してください。

新しい統合がまだドロップダウンに表示されない場合は、サービスから状態を 1 回投稿し、ポリシーを追加するか、 genre/name 値を直接入力します。

レビュー担当者を自動的に含める

特定のディレクトリとファイル内のファイルを変更する pull request、またはリポジトリ内のすべての pull request に、レビュー担当者を自動的に追加できます。

  1. + の横にある ボタンを選択します。

    必要なレビュー担当者の追加を示すスクリーンショット。

  2. [新しいレビュー担当者ポリシーの追加] 画面に入力します。

    [新しいレビュー担当者ポリシーの追加] 画面を示すスクリーンショット。

    • [レビュー担当者] にユーザーとグループを追加します。

    • レビュー担当者を自動的に追加するものの、pull request を完了するために承認を必要としない場合は、[省略可能] を選択します。

      または、次の時点まで pull request を完了できない場合は、[必須] を選択します。

      • レビュー担当者として追加されたすべての個人が変更を承認する。
      • レビュー担当者として追加されたすべてのグループの少なくとも 1 人のユーザーが変更を承認する。
      • 必要なグループが 1 つだけの場合は、指定した最少数のメンバーが変更を承認する。

    • 自動的に追加されるレビュー担当者を必要とするファイルとフォルダーを指定します。 ブランチ内のすべての pull request にレビュー担当者を要求するには、このフィールドを空白のままにします。

    • pull request の所有者が、このポリシーを満たすために自分の pull request を承認する投票ができる場合は、[要求者が自分の変更を承認することを許可する] を選択します。

    • pull request に表示される [アクティビティ フィード メッセージ] を指定できます。

  3. [保存] を選択します。

必要に応じてポリシー バイパスを許可する

場合によっては、ポリシー要件をバイパスすることが必要になる場合があります。 バイパス アクセス許可があると、変更をブランチに直接プッシュしたり、ブランチ ポリシーを満たさない pull request を完了したりできます。 バイパスアクセス許可をユーザーまたはグループに付与し、それらのアクセス許可のスコープをプロジェクト全体、リポジトリ、または単一ブランチに設定できます。

次の 2 つのアクセス許可を使用すると、ユーザーはブランチ ポリシーを異なる方法でバイパスできます。

  • [Pull requests を完了するときに、ポリシーをバイパスする] は、pull request の完了のみに適用されます。 このアクセス許可を持つユーザーは、pull request がポリシーを満たしていない場合でも、pull request を完了できます。

  • [プッシュするときにポリシーをバイパスする] は、ローカル リポジトリからのプッシュと Web 上で行われた編集に適用されます。 このアクセス許可を持つユーザーは、ポリシー要件を満たさずに、保護されたブランチに変更を直接プッシュできます。

ポリシーのバイパス適用に関するアクセス許可を示すスクリーンショット。

これらのアクセス許可の管理の詳細については、Git アクセス許可に関するページを参照してください。

重要

特にリポジトリ レベルとプロジェクト レベルでポリシーをバイパスする機能を付与する場合は注意してください。 ポリシーは、安全で準拠したソース コード管理の基礎となります。

ブランチ ポリシーでパス フィルターを使用する

いくつかのブランチ ポリシーでは、パス フィルターがサポートされています。 パス フィルターを設定した場合、ポリシーはフィルターに一致するファイルにのみ適用されます。 ブランチ内のすべてのファイルにポリシーを適用するには、このフィールドを空白のままにします。

絶対パス (パスは / またはワイルドカードで始まる必要があります) とワイルドカードを指定できます。 例 :

  • /WebApp/Models/Data.cs
  • /WebApp/*
  • */Models/Data.cs
  • *.cs

区切り記号として ; を使用して、複数のパスを指定できます。 例:

  • /WebApp/Models/Data.cs;/ClientApp/Models/Data.cs

パスに ! のプレフィックスを付ける場合は、含まれていない場合は除外します。 例:

  • /WebApp/*;!/WebApp/Tests/* には、/WebApp のファイルを除く、/WebApp/Tests のすべてのファイルが含まれます
  • !/WebApp/Tests/* は、先頭に何も含まれていないため、指定されるファイルがありません

フィルターの順序が重要です。 フィルターを左から右に適用します。

ブランチポリシーのトラブルシューティング

ブランチ ポリシーがあるブランチに変更を直接プッシュできますか?

必須ブランチ ポリシーのあるブランチに変更を直接プッシュすることは、ブランチ ポリシーをバイパスする権限がない限りできません。 これらのブランチはプルリクエストを通じてのみ変更できます。 必須ブランチ ポリシーがない場合は、"省略可能" ブランチ ポリシーがあるブランチに変更を直接プッシュできます。

オートコンプリートとは何ですか?

プル要求用に構成されたブランチ ポリシーを持つブランチには 、[オートコンプリートの設定 ] ボタンがあります。 すべてのポリシーを満たしたら オートコンプリートするプル要求を設定するには 、このオプションを選択します。 オートコンプリートは、変更に関する問題が予想されない場合に便利です。

ブランチ ポリシーの条件はいつチェックされますか?

プル要求の所有者が変更をプッシュするとき、およびレビュー担当者が投票すると、サーバーはブランチ ポリシーを再評価します。 ポリシーによってビルドがトリガーされた場合、ビルドの状態は、ビルドが完了するまで待機中に設定されます。

ブランチ ポリシーで XAML ビルド定義を使用できますか?

いいえ、ブランチ ポリシーで XAML ビルド定義を使用できません。

必要なコード レビュー担当者に使用できるワイルドカード文字は何ですか?

1 個のアスタリスク * は、スラッシュ / とバックスラッシュ \ の両方を含む任意の数の文字に一致します。 疑問符 ? は、任意の 1 文字と一致します。

例 :

  • *.sql は、.sql 拡張子を持つすべてのファイルと一致します。
  • /ConsoleApplication/* は、ConsoleApplication という名前のフォルダーにあるすべてのファイルと一致します。
  • /.gitattributes は、リポジトリのルートにある .gitattributes* ファイルと一致します。
  • */.gitignore は、リポジトリ内のすべての .gitignore ファイルと一致します。

必要なコードレビュアーのパスは大文字と小文字を区別しますか?

いいえ。ブランチ ポリシーには、大文字と小文字の区別がありません。

複数のユーザーを必要なレビュー担当者として構成し、そのうちの 1 人のみが承認するように要求するにはどうすればよいですか?

ユーザーをグループに追加してから、そのグループをレビュー担当者として追加できます。 その後、グループの任意のメンバーが承認してポリシー要件を満たすことができます。

ポリシーをバイパスするアクセス許可があります。 pull request の状態でポリシー エラーが引き続き表示されるのはなぜですか?

システムは、プル要求の変更に対して構成済みのポリシーを常に評価します。 バイパス ポリシーのアクセス許可を持つユーザーの場合、報告されるポリシーの状態はアドバイザリのみです。 バイパス アクセス許可を持つユーザーが承認する場合、エラー状態により pull request の完了がブロックされません。

"要求元が自分の変更を承認することを許可する" を設定したときに、自分のプル要求を完了できないのはなぜですか?

[レビュー担当者の最少数が必要です] ポリシーと [自動的に追加されるレビュー担当者] ポリシーの両方に、[要求者が自分の変更を承認することを許可する] オプションがあります。 各ポリシーで、設定はそのポリシーにのみ適用されます。 この設定は、他のポリシーには影響を与えません。

たとえば、pull request には次のポリシーが設定されます。

  • 一定数以上のレビュー担当者を要求する には、少なくとも 1 人のレビュー担当者が必要です。
  • [自動的に追加されるレビュー担当者] には、自分または自分が参加しているチームがレビュー担当者として必要です。
  • [自動的に追加されるレビュー担当者] では、[要求者が自分の変更を承認することを許可する] が有効になっています。
  • [レビュー担当者の最少数を要求する] には、[リクエスターが自分の変更を承認することを許可する] は有効になっていません。

この場合、承認では [自動的に追加されるレビュー担当者] を満たしますが、[レビュー担当者の最少数が必要です] を満たさないため、pull request を完了できません。

他のポリシーにより、要求者が自分の変更を承認することを許可する が設定されていても、自分自身の変更を承認できない場合があります。 たとえば、直近で push したユーザーが自分自身の変更を承認できないようにする。

パス フィルターが / またはワイルドカードで始まらない場合はどうなりますか?

パスフィルター内の、/またはワイルドカードで始まらないパスは効果がありません。 パス フィルターは、そのパスが指定されていないかのように評価されます。 このようなパスは、絶対ファイル パスの先頭にある / と一致しません。

AI を使用してブランチ ポリシーを構成および管理する

Azure DevOps MCP サーバーを構成する場合は、Azure DevOps Services でブランチ ポリシーを更新する前に、自然言語を使用してリポジトリ、ブランチ、プル要求、ビルド コンテキストを収集できます。

Azure DevOps MCP Server には、Azure DevOps サービス、AI アシスタントのエージェント モード、およびNode.js 20.0 以降が必要です。 現在の MCP ドキュメントでは、ブランチ ポリシーの直接の読み取りまたは書き込みアクションについては説明されていないため、Azure DevOps Web ポータルまたは Azure DevOps CLI を使用してポリシーを作成および更新します。

Task プロンプトの例
リポジトリ内のブランチを一覧表示する List the branches in repo <Contoso.Web> in project <Contoso>
ポリシーを厳格化する前にプル リクエストをレビューする What pull requests require my review in project <Contoso>?
プル リクエストと関連付けられた作業項目を確認する Get details for pull request <67> and its linked work items in project <Contoso>
ビルド検証を必須にする前にビルドの状態を確認する Get the latest build status for pipeline <Contoso-CI> in project <Contoso>

Note

Visual Studio Codeを使用している場合、エージェント モードは、ブランチ ポリシーを更新する前に必要なプロジェクト コンテキストを収集するのに特に役立ちます。

関連するコンテンツ

  • Last updated on