- @mirakui
- 2M recipes
- 52M UB
- 1.6M Premium Service Users
- 1000 EC2
- 15,000 req/s
- 7 ops
- 90+ devs
- 10+ deploys/day
- Rails の人柱
- 1732 models
- レガシーコード、技術的負債
- 放置された Fail テスト
- 属人的デプロイ、デプロイを恐れる
- 素早く価値を提供したい
- x 現場が楽をしたい
- テストああああみたいなテストデータを流し込む
- ダミーデータではなく本番のデータを使って開発する
- 作っているのは機能ではなくサービスである
- 本番と同期した DB
- ユーザと同様の体験
- 予期せぬデータによるバグ、重いクエリ
- 半年ごとに mysqldump -> master-slave
AUTO_INCREMENTに巨大なオフセットを指定することで本番との衝突を回避- ステートメントベースレプリでは開発が壊れるので業ベース
- 本番 -(statement)- binlog変換 -(row)- dev
- スタッフ限定公開, 10%限定
- サービスの価値は使わないとわからない
- 品質とか要らん機能を作ってしまう
- Chanko
- ベータ検証
- エラーが出たら本来の処理にフォールバック
- 価値が認められたら un-chanko
- RSpec
- 1800+ files
- 21000+ examples
- 7 min
- Test smells
- 実行時間が長い
- fail しやすい
- RRRSpec
- 複数の Spot instances
- 業務時間外はインスタンス減らす
- Spot Instance
- オンデマンド価格より高くなることある
- まれにコケる example
- 開いている worker で自動的に再実行
- 1度でも success したら success
- 記録されてる
- 割れ窓理論
- fail した example を blame して通知
- all-night CI
- 10分以上かかったら alert
- pending 通知
- 開発者自身がデプロイ
- 営業時間内のみデプロイ
- 13s -> 150 hosts
- cap
- スケールしない
- 1台から全台に ssh
- mamiya
- S3 に tar を置く
- 全台が tar を pull
- Serf イベントで伝搬
- デプロイはコードベース切り替えてサーバリロードだけ
- スケールする
- 割れ窓を作らないよう、指標を持って改善する
- 開発デプロイのサイクルが早ければ、本番環境を使った開発ができる
- ユーザと同じ体験
- 開発しやすさに投資する価値は十分ある
- 結果として組織もサービスも健全な状態を保てる