LoginSignup
1
0

More than 1 year has passed since last update.

Azure DevOps のブランチ保護

Posted at

ブランチポリシーはGitワークフローの重要な部分であり、開発の重要な支店を保護するためのルールを定義できます。 この記事では、Azure DevOpsでブランチプロテクションを実装する方法について説明します。

ブランチ ポリシーをどのように設定するか

Azure DevOps ポータルにログインし、[Repos] ページに移動します。 ブランチが表示されたら、[ブランチ(Branchs)] を選択し、保護したいブランチ名の右側にある縦3点ボタンをクリックします。 ドロップダウン メニューから [Branch policies] をクリックします。 ポリシーがすでに有効になっている場合、このブランチではプル要求を使用しない限り、直接的な変更は受け付けません。

image.png

選択したブランチの設定ページには、次の 4 つのポリシー タイプがあります:

  • ブランチポリシー
  • ビルドの検証
  • ステータスチェック
  • 自動的に含まれるレビュアー
    まずは、ブランチポリシーからすべてを見ていきましょう。

ブランチポリシー

ここでは、次の 4 つの異なるポリシーについて説明します(デフォルトでは無効になっています):

  • 最低限のレビュアー数が必要
  • リンク先の作業項目を確認
  • コメント解決の確認
  • マージ タイプを制限する

image.png

最低限のレビュアー数が必要

このポリシーは、特定の数のレビュアーがプル要求を承認するよう強制します。 このオプションを有効にすると、次の設定にもアクセスできます:

  • 要求者が独自の変更を承認できるようにします: 有効になっている場合、プル要求の作成者は承認を投票することができます。 そうでなければ、まだ承認に投票することはできますが、その投票はレビュアー数に考慮されません。
  • 最新のプッシャーが独自の変更を承認することを禁止します: この設定は最初の設定と非常に似ていますが、これにはより広範な貢献者グループが含まれます。 デフォルトでは、ユーザ全員がコミットでき、プルリクエストの承認に投票できます。。 このオプションは、より新しいプッシュがあったときにプッシュ者の投票をカウントしないようにします。
  • 一部のレビュアーが待機または拒否に投票した場合でも、完了を許可します‘: 有効にすると、レビュー担当者が変更を拒否しても、プルリクエストを完了することができます。
  • 新しい変更がある場合は、コードレビュアーの投票をリセットします: 有効になっている場合、ソースブランチに新しい変更がプッシュされると、コードレビューアの投票がリセットされます。

image.png

リンク先の作業項目を確認

このポリシーによって、すべてのプルリクエストにリンクされた作業項目があることを要求できます。 これは、タスク管理に Azure ボードを使用している場合に特に便利です。

image.png

コメント解決の確認

このポリシーはコードレビュープロセスに焦点を当てており、コードレビューセクションでコメントされた場合、プルリクエストを完了する前にそのコメントを解決する必要があります。

image.png

マージ タイプを制限する

このポリシーにより、プルリクエストで一部のマージ タイプを許可または拒否できます。

  • 基本マージ(早送りなし): プルリクエストブランチ内の個々のコミットはすべて保持され、マスター ブランチとプル要求ブランチを統合するために新しいマージコミットが作成されます。
  • スカッシュマージ: この特定のマージにより、プルリクエストを構成したすべてのコミットを取り込み(それらは破棄されます、それらのリポジトリ内容で新しいコミットを 1 つ作成します。
  • リベースと早送り: リベースは、プルリクエスト内の各コミットを取り込み、目的のブランチにチェリーピックします。
  • マージコミットを使用してリベース: プルリクエスト内のコミットは、目的ブランチの上でリベースされます。 そして、リベースされたプルリクエストは移動先ブランチにマージされます。

image.png

ビルドの検証

有効にすると、このポリシーは新しいプルリクエストが作成されるたびに新しいビルドの結果を評価します。または、選択したブランチを対象とする既存のプルリクエストに変更がプッシュされる場合も同様です。 このビルドが成功しないと、プルリクエストを完了できません。
ビルド検証を追加するには、まずパイプラインセクションに新しいビルドパイプラインを作成する必要があります。

image.png

新しいパイプラインの作成が完了したら、ブランチの設定ページに移動し、検証ビルドの右側にあるプラスアイコンをクリックします。
表示されるウィンドウで、以前に作成したビルドパイプラインを選択します。 また、さまざまな設定をトリガーとして設定したり(ソースブランチが手動で更新されるたびにパイプラインを起動する)、ポリシー要件を設定したり(ビルドが成功する必要があるかどうか、またはプルリクエストを完了するために失敗する可能性があるかどうかを定義する)、 およびビルドの有効期限を設定できます(保護されたブランチへの更新がオープンプルリクエストの変更を壊さないようにする)。 ポリシーを完了するには、[Save] をクリックします。

image.png

ポリシーが完了すると、ビルド検証セクションに表示されます。 新しいものを追加して、もちろん定義済みのものを変更または削除することもできます。 ビルドを自動的に起動するには、Enable スイッチが必要です。

image.png

ステータスチェック

このブランチ ポリシーを使用すると、サードパーティ サービスを追加してワークフローに参加し、ポリシー要件に基づいてプルリクエストをブロックまたは許可できます。

image.png

レビュアーポリシー

このポリシーを使用すると、変更されたコード パスに基づいて、プルリクエストごとに何人かのレビュアーを自動的に含めることができます。 ポリシー要件設定には、次の 2 つのオプションがあります:

  • 必須: パスのすべてのレビュアーが変更を承認するか、パスに追加された各グループの少なくとも 1 人が変更を承認するまで、プルリクエストを完了できません。
  • オプション: レビュアーを自動的に追加しますが、プルリクエストを完了するための承認は必要ありません。
    プルリクエストは、必要なすべてのレビュアーがコードを承認すると完了します。

image.png

これまで、ブランチ ポリシーを特定のブランチに設定する方法について説明してきましたが、より一般的な方法で実行する方法もあります。
複数のブランチのブランチ ポリシーを設定するには、[Settings] に移動し、[Repositories policies] をクリックして [Branch policies] セクションまでスクロールします。 このセクションでは、プロジェクト全体のブランチ ポリシーを作成できます。 これを行うには、プラス アイコンをクリックし、これらのポリシーをデフォルト ブランチまたは指定したパターンと一致するブランチに適用するかどうかを選択します。

image.png

[Create] をクリックすると、[Cross-repository policies settings] ページにリダイレクトされます。このページでは、以前とまったく同じポリシーを作成できます。

image.png

ブランチにポリシーが適用されると、ブランチ名の右側にアイコンが表示されます。

image.png

参考資料

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0