マイグレーションは、データベースの構造の変更を手順書としてコードに残し、どの環境でも同じ順番で同じ状態にそろえられるようにする仕組みです。建物の改修工事を手順書に起こしておけば、別の建物でも同じ手順で同じ状態にでき、問題があれば手順を逆にたどって戻せる。それをデータベースでやります。
手で直さず手順書にする理由
開発が進むと、データベースの構造は何度も変わります。新しい機能のためにテーブルを足す、項目（カラム）を変える、検索を速くするための設定（インデックス）を加える。
こうした変更を、その場で SQL を打ち込んで直していくと、開発環境、ステージング、本番で、少しずつ構造がずれていきます。誰がいつ何を変えたのかも分からなくなります。
「users テーブルに email カラムを追加する」という変更をマイグレーションのファイルに書いておけば、どの環境でも同じコマンドを実行するだけで同じ構造になります。チームの全員が手元の環境を同じ構造にそろえられ、過去の変更履歴もあとから追えます。アプリの新しいバージョンをデプロイするのと一緒に実行されることが多い作業です。
本番で流す前に確かめること
本番のデータベースは、お客さんのデータが入った建物です。改修工事の前には、次の準備をしておきます。
- バックアップを取る。失敗したときに、データごと戻れる状態を作っておく
- 元に戻す手順（ロールバック）も一緒に書いておく
- ステージングで一度流して、動作を確かめる
- データの量を見積もる。本番のようにデータが大量にあると、カラムを1つ足すだけでも時間がかかることがある
特に慎重になりたいのが、カラムの削除やデータの型の変更です。既存のデータが消えたり壊れたりすることがあり、手順書を逆にたどっても元のデータは戻りません。
チームで開発していると、複数人が同時にマイグレーションを追加して、適用の順番がぶつかることもあります。取り込むときに、順番が正しいかを確かめてください。