ブランチ ポリシーを使用してコードの品質を改善する

Azure Repos |Azure DevOps Server 2020 |Azure DevOps Server 2019 |TFS 2018 |TFS 2017 |TFS 2015

ブランチ ポリシーは、チームが開発の重要な ブランチを保護するのに 役立ちます。 ポリシーによって、チームのコード品質と変更管理の基準が適用されます。

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

[Repos > ブランチ] を選択 して 、Web ポータルの [ブランチ] ページを開きます。

Web 上の [ブランチ] ページを開く

ページで自分のブランチを見つける。 一覧を参照するか、右上の [すべてのブランチを検索] ボックスを使用 してブランチを検索できます。

[ブランチ] ページ

[...] ボタンを選択 します。 コンテキスト メニューから [Branch policies] を選択します。

コンテキスト メニューからブランチ ポリシーを開く

[ポリシーの構成] ページ 設定 します。 各ポリシーの種類の説明については、次のセクションを参照してください。

[Policies] ページでポリシーを構成します。 各ポリシーの種類の説明については、次のセクションを参照してください。 [変更 の保存] を 選択して、新しいポリシー構成を適用します。

[ポリシー] タブ

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

コード レビューは、ほとんどのソフトウェア開発プロジェクトのベスト プラクティスです。 テストを完了する前にチームに変更を確認pull request、レビュー担当者の最小数を要求 する] を選択します

基本的なポリシーでは、特定の数のレビュー担当者が拒否を行ってコードを承認する必要があります。

[コード レビューを要求する] ポリシーを有効にする

  • [ 要求者に独自の変更の 承認を許可する] が選択されている場合は、pull requestの作成者が承認に投票できます。 そうしない場合でも、投票者は承認に投票pull request、投票はレビュー担当者の最小数 に カウントされません
  • 既定では、ソース ブランチに対するプッシュ アクセス許可を持つすべてのユーザーが、コミットを追加し、pull requestに投票できます。 [最新のプッシュ者による独自の変更の承認を禁止する] を有効にすると、職務の分離を強制できます。最新のプッシュを自動的に設定すると、プッシュ者の投票はカウントされません。
  • レビュー担当者が変更を拒否した場合、一部のレビュー担当者が を待機または拒否することを投票した場合でも、[完了を許可する] を選択しない限り、pull requestを 完了できない場合があります
  • 新しい変更がソース ブランチにプッシュされた場合は、コード レビューアーの投票をリセットできます。 新 しい変更がある場合は、[Reset code reviewer votes]/(コード レビューアー投票のリセット)を選択します

[コード レビューが必要] ボックスをオンにします

  • 要求 が独自の変更を承認できない場合、pull request の作成者は引き続き pull request に対して承認に投票できますが、その投票はレビュー担当者の最小数 に カウントされません
  • レビュー担当者が変更を拒否した場合、一部のレビュー担当者が を待機または拒否することを投票した場合でも、[完了を許可する] を選択しない限り、pull requestを 完了できない場合があります
  • 新しい変更がソース ブランチにプッシュされた場合は、コード レビューアーの投票をリセットできます。 新 しい変更がある場合は、[Reset code reviewer votes]/(コード レビューアー投票のリセット)を選択します

必要な数のレビュー担当者が承認すると、pull request完了できます。

注意

要求 者は、独自の変更を承認できます 。この設定は、[レビュー担当者の最小数を要求する] ポリシーにのみ適用 されます。 [コード レビュー担当者を自動的に含める] などの 他のポリシーには影響はありません。 たとえば、JamalArtnett では、次のポリシーが構成pull requestを使用して新しいポリシーが作成されます。

  • レビュー担当者の最小数には、2 人のレビュー担当者が必要です。
  • 要求者は、独自の変更が 設定されていない場合に承認できます。
  • Fabrikam Team グループ は必須のレビューアーであり、Jamal はそのグループのメンバーです。

この例では、Jamal は Fabrikam Team グループに含まれるので、承認投票は必要なレビューアー ポリシーを満たします。 このpull request、レビュー担当者の最小数ポリシーを満たすために 2つの追加の承認投票が必要です。これは、投票がポリシーにカウントされません。

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

ブランチへの変更に作業項目管理の追跡を確実に行うには、pull requests と作業項目の間の 関連付けを要求します。 作業項目をリンクすると、変更に関する追加のコンテキストが提供され、更新が確実に作業項目の追跡プロセスを通過します。

pull requests でリンクされた作業項目を要求する

pull requests でリンクされた作業項目を要求する

コメント解決を確認する

[コメント解決の確認] を選択して、ブランチの コメント解決ポリシーを構成します

コメント解決を確認する

コメントの操作の詳細については、「pull requests -leave comments 」をpull requestを参照してください。

[コメント解決の確認] を選択して、ブランチの コメント解決ポリシーを構成します

コメント解決を確認する

コメントの操作の詳細については、「pull requests -leave comments 」をpull requestを参照してください。

マージの種類を制限する

マージ戦略が完了したらマージ戦略を適用することで、一貫性のあるブランチ履歴pull requestします。 Azure Reposマージ戦略が複数含み、既定では、すべてのマージ戦略が許可されます。 [ マージの種類を 制限する] を選択して、自分のレポジジで許可するマージの種類を選択します。

マージの種類を制限する

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

マージ戦略を適用する

マージ戦略が完了したらマージ戦略を適用することで、一貫性のあるブランチ履歴pull requestします。 [ マージ戦略を適用する] を選択し、その戦略を使用して pull requests のマージを要求するオプションを選択します。

マージ要件を設定する

  • 高速転送マージなし - このオプションは、pull request が終了し、ターゲット ブランチにマージ コミットを作成するときに、ソース ブランチのコミット履歴をマージします。
  • スカッシュ マージ - スカッシュ マージを使用してすべての pull request を完了し、ソース ブランチからの変更を含む 1 つのコミットをターゲット ブランチに作成します。 スカッシュのマージと、それが ブランチ履歴にどのように影響するかを確認します。

ビルドの検証

保護されたブランチを使用して正常にpull requestを完了する前に、pull request変更を必要とするポリシーを設定します。 ビルド ポリシーを使用すると、ブレークを減らし、テスト結果を引き続き合格に保つ。 ビルド ポリシーは、開発ブランチで継続的インテグレーション (CI) を使用して問題を早期にキャッチしている場合でも役立ちます。

ビルド検証ポリシーが有効になっている場合、新しい pull request が作成された場合、またはブランチをターゲットとする既存の pull request に変更がプッシュされると、新しいビルドがキューに登録されます。 次に、ビルド ポリシーはビルドの結果を評価して、ビルドをpull requestできるかどうかを判断します。

重要

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

ビルド ポリシーを追加する

[ビルド検証 + ] の横にある ボタンを選択します

ポリシー設定をビルドする

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

  2. 必要に応じて、パス フィルター を設定します。 ブランチ ポリシーの パス フィルターの 詳細を確認します。

  3. [トリガー] の種類を 選択します。 [ 自動] (ソース ブランチが更新されるたびに) または [手動]選択します

  4. [ポリシー要件 ] を選択します。 [必須] を選択した 場合、プル要求を完了するにはビルドが正常に完了する必要があります。 [ 省略可能 ] を選択すると、ビルドエラーの通知が提供されますが、pull request の完了は引き続き許可されます。

  5. ビルドの有効期限を設定して、保護されたブランチに対する更新によって開いている pull request の変更が破損しなかからなくします。

    • branch name 更新された場合 すぐに: このオプションは、保護されたブランチが更新pull request失敗するビルド ポリシーの状態を設定します。 ビルドを再キューして、ビルドの状態を更新します。 この設定により、保護されたブランチが変更された場合でも、pull request の変更が正常にビルドされます。 このオプションは、変更量が少ない重要なブランチを持つチームに最適です。 Teamsな開発ブランチで作業している場合、保護されたブランチが更新されるたびビルドが完了するのを待つのが中断される可能性があります。
    • n 更新 branch name された場合 の時間後: このオプションは、パスビルドが入力されたしきい値よりも古い場合に、保護されたブランチが更新された場合に現在のポリシー状態を期限切れにします。 このオプションは、保護されたブランチが更新された場合に常にビルドを要求し、それを必要としない場合の妥協点です。 この選択は、保護されたブランチで頻繁に更新されるビルドの数を減らすのに最適です。
    • Never: 保護されたブランチを更新した場合、ポリシーの状態は変更されません。 この値により、ブランチのビルドの数が減少します。 最近更新していない pull request を閉じるときに問題が発生する可能性があります。
  6. このビルド ポリシーの オプションの [表示 名] を入力します。 この名前は、[ブランチ ポリシー] ページ でポリシーを識別 します。 表示名を指定しない場合、ポリシーではビルド パイプライン名が使用されます。

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

所有者がビルドに成功した変更をプッシュすると、ポリシーの状態が更新されます。 [更新された場合は直ちに] または [ビルド ポリシーが更新された場合は時間後] が選択されている場合は、最新のビルドが無効になった場合に保護されたブランチが更新された場合にポリシーの状態が更新されます。 n branch name branch name

保護されたブランチを使用して正常にpull requestを完了する前に、pull request変更を必要とするポリシーを設定します。 ビルド ポリシーを使用すると、ブレークを減らし、テスト結果を引き続き合格に保つ。 ビルド ポリシーは、開発ブランチで継続的インテグレーション (CI) を使用して問題を早期にキャッチしている場合でも役立ちます。

ビルド検証ポリシーが有効になっている場合、新しい pull request が作成された場合、またはブランチをターゲットとする既存の pull request に変更がプッシュされると、新しいビルドがキューに登録されます。 次に、ビルド ポリシーによってビルドの結果が評価された後、ビルドを完了できるかどうかpull request判断されます。

重要

ビルド検証ポリシーを指定する前に、ビルド定義が必要です。 ない場合は、「ビルド定義を作成する」を参照し、プロジェクトの種類に一致するビルドの種類を選択してください。

ビルド ポリシーを追加する

[ビルド ポリシーの追加] を 選択し、 [ビルド ポリシーの追加 ] でオプションを構成します

ポリシー設定をビルドする

  1. [ビルド定義 ] を選択します

  2. [トリガー] の種類を 選択します。 [ 自動] (ソース ブランチが更新されるたびに) または [手動]選択します

  3. [ポリシー要件 ] を選択します。 [必須] を選択した 場合、pull requests を完了するにはビルドが正常に完了する必要があります。 [ 省略可能 ] を選択すると、ビルドエラーの通知が提供されますが、pull request の完了は引き続き許可されます。

  4. ビルドの有効期限を設定して、保護されたブランチに対する更新によって開いている pull request の変更が破損しなかからなくします。

    • branch name 更新された場合 すぐに: このオプションは、保護されたブランチが更新pull request失敗した場合に、ビルド ポリシーの状態を設定します。 ビルドを再キューして、ビルドの状態を更新します。 この設定により、保護されたブランチが変更された場合でも、pull request の変更が正常にビルドされます。 このオプションは、変更量が少ない重要なブランチを持つチームに最適です。 Teamsな開発ブランチで作業している場合、保護されたブランチが更新されるたびビルドが完了するのを待つのが中断される可能性があります。
    • n 更新 branch name された場合 の時間後: このオプションは、パスビルドが入力されたしきい値よりも古い場合に、保護されたブランチが更新された場合に現在のポリシー状態を期限切れにします。 このオプションは、保護されたブランチが更新された場合に常にビルドを要求し、それを必要としない場合の妥協点です。 この選択は、保護されたブランチで頻繁に更新されるビルドの数を減らすのに最適です。
    • Never: 保護されたブランチを更新した場合、ポリシーの状態は変更されません。 この値により、ブランチのビルドの数が減少します。 最近更新していない pull request を閉じるときに問題が発生する可能性があります。
  5. このビルド ポリシーの オプションの [表示 名] を入力します。 この名前は、[ブランチ ポリシー] ページ でポリシーを識別 します。 表示名を指定しない場合、ポリシーではビルド定義名が使用されます。

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

所有者がビルドに成功した変更をプッシュすると、ポリシーの状態が更新されます。 [更新された場合は直ちに] または [ビルド ポリシーが更新された場合は時間後] が選択されている場合は、最新のビルドが無効になった場合に保護されたブランチが更新された場合にポリシーの状態が更新されます。 n branch name branch name

状態チェック

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

承認するために外部サービスを要求する

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

外部サービスからの承認を要求する

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

承認するために外部サービスを要求する

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

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

レポポの特定のディレクトリとファイルのレビュー担当者を選択します。

パスと必要なレビュー担当者を入力します

パスと必要なレビュー担当者を入力します

これらのレビュー担当者は、それらのパスに沿ってファイルを変更する pull request に自動的に追加されます。 アクティビティ フィード メッセージ を指定できます

自動レビュー担当者を追加する

自動レビュー担当者を追加する

[必須] を選択 した場合pull request、次の手順を完了する必要があります。

  • パスのレビューアーとして追加されたユーザーは、すべてのユーザーが変更を承認します。
  • パスに追加された各グループに少なくとも 1 人のユーザーが変更を承認します。
  • パスに追加された各グループに指定されたレビュー担当者の数によって、変更が承認されます。

必要なレビュー担当者が自動的に追加される

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

[要求者に 独自の変更の承認を許可する] を選択できます

[要求者は 独自の変更を承認できます] を選択できます

必要なすべてのレビュー担当者がコードを承認したら、コードをpull request。

Pull request の状態は、レビュー担当者が承認済みである場合に表示されます

ブランチ ポリシーをバイパスする

場合によっては、ポリシー要件をバイパスする必要があります。 バイパスを使用すると、ブランチ ポリシーが満たされていない場合でも、変更を直接ブランチにプッシュしたりpull requestを完了したりすることができます。 前の一覧からユーザーまたはグループにアクセス許可を付与できます。 このアクセス許可のスコープは、プロジェクト全体、レポポ、または 1 つのブランチに対して行います。 このアクセス許可を他の Git アクセス許可 と共に管理します

2019 Azure DevOps Server 2019 以上では、ホストされているサービスを含め、ユーザーがさまざまな方法でブランチ ポリシーをバイパスできる 2 つのアクセス許可があります。 pull request の完了時にポリシーをバイパスする方法は 、pull requests の完了にのみ適用されます。 プッシュ時のポリシーのバイパスは 、ローカル リポジトリからのプッシュと Web 上で行われた編集に適用されます。

これにより、前の単一のアクセス許可 が置き換わる。

ポリシー適用のアクセス許可から除外する

TFS 2015 から TFS 2018 Update 2 では、[ポリシー適用から除外する] アクセス許可により、このアクセス許可を持つユーザーは次の操作を実行できます。

  • アプリケーションを完了pull request、現在のブランチ ポリシーセットが満たされていない場合でも、ポリシーをオーバーライドし、pull request を完了します。
  • ブランチにブランチ ポリシーが設定されている場合でも、ブランチに直接プッシュします。 このアクセス許可を持つユーザーがブランチ ポリシーをオーバーライドするプッシュを行う場合、プッシュはオプトインの手順や警告を使用してブランチ ポリシーを自動的にバイパスします。

重要

ポリシーをバイパスする機能 (特に、レポポとプロジェクト レベル) を付与する場合は注意が必要です。 ポリシーは、セキュリティで保護され、準拠しているソース コード管理の基になります。

パス フィルター

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

絶対パスとワイルドカードを指定できます。 次に例を示します。

  • /WebApp/Models/Data.cs
  • /WebApp/*
  • *.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 文字に一致します。

次に例を示します。

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

必要なコード レビューアー パスでは大文字と小文字が区別されますか?

いいえ。現時点では、ブランチ ポリシーでは大文字と小文字は区別されません。

複数のユーザーを必要なレビュー担当者として構成し、そのうちの 1 人のみを承認するように構成する方法

ユーザーを グループ に追加し、そのグループをレビューアーとして追加できます。 その後、グループのメンバーは、ポリシー要件を満たすためにグループを承認できます。

ポリシーのアクセス許可セットから除外を受け取っていますが、ポリシーの失敗がポリシーの状態で引き続きpull requestですか?

構成済みのポリシーは、構成されたポリシーに変更を追加するときに引き続きpull request。 ポリシーは、ポリシーの適用から除外されるユーザーにも適用されます。 除外ユーザーの場合、ポリシーの状態はアドバイザリのみであり、ポリシーの完了をブロックpull request。

高度なポリシー構成の詳細については、どこで確認できますか?

詳細については 、REST APIドキュメント を参照してください。