Railsから外れたmigrationを再びRailsに乗せる
渋谷.rb[:20170315]
kaiba @ twitter
お金がなくて居酒屋北海道には行けない 
注意
このスライドは個人の見解であり、関連する組織・業務とは無関係です。
Railsのmigrationとは?
- RubyっぽくDB定義の変更を書ける
- rails g migration xxxx
- db/migrate/20170314123456_xxxx.rb
- DB環境構築、gitで管理
migrationの仕組み
メリットは大きい! Railsに乗るなら是非使いたい機能の一つ！
しかし
rake db:migrateを叩かずalter tableでお願いします。
どうしてこうなった?
migrationを知らなかった?
- migration知ってたけどalter table叩いちゃった?
- 知ってる人はいたけど、知らない人が叩いちゃった?
- Railsを効果的に使うには使い方を知ってないと難しい
- 実は他の言語で作られたDBを持ってきた?
再びmigrationできるようにしたい
作業手順
- 開発環境で新規に
rake db:create db:migrateして作り、migrationから作られるテーブル定義を得る - 現状の本番環境のテーブル定義を得る
- 1,2を比較する
- なんとかして、
db:migrateの結果が、本番と一緒なるように頑張る
テーブル定義の比較(MySQLの場合)
開発環境にて
mysql -uxxxx -p information_schema -e "
select * from COLUMNS
where TABLE_SCHEMA = 'dev_db';" > dev_db.txt
- information_schema に全部入ってる
本番環境にて
mysql -uxxxx -p information_schema -e "
select * from COLUMNS
where TABLE_SCHEMA = 'prod_db';" > prod_db.txt
男は黙ってdiff
diff -u dev_db.txt prod_db.txt
…だとちょっと辛いのでGUI
macだとXcodeのFileMergeが好き。
WindowsだとWinMergeが好き。
ここまではよいが…
方針を決める。気持ちを作る。
- 本番が正しいだろ…だって動いてるし…という気持ちを強く持つ。
- だいじょうぶなんじゃないかな。たぶんだいじょうぶだろ。
足りないmigration
migrationを作ってやる。
indexがない、制約がない、型が違う、エンコードが違う、など…。
実行されてないmigration
- 強い意志で基本捨てる。migrationファイルを消す。
実行されてないmigrationだけど…
- 本番に反映したほうが良いやつは
alter table実行 - メモっといて別のバグ対応としてやるのも良いと思う
何度も rake db:resetを行い、差分がないことを確認していく
差分がなくなったら、開発環境のschema_migrationsの内容を本番環境に入れてやる
- migration実行済みの状態にしてやる
insert into schema_migrations
(versions) values
(20170123...),(20170124...),(20170125...);
migration職人の夜は遅い
- 単調だが集中力のいる作業
- 精神的負担(ミスったらサービスが死ぬ可能性もある)
- こうしてひとつひとつ丁寧に作られたmigrationファイルには温かみがある。
どうしてこうなった？しないためには
- Railsチュートリアルやる
- レビューする
- 誰でもDBに
alter tableできる状態にしない
Thanks!
逆にQuestion
- RailsじゃないアプリのDBをRailsでも見たい。
- そんなことしちゃダメ?
勉強会あとにもらったアドバイス
- 本番が正なら
rake db:schema_dumpというのがあり、本番のmigrationを作り、それをｶﾞｯと正としてしまうのもいいかも。 - RailsのDBは、id、updated_at、created_atは必須ではない。RailsじゃないDBを見るのもありだと思う。