AWS CodeCommitの承認ルールワークフローを使ってみた

はじめに
やりたいこと
やってみる
やってみて気づいた点
- 1. 承認ルールテンプレート作成前に作成されたプルリクエストには適用されない
- 2. プルリクエストを作成した本人は承認できない
おわりに

はじめに

Gitの使い方には私もだいぶ慣れてきたものですが、実際にチーム開発でGitを使う際には、ソースコードのバージョン管理以外にも色々と考えることがあります。例えば、コードレビューはどのタイミングで誰がやる？とか、誰でもマージできるなんて怖いから制限したい！とか、プルリクエストを活用したい！とか。ワークフローの設定などでシステム的に制限をかけられたらなお良しですよね。

私自身が最近そんな状況に遭遇したわけなのですが、今回はCodeCommitの承認ルールワークフローを使って色々とやってみた内容をご紹介したいと思います。

ちなみに、ちょっとだけCodeCommitの歴史（？）を遡ると、2017年11月にプルリクエストがサポートされ、2019年11月にプルリクエストの承認ルールワークフローが実施可能になりました。

やりたいこと

想定するフローをざっくり書くと以下のような感じです。

開発者は、開発が完了したらプルリクエストを作成する
レビュアーは、プルリクエスト画面でコードレビューを実施し、問題なければ承認する
管理者は、承認済みのプルリクエストでマージを実施する

上記のフローを実現するために必要な制約をまとめると以下のようになります。

開発者はプルリクエストを承認できない
開発者はマージできない
プルリクエストは承認されていないとマージできない

やってみる

ロールの作成

「やりたいこと」に書いたとおり、登場人物は大きく分けると「開発者」「レビュアー」「管理者」の3人になりました。制約をかけたいので、それぞれに対して割り当てるロールを作成します。それぞれのロールに与える権限は以下のようなイメージです。

「開発者」ロール
- 最低限のGit操作（コミット、プッシュ、プルなど）ができる
- プルリクエストを作成できる
- コメントの作成や返信ができる
「レビュアー」ロール
- 「開発者」ロールの権限に加え、プルリクエストの承認ができる
「管理者」ロール
- 「レビュアー」ロールの権限に加え、プルリクエストのクローズおよびマージができる

マネジメントコンソールのCodeCommit画面上では、上記のいずれかにスイッチロールした上で操作してもらうこととします。

承認ルールテンプレートの作成

次に、承認ルールテンプレートを作成します。承認ルールテンプレートは、承認ルールワークフローの実施に必要な設定ファイルのようなものです。

CodeCommit画面の左サイドメニューから「承認ルールテンプレート」を開き、「テンプレートの作成」ボタンをクリックします。

次に、以下のように各項目を入力し、承認ルールテンプレートを作成します。

「必要な承認の数」には、今回はレビュアーが1人でも承認してくれたらOKとしたかったので、1としました。

ここで重要なのが、「承認プールのメンバー」です。今回はレビュアーロールのみ承認可能に設定します。「承認者のタイプ」で「IAMユーザー名または引き受けたロール」を選択し、「値」には「ロール名/*」の形式で入力します。ロールで制御したい場合はこう書かないといけないようです。

今回は設定していませんが、特定ブランチへのマージを対象にしたい場合は、「ブランチフィルター」を設定することもできます。

プルリクエストの作成～承認～マージ

まずは開発者ロールでプルリクエストを作成します。開発者ロールだと、現状はプルリクエストを更新したり閉じたりすることしかできません。

次に、先程作成したプルリクエストをレビュアーロールで見てみます。すると、以下のように「承認」ボタンが表示されます。

レビュアーは、プルリクエスト画面でコードレビューを実施し、問題なければ承認することとします。

「承認」ボタンを押すと、以下のように承認数が1となり、「マージ」ボタンが出現します。このとき、「承認」ボタンは「承認を取り消し」ボタンに変わるので、もし間違えて承認してしまった場合でも、取り消しボタンを押せば、承認前の状態に戻せます。

あとは管理者が「マージ」ボタンを押してマージします。いい感じ！

やってみて気づいた点

承認ルールテンプレートの設定で、わりと簡単にやりたいことが実現できた～！ということで大満足なのですが、運用していく中で気づいた点があるのでご紹介します。

1. 承認ルールテンプレート作成前に作成されたプルリクエストには適用されない

これは、考えてみたら、うん、そうだよね、という話ですね。

何が言いたいのかというと、承認ルールワークフローを設定したければ、なるべく早く、少なくともプルリクエストが作成される前には承認ルールテンプレートを作成した方が良さそう、ということです。

2. プルリクエストを作成した本人は承認できない

今回の場合、承認できる権限を持つのはレビュアーと管理者になりますが、例えばレビュアーがプルリクエストを作成した場合、作成したレビュアー本人はそのプルリクエストを自分で承認できません。これも、そりゃそうだよね、という感じではあります。自分自身で承認できたら意味ないですもんね。

対応として、

プルリクエストは開発者ロールで作成し、承認はレビュアーロールで行う
管理者に承認してもらう

のいずれかとしました。

今回のように、いくつかのロールで制御を行う場合は上記のような対応で切り抜けられましたが、承認ルールテンプレートで承認者に指定された本人がプルリクエストを作成した場合にはどうするか？については、以下の記事が参考になるかと思います。

[CodeCommit] 承認ルールの承認者自身が作ったPRは自分で承認できるか確認してみた...

~~https://dev.classmethod.jp/articles/codecommit-approvalrule-for-pullrequest-myself/~~

どうも！大阪オフィスの西村祐二です。 7/7は弊社の創立記念日です。おめでたいですね。今回は小ネタです。久しぶりにCodeCommitを検証していると承認ルールワークフローが設定できるようになっていました。アップデ …

クラスメソッド発「やってみた」系技術メディア | DevelopersIO

おわりに

今回初めて承認ルールワークフローを使ってみましたが、なんだかすごくうまく使えた気がする！！！と思いました。（自画自賛…）

とはいえ、冒頭に書きましたが、2019年末には承認ルールワークフローは使えるようになってたんですよね…。そう考えると、だいぶ気付くのが遅かったなと思います。（自画自賛からの反省）

私自身は、Git利用歴だけ見るとそこそこ長く、それなりに使えるようになってきたのですが、周りにはまだGitに不慣れなメンバーも多いのが現状です。特に大きな開発プロジェクトでGitを利用する際などは、文面によるルール周知のみでなく、承認ルールワークフローのような制御も併用して運用するのが良いと改めて感じました。

まだ使ったことがない方も、かなり簡単に使えるので、ぜひお試しください！