Runbook

Perhatian

Halaman ini sengaja generik. Hasil eksekusi nyata (tanggal, jumlah data, ID proses, host/project aktif) tercatat di catatan rilis internal tim, bukan di sini — lihat docs/PUBLIC_DOCUMENTATION_RELEASE_GUIDE.md di repo aplikasi untuk alasannya.

Menerapkan migrasi baru

1. Selalu uji di project Supabase development/staging dulu — jangan pernah mengarahkan SUPABASE_DB_URL ke database produksi pada tahap pengujian.
2. Simpan SUPABASE_DB_URL hanya di .env.local (tidak pernah dikomit). Di jaringan yang tidak mendukung IPv6, gunakan connection string Session pooler (host *.pooler.supabase.com) alih-alih host db.<project-ref> langsung.
3. Terapkan berkas migrasi secara berurutan sesuai nomor/timestamp prefiksnya dengan psql, berhenti total jika satu berkas gagal — jangan melanjutkan ke migrasi berikutnya sebelum yang gagal diperbaiki.
4. Setelah migrasi yang mengubah data (bukan sekadar skema) diterapkan, validasi jumlah baris antara sumber dan tujuan sebelum menganggap langkah itu selesai — jangan asumsikan import berhasil hanya karena tidak ada error.
5. Jalankan skrip migration:* yang relevan dari package.json (lihat CI/CD) sebagai verifikasi otomatis tambahan sebelum mengaktifkan flag canonical-read untuk domain tersebut.

Mengaktifkan/membatalkan domain kanonik

Mengaktifkan pembacaan dari tabel kanonik untuk suatu domain tidak memerlukan deploy ulang kode — cukup set VITE_SUPABASE_CANONICAL_<DOMAIN>_READS=true setelah memverifikasi tabel kanonik domain itu sudah siap (lihat Migrasi & Rollout). Membatalkannya sama mudahnya: set kembali ke false — kode otomatis fallback membaca legacy_documents.

Verifikasi backup

Pemeriksaan kesehatan backup berjalan otomatis setiap hari lewat workflow backup-health.yml (lihat CI/CD), memanggil Supabase Management API untuk memastikan backup/PITR terbaru. Ini bukan pengganti uji pemulihan (restore drill) penuh — restore drill sesungguhnya dijalankan manual, terpisah, dengan project hasil restore sendiri, dan hasilnya dicatat di catatan rilis internal.

Eskalasi & persetujuan

Keputusan cutover/rollback produksi, perubahan skema besar, dan tindakan yang memengaruhi data pelanggan nyata memerlukan persetujuan eksplisit pemilik bisnis — runbook ini adalah panduan prosedur, bukan otorisasi untuk mengeksekusi perubahan produksi.

---

Sumber: pola umum ditelusuri dari docs/supabase-migration/RUNBOOK.md (internal, ditulis ulang generik di sini sesuai docs/PUBLIC_DOCUMENTATION_RELEASE_GUIDE.md), package.json (skrip migration:*), .github/workflows/backup-health.yml.