453
ロードバランサで複数のWEBサーバに処理を分散していて、WEBサーバは一つのDBサーバを参照しているrailsアプリがあります。

運用している中で、テーブルのカラムを削除する必要がある場合、マイグレーションファイルでremove_columnをすると思うのですが、
capistranoで全てのWEBサーバにデプロイする中で、デプロイ対象のWEBサーバが多いとWEBサーバでは削除したカラムを参照しますが、
DB側はrake db:migrateが実行されたためにカラムが削除されているという状況が発生するような気がしています。

このような事象が発生しないように複数サーバへのデプロイを行うにはどうすればよいでしょうか？
CC BY-SA 3.0
2014-12-08T03:28:47.973
435
2014-12-09T15:00:12.367
189
question
ruby ruby-on-rails デプロイ
DBスキーマの変更で発生するソースコードとDBスキーマの不整合をデプロイ時にどうやって解決するか？
すぐには消さない、という戦略が考えられます。

リリースを2回に分け、  
1回めのリリースで、すべてのアプリケーションサーバを、そのカラムにアクセスしない版に更新します。  
次のリリースで、要らなくなったカラムをDBから実際に消す、という寸法です。

カラム名の変更についても、基本的には同じ考え方が適用できるかと思います。

# いっぺんにやってひどい目にあったことが何度か (´・ω・`)
CC BY-SA 3.0
2014-12-08T08:14:16.953
453
2014-12-08T08:19:42.723
2014-12-08T08:19:42.723
208
208
435
answer
単純なカラム削除や追加であれば、KoRoNさんの回答の通り、アプリ側とDB側のリリースを分けたり、自動マイグレーションであれば2回に分けて段階的にリリースするのがセオリーですね。

追加情報として、カラム名の変更や、より複雑なスキーマ変更に関しては、ちょうどそういったDBの変更技法を扱った「データベース・リファクタリング」という書籍があり、一冊丸ごと様々な手法が紹介されています。

<http://amzn.to/131cVYy> (AA)

以前にこの本の読書会が何回か開かれたようで、日本語の情報もあります。

  * [読書会の参加記録と講演メモ](http://makopi23.blog.fc2.com/blog-entry-11.html)
  * [トリガー (上記の本で紹介されている手法) を使わずにカラム名を変更する例](http://dqn.sakusakutto.jp/2012/03/database_refactoring.html)
  * [読書会で使われたスライド](http://www.slideshare.net/daisuke_m/20120830-db)
CC BY-SA 3.0
2014-12-09T06:32:52.313
479
2014-12-09T15:00:12.367
2014-12-09T15:00:12.367
30
972
435
answer