Help us understand the problem. What is going on with this article?

CODEOWNERS で特定の人間をレビュー必須にすれば世界は平和になるはず

「あああああああああああああああああ!!ちょっと待って!なんでそれマージしちゃったの!!!??!?!?」
バグどっかーーーーーーーーーーーーーーーーーーん!💣💥

こんな悲劇、身近にありませんか?ありますよね。
だいたい前後のできごとをデフォルメして再現するならこんな感じになるでしょうか。

再現VTR
俺氏「プルリク出しましたー!レビューお願いしまーす」
同僚甲「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 さんのレビューは必須!という意味です。

.github/CODEOWNERS
# 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
# 頭に / をつけることで、トップレベルにあるディレクトリのみを対象にすることができます。

一番シンプルに書くとこんな感じになります。最初はこれでいいのではないでしょうか。

.github/CODEOWNERS
* @FumiyaShibusawa

2. .github/ 以下に CODEOWNERS を置く

CODEOWNERS の置き場所は、ルートディレクトリ直下かあるいは .github ディレクトリ以下です。 .github の方が分かりやすいでしょう。

3. ブランチのプロテクションルールを追加する

最後に、ブランチのプロテクションルールを追加して、 Code Owners からのレビューを必須にします。

3-1. Settings > Branches > Add rule をクリックする

スクリーンショット 2018 12 16 22 52 47.png

3-2. Require review from Code Owners にチェックをつける

スクリーンショット 2018 12 16 22 57 49.png

これで Create ボタンを押せば完了です。次からプルリクを出した時、以下のスクショのように Reviewers のところに鍵マークが表示されるようになります。このマークのついたユーザーのレビューは必ず通さないとマージできません。
スクリーンショット 2018-12-16 23.05.00.png

最後に

もちろん、この Code Owners がすべてのプロジェクトに活きてくるわけでもないです。人数の少ないかつスピード感を持って開発をしたいスタートアップには合わないかもしれません。このレビュー必須というルールが足かせになる可能性もあるからです。ですが、ある程度の規模があって人数もそれなりに多いプロジェクトには特に便利かと思います。複数人を Code Owners にすることもできますし、特定のディレクトリ/ファイルのみを対象にすることもできるので、わりと柔軟性を持って運用できそうな気がします。

冒頭にあったような悲劇が少しでも減りますように…。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした