Belajar Database Administrator - Database Version Control & Change Management

#Pendahuluan

Bayangkan aplikasi dikelola dengan git — tapi perubahan tabel database dilakukan dengan psql manual di server produksi. Siapa yang membuat kolom itu? Kapan? Apa yang terjadi di rollback? Tidak ada yang tahu. Inilah masalah yang diselesaikan database version control: skema diperlakukan sebagai kode — versi, review, dan deploy otomatis.

Di episode 14 kita mengelola infrastruktur sebagai kode; sekarang giliran skema. Kombinasi keduanya (episode 14 + 17) menghasilkan database yang born from code, changed by PR, deployed by pipeline — fondasi praktik engineering modern yang sangat dicari.

#Migration-Based Schema: Konsep

Prinsipnya sederhana: setiap perubahan skema ditulis sebagai migration (file teks bernomor berurutan), dan tool memastikan setiap migration dijalankan tepat satu kali, dalam urutan. Skema database = urutan migration yang sudah dijalankan.

Perbandingan dua tool populer:

Prinsip yang sama di kedua tool: file migration tidak boleh diubah setelah dijalankan di production — jika ada salah, tulis migration baru untuk memperbaikinya, bukan meng-edit yang lama.

#Flyway: Studi Kasus

Struktur project migration dengan Flyway:

db/migration/
├── V1__create_users.sql
├── V2__create_orders.sql
├── V3__add_status_to_orders.sql
└── V4__add_index_orders_status.sql

V1__create_users.sql:

CREATE TABLE users (
    id         BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    email      TEXT NOT NULL UNIQUE,
    full_name  TEXT NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

Jalankan:

flyway -url=jdbc:postgresql://db:5432/appdb \
       -user=admin -password=*** migrate

Perhatikan: konvensi penamaan V{nomor}__{deskripsi}.sql membuat urutan eksplisit. Flyway mencatat checksum — jika file di-edit setelah dijalankan, ia menolak (proteksi penting!). Di Python, padanannya: alembic revision -m "create users", lalu isi upgrade/downgrade, lalu alembic upgrade head.

#Review Flow: Perubahan Skema via Pull Request

Migration harus melalui review — seperti kode aplikasi. Flow yang sehat:

1. Developer menulis migration + PR ke repo db-migrations.
2. CI menjalankan migration di database uji kosong dan memverifikasi sukses (dan bisa di-upgrade dari skema sebelumnya).
3. DBA mereview: penamaan konsisten (episode 4), index dibuat sesuai query (episode 4/6), tidak ada ALTER TABLE ... DROP COLUMN berbahaya, tidak ada perubahan yang memaksa downtime.
4. Merge → pipeline deploy ke staging, lalu production (window).

Checklist review DBA yang praktis:

• Migration bersifat idempotent-safe? (Idealnya ya, tapi tracking tool menjamin sekali jalan — jangan CREATE TABLE IF NOT EXISTS sebagai pengganti tracking.)
• Ada UPDATE/DELETE massal dalam migration? Itu operasi data, bukan skema — dan berisiko lock. Pindahkan ke script terpisah.
• Kolom baru NOT NULL tanpa default? = downtime (lihat bagian expand-contract).
• Perlu backfill? Kolom baru dengan default konstan dulu, backfill bertahap, lalu ubah constraint.

#Expand-Contract: Migration Tanpa Downtime

Ini keterampilan paling berharga di episode ini. Masalah klasik: menambah kolom NOT NULL di tabel besar mengunci tabel (lock) selama migrasi — aplikasi macet. Solusinya expand-contract:

1. Expand: tambahkan kolom nullable (atau dengan default), tanpa memberitahu aplikasi — aman, tanpa lock berat.

ALTER TABLE orders ADD COLUMN status TEXT;
CREATE INDEX idx_orders_status ON orders (status);

2. Backfill: isi nilai bertahap di luar jam sibuk.

UPDATE orders SET status = 'pending' WHERE status IS NULL
  AND id BETWEEN 1 AND 100000;

3. Contract: ubah NOT NULL + tambahkan ke default privileges, lalu rilis aplikasi yang memakai kolom itu.

Pola yang sama berlaku untuk rename kolom (buat kolom baru, dual-write, cutover) dan mengganti constraint. Inilah cara tim besar berdeploy setiap hari tanpa maintenance window.

#CI/CD untuk Database

Pipeline migrasi yang sehat:

name: db-migrate
on:
  push: { branches: [main] }
 
jobs:
  migrate-staging:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Jalankan migrasi ke staging
        run: flyway -url=$STAGING_DB_URL -user=$STAGING_DB_USER migrate
 
  migrate-production:
    runs-on: ubuntu-latest
    environment: production
    needs: migrate-staging
    steps:
      - name: Jalankan migrasi ke production
        run: flyway -url=$PROD_DB_URL -user=$PROD_DB_USER migrate

Poin penting dalam pipeline:

• Staging selalu migrasi dulu — production tidak pernah jadi tempat uji pertama.
• Environment production diberi approval/guard — manusia menekan tombol di window yang disepakati.
• Gagal? Rollback dengan skema — migration DB tidak selalu bisa di-rollback seperti kode; gunakan migration down (Alembic) atau migration korektif (Flyway), dan selalu punya strategi (pola episode 11).
• Uji otomatis skema baru terhadap query kritis sebelum deploy ke production.

#Pitfall Umum

1. Migration di-edit setelah dijalankan: Flyway akan menolak (checksum), dan riwayat jadi tidak jujur. Buat migration baru.
2. Migration berisi operasi data besar: UPDATE jutaan baris di migration mengunci tabel dan memperlama deploy. Pisahkan jadi backfill batch.
3. Not NULL tanpa default langsung: lock panjang = downtime. Pakai expand-contract.
4. Tanpa uji di CI: migration yang lolos di laptop DBA tapi gagal di staging adalah kejadian biasa — otomatiskan uji.
5. Rollback yang tidak pernah dipikirkan: selalu tulis rencana: "kalau migrasi V12 meledak di production, apa langkah kita?"

#Penutup

Inti yang harus dibawa pulang:

• Skema adalah kode: migration bernomor urut (Flyway/Alembic), dijalankan sekali, direview via PR.
• Review DBA fokus pada: penamaan, index, lock, dan operasi data dalam migration.
• Expand-contract memungkinkan migrasi tanpa downtime — kunci deploy harian di tim besar.
• CI/CD: staging dulu, production dengan guard, backfill terpisah, dan rollback plan wajib.

Di episode 18 selanjutnya kita menyegel jaringan: network security & TLS — firewall dan private networking VPC, konfigurasi TLS/mTLS yang benar, serta VPN peering untuk menghubungkan lingkungan tanpa membuka port ke internet. Sampai jumpa di episode 18!