Database migration adalah cara mencatat setiap perubahan struktur database dalam berkas berversi, sehingga seluruh tim dan semua lingkungan bisa menjalankannya dengan urutan yang sama. Bayangkan Andi menambah kolom baru di database lokalnya, lalu mengirim kodenya ke repositori. Rina menarik kode itu, menjalankan aplikasi, dan langsung bertemu pesan “column does not exist”. Saat rilis, tim baru sadar bahwa perubahan database tidak pernah dijalankan di server produksi.
Kejadian seperti ini sering muncul pada tim yang mengubah database secara manual. Kodenya dikelola dengan Git, tetapi struktur database hidup di kepala masing-masing orang. Akibatnya, setiap komputer, server staging, dan server produksi perlahan menyimpang satu sama lain.
Artikel ini menjelaskan apa itu database migration, masalah yang muncul tanpanya, lima alasan mengapa konsep ini penting dalam kolaborasi developer, dan cara kerjanya. Anda juga akan menemukan contoh kode dengan Knex, alur kerja tim, cara mengubah database produksi dengan aman, serta kesalahan umum yang perlu dihindari.
Daftar Isi
- Apa itu database migration
- Masalah tanpa database migration
- 5 alasan database migration penting dalam kolaborasi developer
- Cara kerja database migration
- Contoh kode database migration dengan Knex
- Alur kerja tim dengan database migration
- Database migration aman di produksi
- Alat database migration populer
- Kesalahan umum
- Pertanyaan yang sering diajukan
- Daftar periksa
- Kesimpulan
Apa Itu Database Migration?
Database migration adalah praktik mengubah struktur database lewat skrip berversi, bukan lewat perintah manual. Setiap perubahan, misalnya membuat tabel, menambah kolom, atau memasang indeks, ditulis dalam satu berkas migrasi. Berkas itu disimpan di repositori kode bersama aplikasi.
Satu berkas biasanya punya dua bagian. Bagian up menjelaskan cara menerapkan perubahan, sedangkan bagian down menjelaskan cara membatalkannya. Alat migrasi lalu mencatat berkas mana yang sudah dijalankan di sebuah tabel khusus di database. Dengan catatan itu, alat tahu apa yang sudah dan belum diterapkan di lingkungan tersebut.
Cara termudah memahaminya adalah membayangkan Git untuk database. Git mencatat riwayat perubahan kode, sementara migrasi mencatat riwayat perubahan struktur data. Jika Anda belum akrab dengan Git, baca Git Adalah: Pengertian, Cara Kerja, dan 10 Perintah Dasar.
Masalah pada Tim Tanpa Database Migration
Tanpa migrasi, perubahan struktur database biasanya dilakukan dengan cara manual. Praktik ini menimbulkan beberapa masalah yang berulang:
- Database antar-developer berbeda. Setiap orang punya struktur yang sedikit berlainan, sehingga kode yang jalan di satu komputer gagal di komputer lain.
- Perubahan dikirim lewat chat. Perintah SQL ditempel di grup, lalu dijalankan sebagian orang dan dilupakan sebagian lain.
- Staging dan produksi tidak sama. Perubahan yang sudah dites di staging bisa terlewat saat rilis.
- Tidak ada riwayat. Tidak ada yang tahu siapa mengubah apa, kapan, dan mengapa.
- Sulit dibatalkan. Jika perubahan bermasalah, tidak ada langkah pemulihan yang tertulis.
- Anggota baru butuh waktu lama. Menyiapkan database lokal berarti meminta salinan dari rekan, lalu berharap isinya mutakhir.
5 Alasan Database Migration Penting dalam Kolaborasi Developer
1. Database Migration Menyamakan Struktur di Semua Lingkungan
Semua developer, server staging, dan server produksi menjalankan berkas migrasi yang sama dalam urutan yang sama. Hasilnya, struktur database konsisten di mana pun. Masalah “jalan di komputer saya” karena perbedaan skema pun hilang.
2. Perubahan Tercatat dan Bisa Ditinjau
Berkas migrasi masuk ke repositori, jadi setiap perubahan database melewati proses yang sama dengan kode: commit, pull request, dan review. Rekan tim bisa melihat dan mengomentari perubahan sebelum menyentuh data sungguhan. Riwayat Git juga menunjukkan siapa mengubah apa dan kapan.
3. Onboarding Anggota Baru Jadi Cepat
Anggota baru cukup mengambil kode dan menjalankan satu perintah migrasi untuk mendapat database yang siap pakai. Tidak perlu meminta salinan database atau menjalankan skrip SQL satu per satu. Kombinasi dengan kontainer, seperti dibahas di Docker Adalah: Pengertian, Cara Kerja, dan 8 Perintah Dasar, membuat lingkungan lokal lebih seragam lagi.
4. Rilis Lebih Aman dan Bisa Dipulihkan
Perubahan database menjadi bagian otomatis dari proses rilis, bukan langkah manual yang bisa terlupa. Jika terjadi masalah, bagian down memberi jalan mundur yang sudah ditulis dan diuji sebelumnya. Ini mengurangi kepanikan saat rilis berjalan tidak sesuai rencana.
5. Kolaborasi Paralel Lebih Teratur
Beberapa developer bisa mengubah database pada waktu bersamaan tanpa saling menimpa, karena setiap perubahan hidup di berkas sendiri. Konflik muncul di tempat yang tepat, yaitu saat penggabungan kode, bukan secara diam-diam di database bersama. Dengan begitu, kerja tim terasa seperti kerja kode biasa.
Cara Kerja Database Migration
Alurnya sederhana dan hampir sama di semua alat:
- Buat berkas migrasi. Alat menghasilkan berkas baru dengan nama yang berurutan, biasanya diawali penanda waktu.
- Tulis bagian
updandown. Anda menjelaskan perubahan dan cara membatalkannya. - Jalankan migrasi. Alat memeriksa tabel riwayat, lalu menjalankan hanya berkas yang belum pernah diterapkan.
- Catat hasilnya. Setelah sukses, nama berkas dicatat di tabel riwayat.
- Simpan di repositori. Berkas dikirim bersama kode agar rekan lain dan server ikut menjalankannya.
Karena hanya berkas baru yang dijalankan, migrasi bisa dijalankan berulang kali tanpa mengulang pekerjaan lama. Sifat ini mirip konsep yang dibahas di Mengenal Idempotency dalam Programming dan Mengapa Konsep Ini Penting?, yaitu aman diulang dan hasil akhirnya tetap sama.
Contoh Kode Database Migration dengan Knex
Knex adalah query builder untuk Node.js yang juga menyediakan fitur migrasi. Contoh ini memakai PostgreSQL. Pertama, siapkan file konfigurasi. Alamat database sebaiknya dibaca dari variabel lingkungan, seperti dibahas di Environment Variable: Cara Pakai .env di Node.js.
// knexfile.js
module.exports = {
development: {
client: 'pg',
connection: process.env.DATABASE_URL,
migrations: {
directory: './migrations',
tableName: 'knex_migrations'
}
}
};Kedua, buat berkas migrasi baru. Perintah ini menghasilkan berkas berawalan penanda waktu di folder migrations.
npx knex migrate:make tambah_no_telepon_pelangganKetiga, isi bagian up dan down pada berkas itu.
// migrations/20261109120000_tambah_no_telepon_pelanggan.js
exports.up = async function (knex) {
await knex.schema.alterTable('pelanggan', (tabel) => {
tabel.string('no_telepon', 20);
});
};
exports.down = async function (knex) {
await knex.schema.alterTable('pelanggan', (tabel) => {
tabel.dropColumn('no_telepon');
});
};Keempat, jalankan migrasi, lihat statusnya, dan batalkan jika perlu. Menurut dokumentasi Knex tentang migrasi, perintah migrate:latest menjalankan semua migrasi yang belum diterapkan, sedangkan migrate:rollback membatalkan batch terakhir.
# Jalankan semua migrasi yang belum diterapkan
npx knex migrate:latest
# Lihat migrasi yang sudah dan belum dijalankan
npx knex migrate:list
# Batalkan batch migrasi terakhir
npx knex migrate:rollbackPerhatikan bahwa Knex mencatat riwayat di tabel knex_migrations. Tabel inilah yang mencegah migrasi dijalankan dua kali. Jika Anda memakai SQL murni tanpa alat, Anda bisa menulis skrip yang aman diulang dengan CREATE TABLE IF NOT EXISTS atau ADD COLUMN IF NOT EXISTS pada PostgreSQL.
Alur Kerja Tim dengan Database Migration
Alat saja belum cukup. Tim perlu kebiasaan yang disepakati bersama:
- Buat cabang baru untuk setiap fitur yang mengubah database.
- Buat berkas migrasi baru. Jangan mengubah struktur lewat klien database secara langsung.
- Uji bagian
updandowndi komputer sendiri. Jalankan migrasi, batalkan, lalu jalankan lagi. - Kirim kode dan migrasi dalam satu pull request. Reviewer memeriksa keduanya sekaligus.
- Jalankan migrasi otomatis di CI dan staging. Pastikan berkas bisa berjalan dari database kosong sampai terbaru.
- Jalankan migrasi sebagai bagian dari rilis produksi. Lakukan cadangan data sebelum perubahan yang berisiko.
Ada dua aturan emas. Pertama, jangan pernah mengubah berkas migrasi yang sudah dijalankan oleh orang lain atau di server lain. Jika ada kesalahan, buat migrasi baru yang memperbaikinya. Kedua, jika dua cabang membuat migrasi pada waktu hampir sama, periksa urutannya setelah digabung agar tidak saling bergantung secara keliru.
Database Migration Aman di Produksi
Mengubah database yang sedang dipakai pengguna butuh kehati-hatian ekstra. Teknik yang umum dipakai adalah memecah perubahan besar menjadi beberapa tahap kecil yang kompatibel dengan kode lama dan baru. Contohnya mengganti nama kolom nama menjadi nama_lengkap.
-- Rilis 1: tambahkan kolom baru (boleh kosong)
ALTER TABLE pelanggan ADD COLUMN nama_lengkap TEXT;
-- Salin data lama (pada tabel besar, lakukan bertahap)
UPDATE pelanggan SET nama_lengkap = nama WHERE nama_lengkap IS NULL;
-- Rilis 2: setelah semua kode memakai kolom baru, pasang aturan
ALTER TABLE pelanggan ALTER COLUMN nama_lengkap SET NOT NULL;
-- Rilis 3: hapus kolom lama setelah yakin tidak dipakai lagi
ALTER TABLE pelanggan DROP COLUMN nama;Pola ini sering disebut “expand and contract”: tambahkan dulu, pindahkan data, lalu hapus yang lama. Dengan cara ini, aplikasi versi lama dan baru bisa berjalan berdampingan selama rilis berlangsung, sehingga tidak perlu menghentikan layanan.
Ada beberapa kewaspadaan lain. Pada PostgreSQL, membuat indeks biasa pada tabel besar bisa menahan penulisan data, sehingga perintah CREATE INDEX CONCURRENTLY sering dipakai. Perintah itu tidak boleh berjalan di dalam transaksi, jadi pada Knex Anda perlu menonaktifkan transaksi untuk berkas tersebut. Selalu cadangkan data, uji di salinan data yang mirip produksi, dan rencanakan langkah pemulihan sebelum menjalankan perubahan berisiko. Untuk dasar perancangan tabel yang baik sebelum dimigrasi, baca Mengapa Database Normalization Penting dalam Perancangan Sistem?.
Alat Database Migration Populer
Hampir setiap bahasa dan framework punya alat migrasi sendiri. Pilih yang paling sesuai dengan tumpukan teknologi tim Anda:
| Alat | Ekosistem | Ciri singkat |
|---|---|---|
| Knex | Node.js | Migrasi ditulis dengan JavaScript, mudah dipakai dengan Express |
| Prisma Migrate | Node.js dan TypeScript | Menghasilkan migrasi dari skema model |
| Laravel Migrations | PHP | Bawaan framework Laravel |
| Alembic | Python | Umum dipakai bersama SQLAlchemy |
| Flyway dan Liquibase | Java dan lintas bahasa | Migrasi berbasis berkas SQL atau XML/YAML, populer di tim perusahaan |
Jika proyek Anda sudah memakai ORM atau framework tertentu, mulailah dari alat migrasi bawaannya. Jangan menggabungkan beberapa alat migrasi pada database yang sama, karena riwayatnya akan saling bertabrakan.
Kesalahan Umum dalam Database Migration
- Mengubah berkas migrasi yang sudah dijalankan. Riwayat di setiap lingkungan jadi tidak cocok. Buat migrasi baru sebagai perbaikan.
- Mengubah database langsung lewat klien. Perubahan manual tidak tercatat dan tidak sampai ke rekan tim.
- Tidak menulis bagian
down. Saat masalah muncul, tidak ada jalan mundur yang sudah teruji. - Memasukkan banyak perubahan dalam satu migrasi. Migrasi kecil lebih mudah ditinjau dan dibatalkan.
- Menjalankan perubahan destruktif tanpa cadangan. Menghapus kolom atau tabel tidak bisa dibatalkan oleh
downjika datanya sudah hilang. - Tidak menguji dari database kosong. Migrasi harus bisa berjalan dari awal sampai terbaru di lingkungan bersih.
- Mencampur perubahan struktur dengan data besar. Pemindahan data berjumlah besar sebaiknya dilakukan bertahap, bukan dalam satu transaksi panjang.
Pertanyaan yang Sering Diajukan tentang Database Migration
Apa bedanya database migration dan seeding?
Migrasi mengubah struktur database, seperti tabel dan kolom. Seeding mengisi data awal atau data contoh, misalnya daftar kategori atau akun uji. Keduanya sering dipakai bersamaan, tetapi tujuannya berbeda, dan seeding data uji tidak boleh dijalankan di produksi.
Apakah database migration wajib untuk proyek kecil?
Tidak wajib, tetapi sangat membantu. Begitu ada lebih dari satu developer atau lebih dari satu lingkungan, migrasi menghemat banyak waktu dan mencegah perbedaan struktur. Bahkan untuk proyek sendirian, riwayatnya berguna saat Anda lupa apa yang berubah.
Apakah bagian down selalu bisa mengembalikan data?
Tidak. Bagian down mengembalikan struktur, bukan data yang sudah terhapus. Jika migrasi menghapus kolom atau tabel, datanya hilang, sehingga cadangan tetap diperlukan sebelum perubahan semacam itu.
Apakah database migration bisa dipakai tanpa ORM?
Bisa. Alat seperti Flyway dan Knex menjalankan skrip SQL atau kode biasa tanpa mewajibkan ORM. Anda juga bisa menulis migrasi dalam berkas SQL berurutan dan menjalankannya dengan skrip sendiri, asalkan ada tabel riwayat yang mencatat berkas mana yang sudah dijalankan.
Daftar Periksa Database Migration untuk Tim Developer
- Apakah setiap perubahan struktur database ditulis sebagai berkas migrasi?
- Apakah berkas migrasi disimpan di repositori bersama kode?
- Apakah setiap migrasi punya bagian
updandownyang sudah diuji? - Apakah migrasi ikut ditinjau dalam pull request?
- Apakah migrasi dijalankan otomatis di CI dan staging sebelum produksi?
- Apakah ada cadangan data sebelum perubahan berisiko?
- Apakah perubahan besar dipecah menjadi tahap kecil yang aman dijalankan bertahap?
- Apakah tidak ada yang mengubah database produksi secara manual?
Kesimpulan: Database Migration Membuat Kolaborasi Developer Lebih Rapi dan Aman
Database migration mencatat setiap perubahan struktur database dalam berkas berversi, sehingga semua developer dan semua lingkungan memakai struktur yang sama. Dengan begitu, perubahan bisa ditinjau, diuji, dan dibatalkan seperti kode. Anggota baru pun bisa mulai bekerja lebih cepat.
Mulailah dari yang sederhana: pilih satu alat migrasi, hentikan perubahan manual, dan biasakan menulis bagian up dan down. Lalu masukkan migrasi ke dalam proses review dan rilis. Dengan kebiasaan ini, kolaborasi tim terasa lebih tenang karena database tidak lagi menjadi sumber kejutan.
Artikel Lainnya di NgodingDaily
Lanjutkan belajar dengan topik lain yang saling melengkapi:
- Git Adalah: Pengertian, Cara Kerja, dan 10 Perintah Dasar
- Docker Adalah: Pengertian, Cara Kerja, dan 8 Perintah Dasar
- Environment Variable: Cara Pakai .env di Node.js
- Mengenal Idempotency dalam Programming dan Mengapa Konsep Ini Penting?
- Mengapa Database Normalization Penting dalam Perancangan Sistem?
