Ketika Perubahan Database Membutuhkan Lebih dari Sekadar Code Review

Seorang developer membuka pull request. Perubahannya terlihat sederhana: menambahkan kolom baru untuk melacak preferensi pengguna. Seorang rekan meninjau kode, menyetujuinya, dan perubahan tersebut digabungkan. Dua puluh menit kemudian, database produksi mulai mengakumulasi lock. Query yang dulu selesai dalam milidetik kini membutuhkan waktu detik. Deployment di-roll back, tetapi kerusakan sudah terjadi.

Skenario ini terjadi di tim yang memperlakukan perubahan database sama seperti perubahan kode aplikasi. Code review menangkap kesalahan logika dan masalah gaya penulisan, tetapi jarang menangkap apa yang terjadi ketika migrasi dijalankan terhadap tabel dengan sepuluh juta baris. Perbedaan antara migrasi yang aman dan yang berbahaya tidak selalu terlihat di diff.

Mengapa Pipeline Database Berbeda

Pipeline aplikasi memverifikasi bahwa kode bisa dikompilasi, pengujian lulus, dan artefak siap di-deploy. Pipeline database memiliki tugas yang berbeda: mereka memverifikasi bahwa perubahan skema tidak akan merusak data yang ada, mengunci tabel terlalu lama, atau menurunkan performa query setelah deployment.

Satu migrasi saja dapat menyebabkan kehilangan data, memicu lock yang berjalan lama, atau membuat aplikasi tidak dapat digunakan hingga migrasi selesai. Risiko-risiko ini bukan sekadar teori. Setiap tim yang mengelola database produksi pasti punya cerita tentang migrasi yang salah.

Pipeline untuk perubahan database ada untuk menangkap masalah-masalah ini sebelum mencapai produksi. Pipeline tidak menggantikan code review. Pipeline menambahkan lapisan verifikasi yang tidak bisa diberikan oleh code review saja.

Apa yang Terjadi Setelah Commit

Ketika seorang developer melakukan commit file migrasi ke feature branch, pipeline database mulai menjalankan pemeriksaan secara otomatis. Pemeriksaan ini terjadi sebelum ada reviewer manusia yang melihat perubahan tersebut.

Pemeriksaan pertama adalah validasi sintaks. Pipeline membaca file migrasi dan memastikan bahwa setiap pernyataan SQL dapat diurai tanpa kesalahan. Ini terdengar sepele, tetapi mencegah pemborosan waktu yang umum: seorang reviewer menghabiskan sepuluh menit melihat migrasi yang gagal di baris pertama.

Pemeriksaan kedua mendeteksi pola berbahaya. Menghapus tabel, menghapus kolom, atau mengubah tipe kolom adalah operasi yang dapat menghancurkan data. Pipeline menandai perubahan ini sebagai berisiko tinggi. Pipeline tidak memblokirnya secara otomatis, tetapi memastikan semua orang tahu apa yang dipertaruhkan.

Pemeriksaan ketiga adalah dry run. Pipeline menjalankan migrasi terhadap lingkungan pengujian yang semirip mungkin dengan produksi. Dry run mengukur berapa lama migrasi berlangsung, apakah menyebabkan table lock, dan apakah indeks perlu dibangun ulang. Dry run juga memverifikasi bahwa data pengujian tetap konsisten setelah migrasi.

Semua hasil ini dikumpulkan ke dalam satu laporan yang dilampirkan ke pull request. Reviewer melihat status sintaks, daftar operasi berisiko, durasi dry run, dan peringatan tentang potensi masalah. Mereka tidak perlu menjalankan migrasi secara manual atau menebak apa yang mungkin terjadi.

Diagram alur berikut merangkum tahapan pipeline dari commit hingga merge:

flowchart TD A[Developer melakukan commit file migrasi] --> B[Pipeline terpicu] B --> C[Validasi sintaks] C --> D[Perbandingan skema dengan produksi] D --> E[Analisis dampak performa] E --> F[Penilaian risiko] F --> G{Risiko rendah?} G -- Ya --> H[Setujui otomatis] H --> I[Beritahu reviewer] I --> J[Gabung jika disetujui] G -- Tidak --> K[Tandai untuk review manual] K --> L[Reviewer menyetujui atau menolak] L --> J F --> M[Buat laporan pipeline] M --> N[Lampirkan laporan ke pull request]

Approval Berbasis Risiko

Tidak semua migrasi membutuhkan tingkat pengawasan yang sama. Menambahkan kolom nullable dengan nilai default adalah risiko rendah. Menghapus tabel yang mungkin masih dirujuk oleh kode aplikasi adalah risiko tinggi. Pipeline harus mencerminkan perbedaan ini.

Approval berbasis risiko berarti pipeline memerlukan approver yang berbeda tergantung pada tingkat risiko migrasi. Migrasi berisiko rendah mungkin hanya perlu persetujuan dari satu senior developer. Migrasi berisiko tinggi yang menghapus kolom atau menjalankan backfill pada tabel besar memerlukan persetujuan dari DBA atau lead engineer yang memahami dampak produksi.

Konfigurasi pipeline mendefinisikan apa yang dianggap berisiko tinggi. Pola umum meliputi:

  • Pernyataan DROP TABLE atau DROP COLUMN
  • ALTER COLUMN yang mengubah tipe data
  • Migrasi yang memakan waktu lebih dari satu menit dalam dry run
  • Operasi yang memerlukan exclusive lock pada tabel besar

Ketika pipeline mendeteksi pola berisiko tinggi, pipeline memblokir merge hingga approver yang ditunjuk memberikan persetujuan eksplisit. Ini bukan tentang birokrasi. Ini tentang memastikan bahwa orang yang memahami database produksi memiliki kesempatan untuk meninjau perubahan sebelum diterapkan.

Laporan yang Menetap di Pull Request

Laporan pipeline tidak hanya untuk reviewer. Laporan ini adalah catatan tentang apa yang diperiksa dan apa yang ditemukan. Ketika seseorang melihat pull request berminggu-minggu kemudian, mereka dapat melihat apakah migrasi telah divalidasi, risiko apa yang diidentifikasi, dan siapa yang menyetujuinya.

Ini penting untuk debugging. Jika migrasi menyebabkan masalah setelah deployment, tim dapat melihat kembali laporan pipeline untuk melihat apakah dry run menunjukkan tanda-tanda peringatan yang diabaikan. Ini juga penting untuk audit. Lingkungan yang diatur perlu bukti bahwa perubahan database telah ditinjau dan disetujui sesuai kebijakan.

Apa yang Tidak Dilakukan Pipeline

Pipeline memverifikasi bahwa migrasi aman untuk dicoba. Pipeline tidak menjamin bahwa migrasi akan berhasil di produksi. Lingkungan produksi memiliki distribusi data yang berbeda, pola beban yang berbeda, dan batasan waktu yang berbeda. Dry run yang membutuhkan waktu tiga puluh detik di staging mungkin membutuhkan waktu lima menit di produksi karena tabelnya lebih besar atau server lebih sibuk.

Pipeline juga tidak menangani waktu pelaksanaan migrasi. Menjalankan migrasi selama lalu lintas puncak berisiko terlepas dari seberapa baik pengujiannya. Keputusan kapan menerapkan migrasi, bagaimana menangani lock, dan apa yang harus dilakukan jika terjadi kesalahan adalah bagian dari proses terpisah.

Daftar Periksa Praktis untuk Pengaturan Pipeline Database

Jika Anda membangun pipeline database untuk tim Anda, berikut adalah hal-hal yang harus diperbaiki terlebih dahulu:

  • Validasi sintaks pada setiap commit. Tangkap SQL yang rusak sebelum mencapai reviewer.
  • Deteksi pola berbahaya. Tandai DROP, ALTER COLUMN, dan operasi berisiko tinggi lainnya secara otomatis.
  • Dry run di lingkungan yang representatif. Ukur durasi, lock, dan konsistensi data.
  • Aturan approval berbasis risiko. Definisikan apa yang dianggap berisiko tinggi dan siapa yang dapat menyetujuinya.
  • Laporan yang dilampirkan ke pull request. Buat hasil validasi terlihat oleh reviewer dan pembaca di masa mendatang.

Mulailah dengan lima item ini. Mereka mencakup titik kegagalan yang paling umum dan memberikan tim Anda cara yang konsisten untuk meninjau perubahan database.

Intisari

Pipeline database bukanlah alat untuk menjalankan migrasi. Pipeline adalah mekanisme untuk memastikan bahwa setiap perubahan database mendapatkan tingkat pengawasan yang tepat sebelum menyentuh produksi. Pemeriksaan sintaks menangkap kesalahan ketik. Dry run menangkap masalah performa. Approval berbasis risiko memastikan orang yang tepat meninjau perubahan yang tepat.

Ketika bagian-bagian ini bekerja bersama, tim Anda dapat bergerak lebih cepat karena mereka percaya bahwa pipeline akan menangkap masalah lebih awal. Dan ketika migrasi benar-benar salah, Anda memiliki data untuk memahami alasannya.