How we cook cookpad.com 2016

http://cedec.cesa.or.jp/2016/session/PRD/11836.html

Transcript

1. 何故 クックパッドの サービス開発の進化は 止まらないのか 庄司 嘉織 ∠
2. 庄司嘉織 yoshiori 2001 組み込み系 プログラマ 2002 Borland Conference Tokyo で発表 2003 SI へ転職
3. 2007 Java-ja コミュニティ立ち上げ 2009 ドワンゴへ転職 Web+DB PRESS で特集1 執筆 2011 ニコニコ静画 （電子書籍） リリース 2012 クックパッド へ転職
4. 2014 Developers Summit で発表（ベストスピーカー） Developers Summit 関西 で基調講演 2016 CEDECで発表 イマココ ∠
5. クックパッドについて 2,450,000 cooking recipes 61,090,000 monthly unique visitors 1,850,000 PS user
6. 世界のクックパッド
7. 13 languages 55 countries
9. 世界一
10. 世界一巨大な モノリシック Rails サイトでもある （かも知れない） https://speakerdeck.com/a_matsuda/the-recipe-for-the-worlds-largest-rails-monolith
11. rake stats >
12. なぜ Ǹ Ruby なのか スクリプト言語としては早い方 Ȑ 多分 Java や ASP にすると サーバ台数半分くらいに出来る
13. コンピュータ資源を使い切りたい Ȑ 素早く価値を届けたい サーバコストを安くしたい 何を優先するか
14. 素早く価値を届けたい コレは資源の有効活用や サーバコスト削減の努力を 怠っているわけではありません。 素早く価値を届けることを最優先事項とし、 それを最大限活かせる形で コスト削減などを 日々努力しています。
15. 開発 テスト デプロイ
16. 開発の基本的な流れ 開発用ブランチを切る 追加修正をしコミット ∠ ∠
17.  開発環境には 本番のデータが 常にレプリ されている http://techlife.cookpad.com/entry/2014/10/03/110806
18. ダミーデータやテストデータでは サービスの価値はわからない データが 大量なときに 遅くなるなども 発見
19. 開発の基本的な流れ 開発用ブランチを切る 追加修正をしコミット ∠ ∠
20. Pull Request を作成し レビューしてもらう リリースブランチに マージ CI でチェック ∠
21. レビュー対象 リリース対象となるブランチにマージされる コードはすべてコードレビューされる必要が ある。ただし、簡単な文言修正や緊急度の 高いものはテストが通ればマージして良い。 レビュー時 必ず返信がほしい、もしくは修正してもらい たいものは [MUST] をつける。逆に今は修 正しなくていいが次に弄るときは気にして おいてほしいことのような気軽なものには [nits][IMO]などをつける レビュー相手 他のチームとの連携や、専門分野外なの で識者にレビューしてもらいたいときはその 人達にも mention すること。 ȑ マージ LGTM を貰ったら自身でマージする。 また [MUST] が付いていない修正箇所は レビュー相手に再度確認を求める義務は なく自身の裁量で修正、マージして良い。
22. 機械的にチェックできるのもは 機械にチェックさせる
23. iOS, Android は dokumi 使って チェック cookpad/dokumi
24. DeployGate などへの 自動アップロードにも対応 cookpad/dokumi 実機ですぐ チェックできる デザイナや ディレクタも
25. もちろん Pull Request 毎に CI も通す
26. Pull Request を作成し レビューしてもらう リリースブランチに マージ CI でチェック ∠ ∠
27. 2,000+ 20,000+ FILES EXAMPLES ̓ MINITS cookpad/rrrspec 分散テスト実行システム
28. Pull Request を作成し レビューしてもらう リリースブランチに マージ CI でチェック ∠ ∠
29. 本番デプロイ CI が通ると Staging に 自動的にデプロイされる ので動作確認 ∠ ∠
30. sorah/mamiya 150+ hosts 13 sec 高速デプロイシステム Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ Ȑ
31. デプロイは開発者自身で行う 業務時間中のみデプロイ出来る デプロイはチャットでボットに言うだけ ロールバックもボットに言うだけ
32. 本番デプロイ CI が通ると Staging に 自動的にデプロイされる ので動作確認 ∠ ∠
33. 90+ 毎週約 90 個の Pull Request が 取り込まれている *クックパッド本体のみの数字です
34. 30+ 課金や認証、 ユーザーサービスなど 30 以上の アプリケーションが 動いている
35. 10+ 毎日 10 回以上 デプロイされている *クックパッド本体のみの数字です
36. 「デプロイしたら終わり」ではない
37. スタッフだけ、 特定のユーザーにだけ 開発中の機能を 簡単に 公開できる cookpad/chanko 安全に簡単に
38. ユーザーさんが ご意見、ご感想を書くためのフォームを サービスの奥に隠すのではなく すぐに書ける場所に置く フォームへの投稿は 専用のチャンネルなどに流すのではなく、 常に眼に入るように サービス担当者が 普段から使っているチャンネルに流す
39. 素早く価値を届けたい
40. 2 年半前、発表した時は dokumi も rrrspec も mamiya も無かったし チャットでデプロイも 出来なかった
41. 進化する 文化
42. 情報共有 Blog と Wiki の機能を持った社内ツールがある。 Wiki だけでなく Blog があるのでストックスべき情 報とフロー情報を分けて書ける。それが別のサービ スとしてあるのではなく、同じ所にあるため全員そ れを見れば良いし誰でも自分の意見を発信できる
43. 全社的に 1Password が 導入された
44. 意見交換 提案は最近は github/issues で行われる。議論と して追いやすく、後から経緯を見ることもできる。 チャットで話し始めたあとに issue に移行する場合 もある
45. 社長も創業 者もアカウント 持ってるし 使っている
46. 雑 ɔ http://techlife.cookpad.com/entry/2015/03/25/202709 決して低品質な仕事をしたり、誰かに迷惑をかけた りすることを指しているわけではありません。日頃か ら発言のハードルが低く、気軽に意見できることが 重要なのです。
47. zatsu リポジトリに 雑に issue を立て ていく
48. 昼飯や 飲みに行った時の 貸し借りも
49. 行動する ユーザーのため、会社のために正しいと思ったら 自分の意志で行動出来る。 怒る人は居ないし、助言してくれたり助けてくれる。 賛同したら一緒に動いてくれる。 Ŏ
50. Tech ブログ英語版 作ったぜ！と言ったら いろいろな人が 書き出している
51. 社外のエンジニアにも貢献すること OSS 活動、執筆や講演などの社外への貢献も評価 の軸の1つです。 そういったことが許されているとかのレベルではなく 会社がそれを望んでいます。
52. 今日ご紹介した 以外にも 多数
53. オープンである
54. 平等である Ŏ ɔ
55. 素早く価値を届けたい
56. –Grace Hopper
 http://en.wikiquote.org/wiki/Grace_Hopper “It's easier to ask forgiveness than it is to get permission.”