Mengapa Deployment Database Membutuhkan Strategi Sendiri

Anda memiliki pipeline CI/CD yang bekerja dengan baik untuk aplikasi Anda. Perubahan kode dibangun, diuji, dan di-deploy ke produksi dalam hitungan menit. Tim dapat merilis beberapa kali sehari tanpa masalah. Lalu seseorang menambahkan migrasi database ke pipeline yang sama, dan semuanya berantakan.

Migrasi berjalan selama empat puluh lima menit di tabel besar. Selama waktu itu, tabel terkunci. Pengguna mulai melihat error. Aplikasi tidak bisa melayani permintaan. Di tengah jalan, migrasi gagal, tetapi Anda tidak bisa roll back dengan bersih karena beberapa baris sudah berubah. Pipeline yang dulu hanya memakan waktu lima menit kini memakan waktu satu jam, dan tidak ada yang berani menjalankannya selama jam kerja.

Ini bukan masalah alat. Ini adalah masalah strategi. Deployment database beroperasi dengan batasan yang fundamental berbeda dibandingkan deployment aplikasi, dan memperlakukan keduanya dengan cara yang sama menciptakan risiko yang tidak bisa diperbaiki oleh otomatisasi apa pun.

Pola Deployment Aplikasi yang Tidak Bisa Diterapkan

Deployment aplikasi mengikuti pola yang sederhana dan dapat diulang: buat versi baru, deploy ke server, dan jika ada yang salah, roll back ke versi sebelumnya. Siklus ini bisa diulang berkali-kali dalam sehari dengan konsekuensi minimal. Versi lama masih ada. File masih valid. Rollback hanya masalah mengarahkan load balancer kembali ke rilis sebelumnya.

Deployment database tidak bekerja seperti itu. Saat Anda menjalankan migrasi, Anda mengubah struktur data yang sudah berisi data produksi. Rollback bukanlah saklar sederhana. Anda tidak bisa begitu saja "meng-undeploy" kolom yang ditambahkan, atau mengembalikan tabel yang dihapus, tanpa merekonstruksi keadaan sebelumnya dengan hati-hati. Data yang diubah selama migrasi tidak otomatis kembali.

Diagram alur berikut membandingkan kedua siklus:

flowchart TD subgraph App[Deployment Aplikasi] A1[Build] --> A2[Deploy] A2 --> A3{Berhasil?} A3 -->|Ya| A4[Selesai] A3 -->|Tidak| A5[Rollback: arahkan load balancer] A5 --> A2 end subgraph DB[Deployment Database] B1[Migrasi] --> B2[Kunci tabel] B2 --> B3[Transformasi data] B3 --> B4{Berhasil?} B4 -->|Ya| B5[Selesai] B4 -->|Tidak| B6[Rollback: rekonstruksi data] B6 --> B1 end

Faktor waktu membuat ini semakin buruk. Deployment aplikasi biasanya selesai dalam hitungan detik atau menit. Migrasi database pada tabel besar bisa memakan waktu puluhan menit atau jam. Selama waktu itu, tabel mungkin terkunci, kueri mungkin terblokir, dan aplikasi mungkin menjadi tidak tersedia sebagian atau seluruhnya. Pipeline yang memperlakukan perubahan database sebagai langkah lain dalam alur kerja aplikasi mengabaikan kenyataan ini.

Mengapa Memisahkan Pipeline Itu Masuk Akal

Respons paling praktis terhadap ketidakcocokan ini adalah memisahkan pipeline aplikasi dari pipeline database. Keduanya berjalan dengan jadwal yang berbeda, proses review yang berbeda, dan profil risiko yang berbeda.

Pipeline aplikasi tetap cepat. Pipeline terus mengirimkan fitur, perbaikan bug, dan perubahan konfigurasi beberapa kali sehari. Pipeline database berjalan dengan irama yang lebih lambat, dengan review yang lebih hati-hati dan penjadwalan yang eksplisit. Migrasi database dapat dieksekusi beberapa siklus sebelum deployment aplikasi yang bergantung padanya. Ini menciptakan penyangga: jika migrasi bermasalah, ada waktu untuk memperbaikinya tanpa memblokir rilis aplikasi.

Pemisahan ini juga mengubah siapa yang terlibat. Deployment aplikasi biasanya dimiliki oleh tim pengembangan atau platform. Deployment database seringkali membutuhkan keterlibatan DBA atau anggota tim yang memahami skema, volume data, dan perilaku penguncian migrasi. Pipeline terpisah memperjelas siapa yang perlu meninjau, menyetujui, dan memantau setiap jenis perubahan.

Perubahan Skema Backward-Compatible Mengurangi Risiko

Strategi lain yang mengubah cara Anda berpikir tentang deployment database adalah membuat perubahan skema bersifat backward-compatible. Idenya sederhana: skema lama dan skema baru harus bisa hidup berdampingan untuk sementara waktu. Ini memungkinkan Anda untuk men-deploy aplikasi dan perubahan database dalam langkah terpisah, tanpa memerlukan cutover yang tersinkronisasi.

Pertimbangkan mengganti nama kolom. Pendekatan naif adalah mengganti nama kolom dalam satu migrasi dan memperbarui kode aplikasi pada saat yang sama. Jika ada yang salah, aplikasi akan rusak karena merujuk pada nama kolom yang tidak lagi ada.

Pendekatan backward-compatible terlihat berbeda. Pertama, tambahkan kolom baru sambil mempertahankan kolom lama. Perbarui aplikasi untuk menulis ke kedua kolom. Deploy perubahan ini. Setelah Anda yakin semuanya berfungsi, perbarui aplikasi untuk membaca dari kolom baru, bukan kolom lama. Deploy lagi. Terakhir, setelah semua konsumen bermigrasi, hapus kolom lama dalam migrasi terpisah.

Proses ini memakan waktu lebih lama. Membutuhkan beberapa deployment dan lebih banyak koordinasi. Tapi ini jauh lebih aman. Jika ada yang salah di langkah mana pun, Anda bisa roll back aplikasi tanpa meninggalkan database dalam keadaan tidak konsisten. Perubahan database tidak pernah menjadi penghambat.

Tata Kelola Bukan Birokrasi, Melainkan Perlindungan

Perubahan database membutuhkan proses review yang melampaui pemeriksaan sintaks. Pull request untuk migrasi harus mencakup jawaban atas pertanyaan seperti: Apakah migrasi ini akan mengunci tabel? Berapa lama kunci diperkirakan berlangsung? Berapa perkiraan waktu eksekusi pada volume data produksi? Apakah ada layanan atau konsumen lain yang membaca dari tabel ini dan mungkin terpengaruh?

Ini bukan tentang menambah birokrasi. Ini tentang mengakui bahwa perubahan database membawa konsekuensi yang tidak dimiliki oleh perubahan kode aplikasi. Bug dalam kode aplikasi bisa diperbaiki dengan deployment baru. Bug dalam migrasi bisa merusak data, menyebabkan downtime, atau membutuhkan restore dari backup. Proses review ada untuk menangkap risiko ini sebelum mencapai produksi.

Prinsip yang sama berlaku untuk siapa yang bisa menjalankan migrasi. Tidak semua orang harus memiliki kemampuan untuk mengeksekusi perubahan skema terhadap produksi. Ini bukan tentang kepercayaan. Ini tentang akuntabilitas dan kenyataan bahwa perubahan database membutuhkan pengetahuan spesifik tentang volume data, indexing, penguncian, dan replication lag. Pipeline terpisah dengan akses terkontrol dan gerbang persetujuan eksplisit adalah pengaman praktis, bukan hambatan birokrasi.

Artinya bagi Tim Anda

Jika tim Anda memperlakukan migrasi database sebagai langkah lain dalam pipeline aplikasi, Anda membawa risiko yang tidak perlu. Solusinya bukan memperlambat deployment aplikasi. Melainkan memberikan deployment database strateginya sendiri, pipeline-nya sendiri, dan proses review-nya sendiri.

Mulailah dengan pemisahan. Jalankan pipeline aplikasi dan database secara independen. Buat perubahan skema bersifat backward-compatible bila memungkinkan. Bangun proses review yang menanyakan pertanyaan yang tepat tentang penguncian, waktu, dan dampak konsumen. Dan terimalah bahwa deployment database tidak akan pernah secepat atau sekasual deployment aplikasi. Itu bukanlah keterbatasan. Itu adalah pengakuan terhadap apa yang dipertaruhkan.

Daftar Periksa Praktis untuk Strategi Deployment Database

  • Pipeline aplikasi dan database dipisahkan, dengan jadwal dan proses review yang berbeda
  • Perubahan skema dirancang untuk bersifat backward-compatible jika memungkinkan
  • Setiap migrasi menyertakan perkiraan waktu eksekusi dan analisis penguncian
  • Perubahan database melalui pull request review dengan pemeriksaan eksplisit untuk penguncian tabel dan dampak konsumen
  • Migrasi diuji terhadap lingkungan staging dengan volume data seperti produksi
  • Rencana rollback didokumentasikan sebelum menjalankan migrasi apa pun di produksi

Kesimpulan

Deployment database bukanlah masalah teknis yang bisa diselesaikan dengan menambahkan alat migrasi ke pipeline yang sudah ada. Ini adalah masalah strategi yang mengharuskan Anda merancang proses terpisah, dengan waktu yang berbeda, kriteria review yang berbeda, dan toleransi risiko yang berbeda. Tim yang memperlakukannya seperti itu akan mengirimkan lebih cepat dalam jangka panjang, karena mereka berhenti terhambat oleh perubahan database yang sejak awal tidak pernah dirancang untuk masuk ke dalam pipeline aplikasi.