Migrasi: Mengubah Skema dengan Aman

Skemamu akan berubah — kamu akan menambah kolom, mengganti nama tabel, menambah indeks. Bayangkan seperti riwayat perubahan yang dilacak pada dokumen bersama: setiap perubahan dicatat secara berurutan, sehingga salinan milik semua orang bisa diperbarui dengan cara yang sama. Migrasi adalah skrip yang bisa diberi versi dan diulang, yang menjelaskan satu perubahan semacam itu. Migrasi penting karena skema di laptopmu, laptop rekan timmu, dan production harus tetap identik.

Aturan yang menjaga migrasi tetap aman:

Jangan pernah mengubah basis data secara manual di production. Tulis sebuah migrasi.
Migrasi bergerak maju. Setiap migrasi adalah file baru; kamu tidak menulis ulang migrasi lama yang sudah dijalankan.
Lakukan perubahan yang bersifat destruktif dengan hati-hati. Menghapus (drop) kolom atau tabel menghapus data secara permanen. Buat backup terlebih dahulu.
Perubahan yang bersifat aditif (menambah) paling aman. Menambah kolom yang boleh kosong (nullable) jarang merusak apa pun; mengganti nama atau menghapus kolom bisa merusak kode yang sedang berjalan.

Migrasi membentuk rantai yang berurutan: masing-masing adalah langkah bernomor yang menggerakkan setiap salinan basis data dari satu keadaan yang diketahui ke keadaan berikutnya, sehingga laptopmu, laptop rekan timmu, dan production semuanya berakhir identik:

   empty DB
      │
      ▼
  ┌────────────┐   ┌────────────┐   ┌────────────┐   ┌────────────┐
  │ 001_init   │ ▶ │ 002_add    │ ▶ │ 003_index  │ ▶ │ 004_bio    │
  │ users      │   │ posts      │   │ on author  │   │ column     │
  └────────────┘   └────────────┘   └────────────┘   └────────────┘
   apply in order ─────────────────────────────────────────▶ current
   never edit a step that already ran — add a NEW one

Alat seperti Prisma, Drizzle, atau migrasi Rails membuat dan melacak semua ini untukmu. Biarkan mereka bekerja.

Sebuah migrasi punya dua bagian: perubahan yang diterapkan (up) dan cara membatalkannya (down). Alat yang bisa dipercaya menghasilkan keduanya, sehingga yang buruk bisa di-rollback dengan bersih:

-- up: add an optional bio, safe to apply live
ALTER TABLE users ADD COLUMN bio TEXT;

-- down: reverse it
ALTER TABLE users DROP COLUMN bio;

Migrasi yang benar-benar berbahaya adalah rename (ganti nama) dan perubahan tipe data, karena kode lama dan skema baru sejenak akan tidak sinkron. Pola yang profesional adalah memecahnya menjadi langkah-langkah aditif: tambah kolom baru, isi datanya (backfill), alihkan kode untuk membacanya, dan baru hapus kolom lama pada deploy berikutnya setelah tidak ada lagi yang merujuk padanya. Terasa lambat, tapi itulah bedanya antara rilis yang mulus dan lonjakan error halaman 500 untuk setiap pengguna di tengah-tengah deploy.

Migrasi: Mengubah Skema dengan Aman

Mau versi offline?