はてなブログチームの開発フローとGitHub（後編）。GitHub Kaigi 2014

2014年6月24日

GitHub User Group主催のGitHub Kaigiが6月1日、都内で開催されました。

本記事ではGitHub Kaigiの2つ目のセッションとなった柴崎優季氏の「はてなブログチームの開発フローとGitHub」の内容をダイジェストで紹介します。

（本記事は「はてなブログチームの開発フローとGitHub（前編）。GitHub Kaigi 2014」の続きです）

GitHubとレビュー

以前は同僚に、「Pull Requestをしたのでレビューをお願いします」と詳しい人に個別にお願いするパターン。

あるいは開発者が自分でPull Requestのなかからそれっぽい奴をさがしてレビューするか、という2パターンでやっていました。

これもあんまりうまくいかなかったんですね。Pull Requestの状態が分からないので、いまレビューしてもらいたいのか、WIP（Work In Progress：仕掛かり中）で修正中なのか、レビューがもう終わっているのか。分からないので面倒になってレビューをためらうと。

その結果レビューが消化されず、Pull Requestがすごい量になっているのだけど、誰がレビューするんだということで固まってしまうとか、ベテラン開発者がひたすらレビューをし続けるはめになるとか。

GitHubのレビューツールはいいのですが、レビューの促進にはならないので、最近ではレビューの状態をはっきりさせようとか、レビュー依頼の一覧を分かりやすくしようとか、みんなでレビューしようという雰囲気作りをしています。

そのためにやっているのが、レビュー状態ラベルとレビュータイムです。

レビュー状態ラベルは、レビュー状態をはっきりさせるのと、レビュー依頼一覧を分かりやすくする取り組みで、Pull Requestに分かりやすいラベルを付けるというもの。

今まさにレビューして欲しいときに「レビュー依頼」ラベルを付けて、レビューする人は「レビュー中」ラベルを付け、レビューしてコメントを付けたらレビューした人が「レビュー完了ラベル」を。それを見て、レビュー依頼をした人がなにもなければマージ、修正をしたら再レビュー依頼として「レビュー依頼」ラベルを付けると。

issuesはラベル一覧を見ることができるので、いまレビューしてほしいものが分かるようになるのと、自分にアサインされているものの一覧も見ることができます。

みんなでレビューする雰囲気作りのための取り組みとして、レビュータイムをもうけています。レビュータイムは、毎日ランチ後の14時にレビュー依頼タスクを片っ端からみんなで見るものです。

その時間になるとボットに言われてやりはじめると。

レビューのきっかけができて、毎日みんなでレビューするようになりました。

GitHubとリリース

最後にリリースについて。developブランチからmasterにマージしてリリースしていますが、デプロイ自体はコマンド一発でできるようにしています。

ただ、実際にはデプロイ作業以外にもリリースに必要なものがあって、それはマネージャにそもそもデプロイしてもビジネス的にいいですかとか、リリース前に検証環境でみんなで最終確認しましょうとか、そういうのがあるのでなかなか自動化できていなかったんですね。

ですからマネージャに確認せずにリリースしてしまったり、自動化されていない部分を教えないと新人がリリース作業をできなかったり。

そこで最近ではリリース用のPull Requestに手順をまとめるようにしています。developブランチからmasterブランチへのPull Requestを「リリース用のPull Request」と言っていて、リリースされる内容や誰がやったのか、マネージャに確認しましょうと言ったチェックボックスなどのチェックリストなど、これをコマンド一発で作成できるようにしています。