食べログ×クックパッド合同勉強会 に行ってきた #tabepad
はじめて白金台の駅で降りた。なんだこのおしゃれな感じは…。昔は毎日こんなところを通過していのか。
電車を降りててくてく歩いて行くと、そのなかでも目を引くかっこいいビルがあって、そこの5階がクックパッドのオフィス。エレベーターを降りてちょっと曲がるとすぐに広いキッチンがあって、みんなでなにかを作っている。すごく美味しそうな匂いがして、炒めもののいい音が聞こえるする。
19時ちょっと前のお腹の減った僕には辛いくらい。
前置きが長くなったけど、食べログ×クックパッド合同勉強会に行ってきた。30人の狭き門で、抽選に当たって嬉しかった。
発表のタイトルはこんな感じ。
- 「いかにしてユーザ体験を保証するか」クックパッド 高田 悟史さん ([twitter:@satoship])
- 「Jenkins + Selenium + Python on 検索システム」カカクコム 椎野 峻輔さん ([twitter:@shun115])
- 「JavaScriptの継続的インテグレーション」クックパッド 太田 昌吾さん ([twitter:@os0x])
- 「大規模環境でRailsと4年間付き合ってきて」カカクコム 京和 崇行さん ([twitter:@tkyowa])
togetter のまとめはこちら。
ustの録画はこちら。
いかにしてユーザ体験を保証するか
- Status Code : 502 Bad Gateway
- 例えば蛇口をひねったけど、水がでない
- 期待したことができていない
- サーバがエラーを返したり、重かったりする
- 嫌な体験は簡単に与えられる
- 守る
- 進む
- 備える
守る
- 明確な目標を持つ
- 200 msec/req でサーバから返す
- ユーザのことを考えて目標を設定する
- 目標が明確だと意思決定がしやすくなる
- すみずみまで監視する
- リアルタイム監視
- どのくらいのアクセス数があるか
- どれくらいの速度で返却しているか
- モニタリング数を多くし過ぎると見なくなる
- 毎日見るものは少なくする
- 障害時は迅速に対応する
- ユーザ体験を優先する
- 問題解決よりも、復旧させることが大事
- 迅速に対応できるように工夫する
- エラーログを追いやすくする
- スピードには価値がある
- 障害から学ぶ
- 再発防止策を行うまでが障害対応
- 障害はredmineのチケットに登録
進む
- 変化に強い体質
- 継続的にデプロイする
- 1日に10回くらいデプロイしている
- すぐにフィードバックがある
- 変更が少しづつになる
- 問題が起きても原因がわかりやすい
- デプロイルール
- デプロイは 09:30-19:00
- インフラサポート待機
- デプロイしたひとはデプロイ後1時間待機
- 障害が発生してもすぐ対応ができる
- 設定も履歴管理する
- サポートチーム(ユーザと接しているひとたち)と連携する
- 大きな変更をしたときは、変更内容を伝えておく
まとめ
- インターネットの向こうにはユーザがいる
- ユーザ体験を守り、変化に強い体質を作り、将来に備えよう
Jenkins + Selenium + Python on 検索システム
- 自己紹介
- 検索システムでのJenkinsジョブ構成
- ビルドジョブ
- デプロイジョブ
- Seleniumジョブ
ビルドジョブ
デプロイジョブ
- トリガは環境により異なる
- ssh scp で tarball 配布
- 本番の場合L7ロードバランサから切り離してデプロイして繋げ直す(今後やりたい)
Seleniumジョブ
Jenkins自身の構築、運用、注意
- インストールなどは特に問題なし
- JenkinsはAPサーバの実行ユーザで動作する
- JenkinsのHOMEをwarのディレクトリと別にする
- アップデートしたら、いろいろごっそり消えてしまったりしたので
- 更新が早くてついていくのが大変
- LTSを使おうかな
- Jenkinsの認証を使っている
- 通常はユーザ登録はできないようにしている
- 案件が複数走るとtag/trunk/branchの管理が大変
- gitで解決できるかな?
まとめ
- Jenkinsいい!
- 毎回やらなければならないことがなくなる
- Jenkinsが浸透してきた
- デプロイ作業が精神的に楽に
- メンテナンスはけっこう大変
- ジョブが複雑になると大変そう
- 総じていいプロダクト!
JavaScriptの継続的インテグレーション
- 開発基盤グループのお仕事について
- 継続的インテグレーション
- テストの高速化について
- プロトタイプの開発について
- JavaScriptのテスト事情
- あまりされてない
- 実行環境の問題
- テストしにくい(非同期通信など)
実行環境の問題
- 今日のメイン
- JavaScriopt実行環境(railsにおける)
- ブラウザ
- 起動が遅い / 不安定
- JavaScriptエンジン
- DOM(HTML)がない
- Selenium
- 遅い
- headless
- GUIのないブラウザ
- capybara-envjs
- SpiderMonkey
- envjs
- 古いenvjsをフォークしていてマージ不可
- capybara-zombie
- v8(node.js)
- JSDOM
- 最近出てきたばかりでバグが多い
- Akephalos
どれもいまいち、そこで
specを書く
- そのSpecのゴールはなにか
- JSCoverage
- JSファイルの何行目が実行されたかわかる
- 通っていればいいわけじゃないけど、通っていないところはわかる
- どうやってる?
- 各行にカウントアップのコードが入る
- Jenkinsに渡してカバレッジを表示
- おとといくらいにできるようになった!
まとめ
- capybara-webkitとjscoverageで快適に継続的インテグレーション
- 足りない機能はgithubでpull request
- OSS & github は素晴らしい
大規模環境でRailsと4年間付き合ってきて
- 新サービス作りました
- 食べログ
TiDD
-
- はじめて2年半
- いまではないと仕事が回らないくらい
- 2つのカナメ
- No Ticket, No Commit
- カスタマイズしたワークフロー
- 開発プロセスにあった、ワークフローに
- 週2回リリース
- 人数が増えてくるとリリースで問題が頻出
- いつのまにかリリースされていたり
- redmineで自作プラグイン
- リリース範囲のリビジョン、チケットを表示する
- リリース対象のチケットを一覧化
- 過去のリリースを簡単にさかのぼって確認できる
- エンジニア以外の人たちも何がリリースされているか把握できる
- 継続的インテグレーションしたい
- gitへの移行
- デザイナさんの習得コストもあるので、ちょっと難しい
今回はコードに注目
how to
- テスト→グリーン→修正→グリーン OK
- これができたらいいけど、仕様や実装コストの問題で諦めた
- 脱リニューアル症候群
- 既存のコードは変えない
- 移動するだけ
- ソースの静的解析で影響範囲を確認
result
- サブシステム単位でデプロイ
- 気軽に変更
- 大規模案件は新しいサブシステム
- ただしサブシステムが多くなって複雑化した面もあった
懇親会
タイ料理!パクチー!おいしい!
まとめ
エンジニアだけじゃなく、ほかのひとでも状況を理解できることは大事だなと思った。
たとえばエンジニアだけではなくデザイナも。たとえばインフラエンジニアだけではなく、開発エンジニアも。お互いの領域をある程度理解することで、いろいろなことを加速させることができる。
最近 ruby / rails を使っていたし、Subversion / Jenkins も馴染みがあるし、JavaScript 好きだし、とても勉強になった。こういう取り組みは、一度に全部やろうと思ってもできないし、そうじゃなくても失敗することはよくあると思う。まずは自分たちでできることから取り入れていきたい。確かに上を見上げれば果てしないのだが、すぐに取り組めるものもいっぱいあると思うので。
次回も是非参加したい。抽選に当たることを祈るばかり。
最後においしいご飯を作ってくださった方々にも感謝、ほんとにおいしかった。