More than 1 year has passed since last update.

Azure DevOps のブランチ保護

Posted at 2023-06-26

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

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

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

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

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

ブランチポリシー

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

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

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

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

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

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

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

コメント解決の確認

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

マージタイプを制限する

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

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

ビルドの検証

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

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

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

ステータスチェック

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

レビュアーポリシー

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

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

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