2016.06.18 2024.06.14

GitHub のプルリクエストのコードレビュー頻度とラベル運用見直し

gene

下記のブログでご紹介のとおり、これまで弊社では毎日15時に GitHub のプルリクエストチェックするように促す運用を行ってきた。

Github でメンションを送られているプルリクエストを確認 | MMMブログ

メンションされた人全員がレビューを行い、OKだったらマージするという運用を行って来たが、プルリクエストのレビュー待ち、レビュー後の指摘事項反映待ち、など開発の速度が遅くなってきてしまう問題が出てきた。

Contents

プルリクエストがなかなかマージできない

プルリクエストがなかなかマージできない

複数人で開発を行っていると、どんどんプルリクエストが上がってきて、レビューがなかなか終わらないためマージがなかなかできないという状況になって来ていた。

プルリクエストの数が多くなってきているのに加えて、各自がしっかりとコードレビューを行っていて、指摘がバンバン入っているため、指摘事項修正対応に時間がかかっている。

コードの品質を高く保つという面では非常に良いとは思うものの、開発スピードという視点で見ると、ちょっと遅くなってきてしまっていると感じることがある。

また、別のプルリクエストがマージされた影響で、他のブランチへの反映が必要になったり、あるブランチから別のブランチを作ってるようなときに、ベースのブランチのプルリクエストで指摘が続くと、それを反映しないといけなくて、時間がかかってしまったり、とコードレビューがスピード感を持った開発におけるボトルネックとなりつつあった。

レビューの頻度を上げる

そこで、これまでの1日1回プルリクエストのコードレビューをしていたものを、 1日2回プルリクエストをレビューする運用にしてはどうか、という提案があった。

そうすることで、朝に指摘した事項を15時に確認できるし、15時に指摘した事項を、次の日の朝確認できるので、レビュー＆修正/指摘事項反映のサイクルがもっと頻繁に回るのではないか、ということである。

ラベルの運用も合わせて見直すことに

また、レビューの頻度を上げることと合わせて、ラベルの運用も見直すことになった。
これまであまりチーム間で認識合わせを行っておらず、各自の判断で使用していたラベル運用を、チーム内で共通認識を持つことで効率よくレビューのサイクルを回そう、という試みである。

ラベル一覧

今後のラベル運用で使うことになったラベルは下記のとおり。

`review`

「マージできる準備ができているから早くレビューして！」

チームメンバーに、レビューしてもらえる状態。
チームメンバーは、こちらの review ラベルが付いているものから優先的にレビューを行う。

`in progess`

「時間あるならレビューしてくれると助かるな！」

review ラベルと併用される。
review in progress が付いているものは、レビューで修正が必要な箇所が出てきたため、まだマージできないけど、時間あるならレビューしてくれると助かるな！というもの。
チームメンバーの、コードレビューの優先度としては、 review ラベル単独のものよりは、優先度が低くなる。
また、この in progress はちょっと重た目の指摘をした人が付ける。
typo など軽めの指摘だったら付けない。「重た目」かどうかは、レビューした人の主観が入ってしまうが、そこはとりあえず各自に任せることとなった。

`help wanted`

「実装の方針とか設計とか間違ってないかな？意見ください！」

help wanted は方針が間違っていないかなどの意見が、早い段階から欲しい時などに使用する。
このラベルは、プルリクエストのタイトルに WIP を付けたまま、 help wanted を付ける。
必要に応じて、チームメンバーを呼び出して、このプルリクエストを見ながら早めの段階で議論する。