2016年9月23日金曜日

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

15:54    No comments

引用元：
http://blog.madoro.org/mn/93

17th Oct, 2013 (Updated on 4th Mar, 2016) | 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)の外へ出たくない、という方針。
この辺りって、絶対的に正しい方法というのはなく、組織のサイズとかサービスの規模に応じて、ダイナミックに変えていくのが正しい道だと思っている。
追記: CircleCIで上記のことをする方法書いた

引用元：
http://blog.madoro.org/mn/95

CircleCIでfeature branchをHerokuに継続deploy
15th Mar, 2014 (Updated on 4th Mar, 2016) | development heroku circleci
最近CIサーバーを自前Jenkinsから CircleCI に移した。CircleCIとても便利で簡単なのでオススメ。
CircleCIには普通のheroku deployは内蔵されているのだけど、 非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 、をやるにはちょっと工夫が必要。
色々書こうと思ったけど、めんどくさくなったのでscriptを晒しておくだけにしよう！
この中で使われているスクリプト関連、特に秘密にする部分もないのでpublicでgithubに置いている。 https://github.com/quipper/deploy-support-tools
/circleci.yml
deployment:
  feature:
    branch: /^(?!^master$).+$/
    commands:
      - ./script/staging_deploy.sh
  production:
    branch: master
    commands:
      - ./script/production_deploy.sh
/script/staging_deploy.sh
#!/bin/bash -e

STAGING_APP_PREFIX="hoge-cms"
NUM_OF_STAGING_SERVERS=4

DEPLOY_SCRIPT=/tmp/deploy.$$.sh
curl https://quipper-deploy-support-tools.herokuapp.com/scripts/staging_deploy.sh.txt > ${DEPLOY_SCRIPT}
. ${DEPLOY_SCRIPT}

function prepare_for_staging_server() {
  heroku addons:add redistogo:nano || : # nothing if it's already installed
  heroku labs:enable user-env-compile
  heroku config:add \
      FOO=bar \
      BAZ=hoge
}

deploy
/script/production_deploy.sh (これは普通にdeployするだけのscript)
#!/bin/bash -e

HEROKU_APPS="<heroku app name1> <heroku app name2>"

DEPLOY_SCRIPT=/tmp/deploy.$$.sh
curl https://quipper-deploy-support-tools.herokuapp.com/scripts/production_deploy.sh.txt > ${DEPLOY_SCRIPT}
. ${DEPLOY_SCRIPT}

deploy
上のスクリプト、CircleCIのheroku deployの仕組みは使っていないので、HerokuのSSH keysの登録と、 上記スクリプトから参照される HEROKU_API_TOKEN と HEROKU_USERを、CirclCIのEnvironment variablesに設定する必要ある。

0 コメント:

コメントを投稿