マイグレーション: スキーマを安全に変える

あなたのスキーマは変わっていきます — カラムを追加し、テーブル名を変え、インデックスを追加します。共有ドキュメントの変更履歴(変更追跡)のようなものだと考えてください: すべての変更が順番に記録され、誰のコピーも同じやり方で最新に揃えられます。マイグレーション とは、そうした1つの変更を記述した、バージョン管理された、繰り返し実行できるスクリプトです。マイグレーションが重要なのは、あなたのノートPC、チームメイトのノートPC、そして本番のスキーマが、同一に保たれなければならないからです。

マイグレーションを安全に保つルール:

• 本番でデータベースを手作業で編集しない。 マイグレーションを書きます。
• マイグレーションは前へ進む。 それぞれが新しいファイルです。すでに実行された古いものを書き換えてはいけません。
• 破壊的な変更は慎重に。 カラムやテーブルを削除すると、データは永久に消えます。先にバックアップを取りましょう。
• 追加的な変更が最も安全。 NULL許容のカラムを追加してもめったに何も壊れません。名前変更や削除は、稼働中のコードを壊しかねません。

マイグレーションは順序のある鎖を成します: それぞれが番号付きのステップで、データベースのすべてのコピーを、ある既知の状態から次の状態へ動かします。だからあなたのノートPC、チームメイトのもの、そして本番が、すべて同一に行き着きます:

   空のDB
      │
      ▼
  ┌────────────┐   ┌────────────┐   ┌────────────┐   ┌────────────┐
  │ 001_init   │ ▶ │ 002_add    │ ▶ │ 003_index  │ ▶ │ 004_bio    │
  │ users      │   │ posts      │   │ on author  │   │ カラム     │
  └────────────┘   └────────────┘   └────────────┘   └────────────┘
   順に適用 ──────────────────────────────────────────▶ 現在
   実行済みのステップは編集しない — 新しいものを追加

Prisma、Drizzle、Rails migrationsのようなツールが、これらを生成・追跡してくれます。任せましょう。

マイグレーションは2つの半分でできています: 適用する変更 (up) と、それを取り消す方法 (down) です。信頼できるツールは両方を生成するので、まずいデプロイがきれいにロールバックできます:

-- up: 任意のbioを追加。稼働中に適用しても安全
ALTER TABLE users ADD COLUMN bio TEXT;

-- down: 取り消す
ALTER TABLE users DROP COLUMN bio;

本当に危険なマイグレーションは 名前変更 と 型変更 です。古いコードと新しいスキーマが一瞬食い違うからです。プロのパターンは、それらを追加的なステップに分割することです: 新しいカラムを追加し、バックフィルし、コードがそれを読むよう切り替え、何も参照しなくなった 後の デプロイでようやく古いカラムを削除します。遅く感じますが、それが滑らかなリリースと、デプロイの最中にすべてのユーザーに500エラーが噴き出すこととの違いです。