「あああああああああああああああああ！！ちょっと待って！なんでそれマージしちゃったの！！！？？！？！？」
バグどっかーーーーーーーーーーーーーーーーーーん！💣💥
こんな悲劇、身近にありませんか？ありますよね。
だいたい前後のできごとをデフォルメして再現するならこんな感じになるでしょうか。
俺氏「プルリク出しましたー！レビューお願いしまーす」
同僚甲「Approveしましたー！」
同僚乙「Approveしましたー！」
俺氏「（このあたりは同僚丙さんが一番詳しいけど、ちょっとの修正だし、まーええやろ）」
「ほんじゃマージしまーす！」
「ポチッ（マージボタンを押す）」
（CIで自動でデプロイが走る。同僚丙、トイレから戻ってくる）
同僚丙「……………………ふぁ！？」
「あああああああああああああああああ！！ちょっと待って！なんでそれマージしちゃったの！！！？？！？！？」
「この部分、実はこのファイルとこのファイルに影響してて修正しちゃうとバタフライエフェクト的にうんぬんかんぬん…」
（デプロイが完了する）
バグどっかーーーーーーーーーーーーーーーーーーん！💣💥
こうした悲劇を未然に防ぎたい。
どんな小さなコードベースの変更だったとしても、
第三者の目を透してからじゃないと絶対にマージできないようにしたい。
しかも、できればそのコードベースに一番詳しい人／プロジェクトのリーダーのレビューは絶対に通したい。
そんなときに便利なのが、 Code Owners という GitHub の機能。
https://blog.github.com/2017-07-06-introducing-code-owners/
https://help.github.com/articles/about-codeowners/
Code Owners とは
リポジトリ内のコードに責任を持つ個人あるいはチームのことを指します。その人／チームが Code Owners になることで、そのコードに変更があるプルリクが出された場合、自動的にレビュー依頼が飛ぶようになります。また、ブランチのプロテクションルールにある Require review from Code Owners にチェックを入れると、 Code Owners から Approve されないとマージできないようにすることもできます。人数の多いプロジェクトチームのレビュー管理に特に便利。
Code Owners の設定方法
手順は割と簡単で、以下のステップに沿っていけば数分で Code Owners を指定できるようになります。
1. CODEOWNERS ファイルを作成する
CODEOWNERS というファイルを作成して、そのリポジトリ上に置いておく必要があります。このファイル内で、特定の範囲のコードに対してユーザー名やユーザーのメールアドレスを指定していきます。
以下のサンプルコードにそれぞれ日本語でコメントアウトしていきますが、基本的に * @foo @bar と書いておけば OK かと思います。これは、すべてのコードに対して ＠foo さんと ＠bar さんのレビューは必須！という意味です。
# This is a comment.
# Each line is a file pattern followed by one or more owners.
# These owners will be the default owners for everything in
# the repo. Unless a later match takes precedence,
# @global-owner1 and @global-owner2 will be requested for
# review when someone opens a pull request.
* @global-owner1 @global-owner2
# リポジトリ内の全てのコードに対して、 @global-owner1 さんと @global-owner2
# さんがレビューを求められるようになります。
# Order is important; the last matching pattern takes the most
# precedence. When someone opens a pull request that only
# modifies JS files, only @js-owner and not the global
# owner(s) will be requested for a review.
*.js @js-owner
# .js と名のつくファイル全てに対して、 @js-owner がレビューを求められるようになります。
# You can also use email addresses if you prefer. They'll be
# used to look up users just like we do for commit author
# emails.
*.go docs@example.com
# ユーザーの指定にはメールアドレスを用いることもできます。
# In this example, @doctocat owns any files in the build/logs
# directory at the root of the repository and any of its
# subdirectories.
/build/logs/ @doctocat
# ディレクトリを指定すると、そのディレクトリ以下すべてのコードを対象にすることもできます。
# The `docs/*` pattern will match files like
# `docs/getting-started.md` but not further nested files like
# `docs/build-app/troubleshooting.md`.
docs/* docs@example.com
# foo/* と書くと、 foo 直下のファイルのみを対象にすることができます。
# In this example, @octocat owns any file in an apps directory
# anywhere in your repository.
apps/ @octocat
# ちょっとトリッキーですが、 app/ が複数あった場合はすべて対象になります。
# In this example, @doctocat owns any file in the `/docs`
# directory in the root of your repository.
/docs/ @doctocat
# 頭に / をつけることで、トップレベルにあるディレクトリのみを対象にすることができます。
一番シンプルに書くとこんな感じになります。最初はこれでいいのではないでしょうか。
* @FumiyaShibusawa
2. .github/ 以下に CODEOWNERS を置く
CODEOWNERS の置き場所は、ルートディレクトリ直下かあるいは .github ディレクトリ以下です。 .github の方が分かりやすいでしょう。
3. ブランチのプロテクションルールを追加する
最後に、ブランチのプロテクションルールを追加して、 Code Owners からのレビューを必須にします。
3-1. Settings > Branches > Add rule をクリックする
3-2. Require review from Code Owners にチェックをつける
これで Create ボタンを押せば完了です。次からプルリクを出した時、以下のスクショのように Reviewers のところに鍵マークが表示されるようになります。このマークのついたユーザーのレビューは必ず通さないとマージできません。
最後に
もちろん、この Code Owners がすべてのプロジェクトに活きてくるわけでもないです。人数の少ないかつスピード感を持って開発をしたいスタートアップには合わないかもしれません。このレビュー必須というルールが足かせになる可能性もあるからです。ですが、ある程度の規模があって人数もそれなりに多いプロジェクトには特に便利かと思います。複数人を Code Owners にすることもできますし、特定のディレクトリ／ファイルのみを対象にすることもできるので、わりと柔軟性を持って運用できそうな気がします。
冒頭にあったような悲劇が少しでも減りますように…。