2015年9月13日日曜日

非開発者もGitHub Flowに巻き込んでみんなハッピーになった話

22:16    No comments

17th Oct, 2013 (Updated on 4th Jul, 2015) | development heroku github
前提: GitHub flow を使っていてCIサーバーはJenkins
最近ちょっと開発フローの改善をして、とてもよく機能してて満足しているので紹介してみる。
この改善をやる前の悩み:
  1. pull-requestでコードレビューはできるのだけど、cssとかjavascriptなどの見た目や動作の変更ってコードだけだとわかりにくい。レビューする人が各自ローカル環境で実行するのもだるい。
  2. コードを読まないデザイナーとかプロダクトオーナーとかの人が、pull-requestのレビュープロセスに簡単に参加できない(非開発者全員のところでローカル環境設定するのはだるすぎる)。
  3. コード的にokに見えてmasterにmerge後、何か問題(特に仕様的な問題や、デザイン的な問題)が発生した場合、「修正branchを作ってpull-request」というフローを再度回さないといけない。最初のpull-requestで非開発者の人を巻き込めたらそこで気付けるのに。
これらの問題を解決するのに、feature branchもHerokuにJenkinsから自動的にデプロイするようにしたら色々幸せになれた。
具体的には、N個(N=アクティブな開発者の数くらいが良さそう)のfeature branchのテスト用のHeroku appを予め作っておいて、feature branchにpushされるたびに、Jenkinsからその中の一つへデプロイされる感じにした。
補足:
  1. 同じfeature branchの新しいpushがなるべく同じHeroku appにデプロイされ続けるようにとか、heroku configもするとか、多少工夫してる。
  2. 初期の頃、feature branch毎にJenkinsから毎回heroku createしてたが、それはさすがに怒られそうなので、複数をローテーションで使うようにした。
  3. いまどき？だとJenkinsで動的に仮想環境とか作っちゃうのもありだと思う。でも、Herokuが楽過ぎて頑張って仮想環境作る必要もないかな、というのが現在の弊社の状況。
非開発者にもレビューして欲しいときは、pull-request上でmentionして、heroku上のデプロイされたものを見てもらう感じ。基本的にUIに変更のあるようなものは非開発者もチームほぼ全員見るようにしている。
数ヶ月運用してるけど、もうこれなしでは生きるのが辛い感じにまでなってきてる。
非開発者の人もとても楽になった感じで、それまでは、色々な変更が入った(または肝心なものがコミュニケーションの問題で入っていない)masterブランチが動作しているのを見るしかなく「何が」実際変更されたのかわかりづらかったが、このフローにしてから、変更点がわかりやすく開発者とのコミュニケーションもだいぶ楽になった。また、チームメンバーの誰かが「思ってもみなかった」変更がいきなり入ってしまうということもなく、だいぶストレスが減った感じ。
また、開発者も、それまでは、merge後、非開発者に指摘されると「めんどくせーなー」という意識が生まれがちで、かつ、その場合mergeから時間が経っていることも多く、その変更に対するフレッシュさが減り、再度作業を始めるまでの心理的な負担(実際、実装を思い出すための脳のコストも高そう)も高かった。それが、pull-request中に非開発者からフィードバックが貰えることで、そのpull-requestにcommitを追加することだけでさくっと修正できて、全体のスピード感がとてもあがったし、開発者の負担も減った。
つまり、pull-requestのmergedがチームメンバー全員にとってのDONEというステータスになり「実装終わったけどまだ本番には入っていない」とか「チームメンバーが納得してないものが本番に入っちゃった」みたいな事故/ストレスを減らせた。Done means DONE!
これらの結果、masterにmerge後、Jenkinsからの自動デプロイもかなり安心してできるようになった。
おまけ:
@hsbtさんが いい感じのGitHub flowベースのワークフローをあげていたので、弊社(Quipper)との差分を書いてみる。
  1. masterブランチは常にデプロイ可能な状態でかつ自動デプロイされている。
  2. なので、手でデプロイという作業は発生しない。
  3. WIPのpull-requestはそれほど推奨してない。この辺はpull-requestの粒度の話もあるので別エントリで書きたい感じ。
  4. 関連して、チェックリストみたいのも基本作らない(必要ない)。
  5. mergeはレビューした人が行う。
  6. コードレビュー以外のテストも上に書いたように、feature branchでしてしまう。
  7. インフラメンバーいない。(が、そろそろ欲しい！ 興味ある人ご一報を)。
  8. Release’s notes 作成してない。
フローの中でGithub(とJenkins)の外へ出たくない、という方針。
この辺りって、絶対的に正しい方法というのはなく、組織のサイズとかサービスの規模に応じて、ダイナミックに変えていくのが正しい道だと思っている。

0 コメント:

コメントを投稿