# IMVU エリック・ライズが共同設立しCTOを務めた企業。『ウェブオペレーション』4章「継続的デプロイ」において、継続的デプロイのプロセスとインフラを実践する具体例として繰り返し登場する。デプロイのツールやプロセスを改善することで、ほとんど機能停止しなくなったと述べられており、その基盤は次の5つの防御レベルで構成される。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] §4.4) 1. エンジニアが自分のサンドボックスを持ち、できるだけプロダクション環境に合わせ、差異が出たときは「5つのなぜ」で原因を調べる。 2. ユニットテスト・受け入れテスト・機能テスト・パフォーマンステストを行い、テスト駆動開発(TDD)を全チームで実践する。 3. 継続的統合専用のクラスタを用意し、チェックインごとに全テストを実行、失敗したリビジョンはデプロイしない。 4. 「[[クラスタ免疫システム]]」と呼ばれる完全自動デプロイシステムで、変更をマシン1台ずつ順番にデプロイし、問題があれば拒否・リバートする。 5. Nagios による静的閾値では調整が難しいメトリクスを、過去データから予測する動的アルゴリズムで基準値超過時のみアラートする。 (Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] §4.4) エンジニアが問題のあるコードをチェックインすると、10〜20分後にクラスタ免疫システムから「あなたのチェックインをリバートしました」という趣旨の自動メールが送られ、チーム全員にアラートで通知される運用が紹介されている。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] §4.4) 昔ながらの「ベストプラクティス」に固執し、ブランチを最後に統合すればよいと主張する社員を雇ったことがあるが、大きなバッチをチェックインしては統合時の衝突を繰り返す「コードバウンシング」を数週間のうちに自ら経験し、考えを改めていったというエピソードが語られている。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] §4.5.1) ## 関連 - ソース: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 4 継続的デプロイ]] - 実体: [[Eric Ries]] / [[クラスタ免疫システム]] - 概念: [[継続的デプロイ]]