Schema Migration — esensi, jenis, dan alat migrasi skema basis data

Apa itu Schema Migration

Schema Migration adalah praktik pengelolaan perubahan struktur basis data melalui file berversi yang diterapkan secara berurutan ke berbagai lingkungan. Setiap file berisi serangkaian perintah SQL: membuat tabel, menambah kolom, mengubah indeks, atau memperbarui batasan. Alat migrasi melacak versi yang telah diterapkan dan menjamin bahwa setiap perubahan dijalankan tepat satu kali.

Tidak seperti Data Migration yang memindahkan konten tabel, Schema Migration hanya mengelola struktur — operasi DDL. Ini adalah perbedaan mendasar: Schema Migration berjalan sebelum Data Migration, membuat skema target, kemudian Data Migration mengisinya dengan data. Menurut Redgate (2024), 62% insiden di basis data production terkait dengan perubahan skema manual tanpa skrip migrasi.

Versi migrasi

Setiap Schema Migration menerima pengenal unik — biasanya versi (V1, V2) atau stempel waktu. Alat menyimpan dalam tabel khusus (flyway_schema_history, alembic_version) daftar migrasi yang telah diterapkan. Saat dijalankan, alat membandingkan daftar dengan file di classpath dan hanya menerapkan yang baru. Idempotensi adalah properti kunci: eksekusi ulang tidak menimbulkan efek samping.

Jenis perubahan skema

Operasi Schema Migration yang umum: membuat tabel (CREATE TABLE), menambah kolom (ALTER TABLE ADD COLUMN), mengubah tipe, membuat indeks, menambah kunci asing, dan memperbarui urutan. Migrasi yang lebih kompleks mencakup mengganti nama kolom dengan mempertahankan data, membagi tabel menjadi beberapa bagian, dan mereplikasi skema ke shard.

Mengapa migrasi skema basis data diperlukan

Tanpa Schema Migration, pengembang mengubah basis data secara manual — menulis DDL di konsol, menambah kolom di lingkungan dev, dan menyalinnya ke staging dari ingatan. Hasilnya: perbedaan skema antar lingkungan, hilangnya perubahan saat deployment, dan migrasi rusak di production. Schema Migration memecahkan tiga masalah kunci: konsistensi, reproduktibilitas, dan audit.

Konsistensi antar lingkungan

Ketika struktur basis data dijelaskan dalam kode, struktur tersebut identik di dev, staging, dan production. Pengembang tidak dapat lupa menerapkan perubahan — alat akan menjalankan semua migrasi yang terlewat secara berurutan. Jika di production sebuah kolom tidak ada tetapi kode membutuhkannya — aplikasi akan error. Pemeriksaan otomatis menghilangkan skenario ini.

Reproduktibilitas untuk pengembang baru

Anggota tim baru menjalankan flyway migrate dan mendapatkan skema terkini dalam hitungan detik — tanpa dump dari production dan kueri DDL manual. Ini sangat penting dalam arsitektur mikroservis, di mana setiap layanan memiliki basis data sendiri dan skema terdiri dari puluhan migrasi. Reproduktibilitas penuh mempersingkat waktu orientasi dari hari menjadi menit.

Audit perubahan

Setiap Schema Migration disimpan di sistem kontrol versi bersama dengan kode aplikasi. Anda dapat membuka Pull Request, melihat perintah SQL yang tepat untuk perubahan skema, dan melakukan code review. Saat terjadi insiden, mudah untuk menentukan migrasi mana yang terakhir diterapkan dan siapa penulisnya. Riwayat Git memberikan jejak lengkap perubahan basis data selama proyek berlangsung.

Alat migrasi skema

Ada puluhan alat Schema Migration di pasaran untuk berbagai bahasa dan platform. Pilihan tergantung pada tumpukan teknologi, format deskripsi migrasi, dan persyaratan rollback. Mari kita lihat kategori utama dan alat populer.

Cara memilih alat

Untuk tumpukan Java/Kotlin — Flyway sebagai yang paling ringan dan dapat diprediksi. Untuk proyek dengan rollback yang sering — Liquibase, yang memiliki rollback bawaan secara arsitektural. Untuk Python/Django — Alembic sebagai alat standar SQLAlchemy. Untuk startup tanpa insinyur DevOps — pilih alat dengan konfigurasi paling sedikit: Flyway hanya membutuhkan file skrip dan perintah migrate.

Solusi komersial

Selain alat open-source, ada solusi komersial: Redgate SQL Change Automation, Datical DB, dan DBmaestro. Mereka menyediakan perbandingan skema visual, resolusi konflik otomatis, dan integrasi dengan pipeline CI/CD. Namun, untuk sebagian besar proyek, Flyway atau Alembic mencakup 100% kebutuhan tanpa lisensi tambahan.

Migrasi dengan Flyway

Mari kita lihat contoh praktis Schema Migration di Kotlin dengan Flyway. Mari buat migrasi yang menambahkan tabel orders ke basis data PostgreSQL. Flyway secara otomatis membuat tabel flyway_schema_history dan melacak versi yang diterapkan.

-- V1__Create_Orders_Table.sql
CREATE TABLE orders (
    id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id         UUID NOT NULL,
    total_amount    DECIMAL(10,2) NOT NULL,
    currency        VARCHAR(3) NOT NULL DEFAULT 'USD',
    status          VARCHAR(20) NOT NULL DEFAULT 'pending',
    created_at     TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    CONSTRAINT fk_user FOREIGN KEY (user_id) REFERENCES users(id)
);

Menghubungkan Flyway di proyek Kotlin melalui konfigurasi dataSource. Setelah konfigurasi, perintah flyway:migrate akan menerapkan semua migrasi baru dari classpath.

// FlywayConfig.kt — Konfigurasi Flyway di Spring Boot
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration
import org.flywaydb.core.Flyway

@Configuration
class FlywayConfig {
    @Bean
    fun flyway(dataSource: DataSource): Flyway {
        return Flyway.configure()
            .dataSource(dataSource)
            .locations("classpath:db/migration")
            .baselineOnMigrate(true)
            .load()
    }
}

Alembic untuk proyek Python

Alembic adalah alat Schema Migration untuk Python, dibangun di atas SQLAlchemy. Fitur utamanya adalah pembuatan skrip otomatis berdasarkan perbandingan model SQLAlchemy dengan skema basis data saat ini. Alembic cocok untuk proyek Django, FastAPI, dan Flask.

Inisialisasi dan pembuatan migrasi

Setelah inisialisasi (alembic init alembic) dan konfigurasi connection string, perintah alembic revision --autogenerate memindai model SQLAlchemy dan menghasilkan skrip migrasi. Pengembang tinggal memeriksa kode yang dihasilkan dan menerapkannya melalui alembic upgrade head. Autogenerate menghemat jam penulisan DDL manual.

# models.py — Model SQLAlchemy untuk pembuatan otomatis
from sqlalchemy import Column, Integer, String, DateTime, Enum
from sqlalchemy.orm import DeclarativeBase
import enum

class OrderStatus(enum.Enum):
    pending = "pending"
    paid = "paid"
    shipped = "shipped"

class Base(DeclarativeBase):
    pass

class Order(Base):
    __tablename__ = "orders"
    id = Column(Integer, primary_key=True)
    status = Column(Enum(OrderStatus), nullable=False)
    created_at = Column(DateTime, nullable=False)

Praktik terbaik migrasi skema

Tim yang berpengalaman telah mengembangkan serangkaian aturan Schema Migration yang mengurangi risiko kegagalan dan menyederhanakan debugging. Mematuhi praktik ini adalah tanda budaya teknik yang matang. Lima aturan kunci mencakup perancangan, pengujian, dan penerapan migrasi.

Satu migrasi — satu perubahan

Setiap Schema Migration harus melakukan tepat satu perubahan logis: membuat tabel, menambah kolom, atau mengubah indeks. Mencampur beberapa operasi dalam satu migrasi mempersulit rollback — jika operasi kedua gagal, operasi pertama sudah diterapkan dan harus dikembalikan secara terpisah. Langkah kecil adalah dasar migrasi yang andal.

Jangan pernah mengedit migrasi yang sudah dipublikasikan

Setelah migrasi diterapkan ke production, migrasi tidak dapat diubah — hanya migrasi baru yang dapat dibuat untuk memperbaiki masalah. Mengedit migrasi yang dipublikasikan merusak pelacak: pengembang dengan basis data lain akan melihat ketidakcocokan hash. Migrasi yang tidak dapat diubah menjamin perilaku yang dapat diprediksi di semua lingkungan.

Pengujian pada salinan production

Sebelum menerapkan Schema Migration ke production, jalankan pada salinan data production. Tujuannya adalah memeriksa kecepatan eksekusi, adanya penguncian tabel, dan kebenaran perubahan. Untuk tabel besar, ALTER TABLE dapat memblokir penulisan selama berjam-jam — pengujian akan mengungkapkannya lebih awal. Staging dengan dump production adalah langkah wajib.

Hindari NOT NULL untuk kolom baru

Kolom baru tanpa nilai default dengan NOT NULL — penyebab umum kegagalan migrasi. Di record yang ada, nilainya akan NULL dan NOT NULL akan menyebabkan error. Praktik terbaik: buat kolom dengan nilai default dan nullable, lalu dengan migrasi terpisah tambahkan NOT NULL setelah data diisi.