次の方法で共有

ブランチ ポリシーと設定

  • [アーティクル]

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

ブランチ ポリシーは、チームが開発の重要なブランチを保護するのに役立ちます。 ポリシーによって、チームのコード品質と変更管理の基準が適用されます。 この記事では、ブランチ ポリシーを設定して管理する方法について説明します。 すべてのリポジトリおよびブランチのポリシーと設定の概要については、Git リポジトリの設定とポリシーに関するページを参照してください。

必要なポリシーが構成されているブランチは削除できず、すべての変更に pull request (PR) が必要になります。

前提条件

  • ブランチ ポリシーを設定するには、Project Administrators セキュリティ グループのメンバーであるか、リポジトリ レベルの 編集ポリシー アクセス許可を持っている必要があります。 詳細については、「Git リポジトリのアクセス許可を設定する」を参照してください。

  • Azure DevOps CLI az repos policy コマンドを使用してブランチ ポリシーを管理する場合は、「Azure DevOps CLI の概要」の手順を実行します。

  • ブランチ ポリシーを設定するには、Project Administrators セキュリティ グループのメンバーであるか、リポジトリ レベルの 編集ポリシー アクセス許可を持っている必要があります。 詳細については、「Git リポジトリのアクセス許可を設定する」を参照してください。

ブランチ ポリシーを構成する

ブランチ ポリシーを管理するには、[Repos]>[ブランチ] を選択して、Web ポータルで [ブランチ] ページを開きます。

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

また、[プロジェクト設定]>[リポジトリ]>[ポリシー]>[ブランチ ポリシー]><[ブランチ名]> で、ブランチ ポリシーの設定を表示することもできます。

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

ブランチ ポリシーを設定するには、管理する必要があるブランチを見つけます。 一覧を参照するか、右上の [ブランチ名の検索] ボックスでブランチを検索することができます。

ブランチの横にある [その他のオプション] アイコンを選択して、コンテキスト メニューから [ブランチ ポリシー] を選択します。

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

ブランチの設定ページでポリシーを構成します。 ポリシーの種類ごとの説明と手順については、次のセクションを参照してください。

レビュー担当者の最少数を要求する

ソフトウェア開発プロジェクトには、コード レビューが重要です。 チームが PR を確実にレビューして承認するために、最少数のレビュー担当者からの承認を要求できます。 基本ポリシーでは、指定された数のレビュー担当者が拒否なくコードを承認する必要があります。

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

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

  • PR の作成者がその承認に投票できるようにするには、[要求者が自分の変更を承認することを許可する] を選択します。 それ以外の場合は、作成者は PR の承認に投票できますが、その投票はレビュアーの最低人数には含まれません。

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

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

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

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

リンクされた作業項目を確認する

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

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

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

コメント解決の有無を確認する

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

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

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

pull request コメントの使用の詳細については、「pull request のレビュー」を参照してください。

マージの種類を制限する

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

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

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

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

ビルドの検証

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

ビルド検証ポリシーは、新しい PR が作成されるか、ブランチを対象とする既存の PR に変更がプッシュされたときに、新しいビルドをキューに入れます。 ビルド ポリシーはビルド結果を評価して、PR を完了できるかどうかを判別します。

重要

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

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

  1. ビルド検証の横にある+を選択します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

状態の確認

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

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

このポリシーの構成手順については、「外部サービスのブランチ ポリシーを構成する」を参照してください。

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

特定のディレクトリとファイル内のファイルを変更する 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/* は、先頭に何も含まれていないため、指定されるファイルがありません

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

Q & A

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

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

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

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

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

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

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

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

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

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

例 :

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

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

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

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

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

私にはポリシーをバイパスするための権限があります。 pull request の状態でポリシー エラーが引き続き表示されるのはなぜですか?

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

[要求者が自分の変更を承認することを許可する] が設定されているときに、自分の pull request を完了できないのはなぜですか?

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

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

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

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

また、[要求者が自分の変更を承認することを許可する] が設定されている場合でも自分の変更を承認できないようにする他のポリシー ([最新のプッシュ元が自分の変更を承認することを禁止する] など) もあります。

パス フィルター内のパスの先頭に / もワイルドカードもない場合、どうなりますか?

先頭に / もワイルドカードも付かないパス フィルターのパスは無効です。そのパスが指定されなかった場合と同じようにパス フィルターが評価されます。 このようなパスは、絶対ファイル パスの先頭にある / と一致しません。