クックパッド株式会社様で開催された「chanko勉強会」に参加してきました #chanko
クックパッド株式会社様で開催されたchanko勉強会に行ってきました。
chanko以前は、本番サービスとは別の閉じた環境(社内のテスト環境のような)を作って新機能などの仮説検証を行うという、普通の開発スタイルであったのが、
- 本物のユーザからのフィードバックを得ることで、より正確な仮説検証を行う
- また、その際に実験的機能が他の機能に影響を与えることのないこと
を可能とするために、chankoが開発・導入された。これによって、速く、正確な仮説検証サイクルを回せるようになったとのこと。このあたりは、まさに『リーンスタートアップ』にしつこく語られているような内容で、それを、書籍刊行以前から開発・導入していたのはすごいなと思う。単によりよいプラクティスを実践していたら、それがいつの間にか名前をつけて呼ばれるようになっていたという感じで、開発スタイルかくあるべしという話。
たとえば、検索フォームをどう見せるのが効果的かということで、表示のだしわけをするという事例が紹介された。一定の手続きを踏みさえすれば(100人以上のユーザが使う機能についてはちゃんとテスト書くとか)、どんどんmasterにmergeして機能の仮説検証を行っているのだという。それも、chankoが他の機能に影響を与えることがないように作られているからこそ可能となっているのでしょう。開発速くて、よさそう。
chankoの使い方自体は、上記githubのREADMEにある通りで、それ見りゃいいという感じなので割愛。その他、気になっていたことに対する答えがいくつか提示されていたので、よかった。
- Rails Engineでできるのでは？ → 他の機能に影響を与えないという安定性を最も重視して開発しているところが違う
- デプロイの頻度は？ → 多い日は10回とか。JenkinsによるCIを通ったら任意のタイミングでデプロイ可能なので、どんどんデプロイできる
- どんぐらいchankoで動いている機能があるのか → 30〜40が同時並行で動いている
- varnish/squid的なキャッシュはどうすんの？ → 特定のcookieを付与することで、別のユーザ群のレスポンスが混じらないようにしている
- エラーログどうしてるのか → メインのコードとchanko拡張のエラーログが混じらないようになんかしてる(chanko自体でなんか対応しているわけではないそうな)
- 仮説検証の結果、機能が採用になったら、chankoのコードはどうなる？ → chankoに残すのではなく、メインのコードにmergeする(そんなに大変ではないとのこと)。
- 実験的機能用のmigrationとかどうしてるのか → migration使ってない
migration使ってないというのは、大規模サービスならそりゃそうだよなーという感じ。なんかおもむろにproductionでrake db:migrateとかしちゃったら「1時間サービス止まりました」とかあり得るだろうし。
帰りは、白金台から青葉台まで酔いさましに歩いて帰っていたのだけど、その時に思いついた疑問。
- 30〜40も機能が動いていたら、viewの中でinvoke(機能名, メソッド名)みたいなのが大量に発生することになるだろうけど、その実体のファイルを探して開いたりするの、だいぶだるいことになりそう。
- A/Bテスト的な感じで表示のだしわけをした結果(Aが◯%、Bが×%)みたいなのって、どうやって記録、統計とってるんだろう。ログ投げるのはfluentdなんだろうけど、その際のタグ付けのルールとかどうしてるのか。カオスになりそう。
という話はさておき、@mrknさんによる発表の後は、発表会場のすぐ後ろの巨大キッチンで作成されたおいしいご飯などをいただいて、大変ごちそうさまでございました。東証一部上場企業の部長様や@takaiさんとか、隣席のるびりすとの元同僚さんなどともお話させていただいて、楽しかったです。どうもありがとうございました!!1
