こんにちは、クラウド事業部 CI/CDサービスメニューチームの山路です。
今回はGitLab上で安全に開発・リリースを進めるうえで重要なMerge request approval rules / Code Ownersを紹介します。
docs.gitlab.com docs.gitlab.com
背景
GitLabなどのバージョン管理システムでソースコードを管理する場合、ソースコードの品質を担保する手段の一つとして、特定の人物（プロダクトマネージャー、特定のプログラミング言語の専門家など）のレビュー・承認をコード変更の条件にする場合があります。GitLabはこれを実現する方法として、Merge request approval rules / Code Ownersなどの機能を提供します。
Merge request approval rulesは、Merge requestをマージするのに「誰から」「何件の」承認が必要かを義務付ける機能です。Approval rulesはProjectごとのデフォルトルールを設定するほか、Merge requestごと・GitLabインスタンスごと (Self-managed版のみ) に設定することもできます。
一方でCode Ownersは、リポジトリ内のファイルやディレクトリを対象に所有者を定義します。Code Ownerを定義すると、GitLab上で該当のファイルを閲覧した際に所有者として表示されるほか、Protected branchと組み合わせてファイル変更時のレビュアーに所有者を設定できます。
さらにMerge request approval rulesとCode Ownersを組み合わせると、ファイルの所有者以外にもレビュアーを追加できます。これにより、より広い観点からレビューを実施し、リポジトリ中のファイルの品質を担保することが出来ます。
なお、Merge request approval rules / Code OwnersはどちらもPremiumプラン以上で利用可能です。
Merge request approval rules
ここからMerge request approval rules / Code Ownersそれぞれの利用方法を紹介します。
ルールの追加
まずはMerge request approval rulesのルールの設定を行います。設定は対象のProject画面に移動後、GitLab画面左メニューから 設定→ マージリクエスト を選択し、 マージリクエストの承認の項目に移動します。
承認ルールを追加を選択すると、画面右側に以下のような画面が表示されます。ここではテスト用のルールを設定します。
Approval rulesは以下の項目を設定します。
- ルール名
- ターゲットブランチ: ブランチ名を指定するほか、
すべてのブランチ全ての保護されたブランチも選択できます。 - 必要な承認数: 0~100までの数字を設定できます。
0の場合はApproval rulesのパスが必須とはならずオプション扱いとなります。 - 承認者を追加: 承認者としての条件を満たすユーザー・Groupから選択します。
変更を保存を選択すると、以下のようにルールが追加されます。なおMerge request approval ruleは複数追加できます。
この状態でMerge requestを作成すると、以下のようにマージがブロックされます。
詳細を見ると、ここでは2つのルールのうち、片方をクリアしていないことがわかります。なお test01 のほうは、Merge requestの作成者と承認者が同一だったため、自動的に承認されたようです。
またAdmin権限を持つユーザー、もしくはMerge requestの作成者で、かつMerge requestでのAproval rulesの変更が禁止されていない場合、Merge requestの作成時にApproval rulesを設定することもできます。
Merge request作成画面で 承認ルール を選択すると、Projectのデフォルトルールが表示されるので、新しいルールの追加や削除を実行できます。
Security approval (Ultimateプラン)
Ultimateプランを利用している場合は Merge request approval policy との連携も可能です。これはセキュリティスキャンの実施結果をもとにしたポリシーを設定可能で、例えば重大な脆弱性を検知した場合はMerge request上でエラーを表示する、といった処理が可能になります。
ここでは先ほどと同じくProjectの左画面から 設定→ マージリクエストに移動し、 セキュリティ承認の項目から セキュリティポリシーの作成を選択します。
画面が遷移してSecurity Policyの作成画面に移動します。ここでは マージリクエスト認証ポリシーを選択します。
ポリシー作成画面が表示されるので、テスト用にポリシーを設定します。
ここでルールにセキュリティ関連のチェック項目を選択すると、Merge request作成時にセキュリティチェックを行います。
作成を行うとMerge request経由で変更するよう案内されます。なおこの時に新しいprojectが作成されていることに注意してください。
マージすると以下のように .gitlab/security-policiesというディレクトリに policy.ymlファイルが作成され、Security approvaslが設定されました。
ここで先ほどの マージリクエスト設定画面に戻ると、セキュリティ承認にルールが設定されているのを確認できます。
この状態で再びMerge requestを作成すると、いくつかの違いを確認できます。
まずは警告されるルールに先ほど追加した test01 が追加されています（同名のルールなのでわかりにくいですが、一番下が追加したものです）。
そして アクティビティー を見ると、GitLab Security Botから条件を満たしていないことを伝えるメッセージが投稿されています。
また同じメッセージはGitLabのメールにも届いています。このような形でセキュリティチェックと通知を行い、セキュリティに問題の可能性が残る変更をブロックしてくれます。
その他
GitLabは Reporter というRoleがあります。このRoleはコードの修正やコミットの権限はなく、コードやIssueなどの閲覧権限のみ付与されています。例えば特定のプロジェクトに関わる方の中には、コードの変更や内容はチェックせず、どんな作業 (リリース作業など) をするかチェックしたい場合もあります。GitLabではこういったケースに対応するため、 Reporter roleに承認権限を追加する手段も用意しています。
Code Owners
続いてCode Ownersの設定を見ていきます。
Code Ownerの設定
Code Ownersを設定するには、 CODEOWNERS というファイルに設定を記載し、リポジトリに配置します。
ここではテスト用に doc / test01.md doc / test02.md というファイルを作成します。
CODEOWNERS の記載方法はGitLabのドキュメントにありますが、ここでは以下のようなファイルを用意しました。
# CODEOWNERSは[Section]の配下に対象のファイル・ディレクトリと所有者を定義する # ここではREADME.mdを管理するため [README] Sectionを定義し、その中でファイル名と所有者を定義する # 所有者は@の後ろにGitLabユーザー名を記載する [README] README.md @futa_yamaji # CODEOWNERSはワイルドカードなどを使い、複数のファイルを指定することもできる [Doc] doc/*.md @<GitLabユーザー名>
上記ファイルを作成し、リポジトリに配置します。
CODEOWNERS 配置後に該当のファイルにアクセスすると、画面上にCode Ownerが表示されるのを確認できます。
Protected branchに対するCode Ownersからの承認要求
次にProtected branchとCode Ownersを組み合わせてみます。
※参考:
Protected branchの設定を確認するため、Projectの 設定 → リポジトリに移動し、 保護ブランチ の項目を確認します。
コードオーナーの承認という項目があるのでこれをクリックし、対象のブランチでCode Ownerの承認を有効にします。
この状態でMerge requestを作成すると、Code Ownerからの承認が必要であることが表示される。
ここで詳細を見ると、誰がCode Ownerかを確認することもできます。
Merge request approval rulesとCode Ownersの組み合わせ
最後にMerge request approval rulesとCode Ownersを組み合わせる場合を紹介します。
ここまで紹介した通り、Merge request approval rulesとCode Ownersは、それぞれ異なる視点・設定からMerge requestのレビュアーを設定することができます。そこで、この2つを組み合わせることで、リポジトリ中のファイルへの変更を、以下のような異なる目線からレビューすることが可能となります。
- Code Owners: リポジトリ内の特定のファイルやパスに対して専門的な知識を持つユーザーを指定し、Code Ownerのチェックを経てマージされるよう設定出来る。
- Approval rules: 特定のファイルやパスに依存しない専門家（例えばフロントエンド・セキュリティなど分野レベルの専門家）を指定し、より広い範囲でチェックされるようにできる。
GitLabのドキュメントでは、Code OwnersとApproval rulesの組み合わせとして、以下のような例を紹介しています。
| Type | ルール名 | Scope | 概要 |
|---|---|---|---|
| Approval rule | UX | 全てのファイル | UXチームメンバーがProject内の全ての変更に対するUXをチェックする |
| Approval rule | Security | 全てのファイル | SecurityチームメンバーがProject内の全ての変更に対するセキュリティ・脆弱性をチェックする |
| Code Owner rule | Frontend: Code Style | *.css |
FrontendエンジニアがCSSファイルへの変更に対し、標準的またはProject内のルールに従っているかチェックする |
| Code Owner rule | Backend: Code Review | *.rb |
BackendエンジニアがRubyのファイルへの変更に対するロジックとコードスタイルのレビューを行う |
さいごに
今回はGitLabのMerge request approval rules / Code Ownersという機能を紹介しました。この機能はどちらもコードレビュー時に必要なレビュアーが漏れることを防ぐ機能のため、まだ導入していない場合はぜひ導入してみることをお勧めいたします。また、それぞれ個別に使うことも有効ですが、コードレビューの品質をさらに向上するため、2つを組み合わせて利用することも、検討してみてはいかがでしょうか。
最後に、弊社はGitLabオープンパートナー認定を受けております。 また以下のようにCI/CDの導入を支援するサービスも行っているので、何かご相談したいことがあればお気軽にご連絡ください。
