_ GitHub実践入門に倣って実践したこと

去る7月13日に、Github実践入門 の著者である大塚さんをお招きして、pull requestを使った開発についてお話していただいた。

その時、git flow でプロジェクトのリポジトリを運用していて、リリースブランチが、デプロイが面倒だったりなんだりで、なかなか出せずに溜まりに溜まっていた。

ウェブサービスなら、github flowの方が良いし、そうあるべき。

といった話があったので、もっとシンプルに、早く出せるフローにしたいと思ったので、この時聞いた話の中でいくつか実践してみた。

フィーチャーブランチは作ったら、すぐpull requestを出す。

以前は実装完了後のレビューのために、pull requestを使っていた。 それを、まだ完了していない段階で出すようにしてみた。 やってみると、長期的な開発のものから、短期的なものまで色々あり、どれを優先的に見ればいいのかわかりづらかったので、(WIP) や(In Reviewing) とpull requestのタイトルに勝手に追加して回った*1。

これからやることについてpull requestを出しておけば、どんな変更が入る（入りそう）なのかを周知できるし、開始時点でレビューできるので設計時点で指摘できる。pull requestを出した方も、最後に差し戻しをくらうよりかは早めの方が助かるだろう。

レビューで、良いところも書く。

レビューで特に問題を見つけられない場合がある。 実装の規模が小さかったりすり、ちょっとしたタイポなんかだと、指摘事項が出づらい。 そんな時には、レビューで見つけて良かったことや、感謝の気持ちを書くようにした。

言葉で書くだけだと照れくさいので、紹介してもらったLGTMというChrome拡張や、MISAWA::MD を使って楽しい雰囲気を添えている。

ただ「ありがとう！」とか「いいね！」と言うよりも、 とするだけで、雰囲気が変わる*2のがいい。

効果として、何よりも、pull requestのコメントが活発になってきたのが大きい。 コメントのバリエーションが増えたし、ポジティブだし、面白い画像を貼っても良いということでハードルが下がったことが要因だと思う。 それによって、単にpull requestの内容についてだけでなく、コードの書き方とかフレームワークの機能の質問とか、知識共有の場にもなってきてるように感じる。

デプロイを1行のコマンドにした。

github flow とは直接関係無いが、github flowの理想的な状態には自動化されたデプロイによって早く最新の状態をリリースできることが必要不可欠と思い、まずはデプロイツールの見直しをした。

それまでは、複数の一連のコマンドを叩くとデプロイできる状態だった。 これはこれで便利だったんだけども、全体の見直しと、Capistranoのバージョンアップも兼ねて、cap production deploy 一発で出せるようにした。

気軽に各環境にデプロイできるようになったことで、UIや全体の使用感を含めたレビューもやりやすくなった。 それまでは、ソースコードレベルでのレビューになってしまうので、出してみて、「あ、これはわかりづらい…」と気づくことが多かったが、それを事前に気づけるようになった。 また、チーム内のレビューだけでなく、次期リリース予定の機能をリクエストしてくれたユーザーに試してもらったり、など聞きにいけたりと当初想定していなかった利点も出てきた。

最後に

やったことは、デプロイ以外は、特に新しいツールが必要なわけではないが、非常に効果が多きかった。

自分が最終的なリリースについて管理しているので、デプロイの安心感を感じる。 それぞれの機能をチームメンバー全員で作っているという連帯感を感じる。 ユーザーに事前に評価してもらえたり、自分たちが新しい要求に対して、特段の理由も無く対応できるという安心感を感じる。

今回やったことが、成果物の品質や性能というだけでなく、チームの自信に繋がっているように感じている。

参考

【楽天ブックスならいつでも送料無料】GitHub実践入門 ～Pull Requestによる開発の変革 [ 大塚... 価格：2,786円（税込、送料込）