How we cook cookpad.com 2016

How we cook cookpad.com 2016

17eb0c1a9d70a94ce95401d046375e3c?s=128

Yoshiori SHOJI

August 26, 2016
Tweet

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

  8. None
  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.”
  57. None
  58. None