✦ Selamat Idul Fitri 1447 H 🌙 Taqabbalallahu minna wa minkum. Mohon maaf lahir dan batin. ✦
Pribadi

Gagal Deploy, Belajar Mahal, Tidak Akan Diulangi

· Diperbarui 09 Jan 2026 · 0 komentar · ± 3 menit baca · 👁 40 dilihat

Saya ingin cerita satu kejadian yang sampai sekarang masih bikin saya ngilu kalau diingat. Bukan karena dramatis, tapi karena bodohnya terasa sangat avoidable — dan ternyata saya yang harus menanggung pelajarannya.

Ini terjadi beberapa tahun lalu, waktu saya sedang semangat-semangatnya oprek blog. Baru belajar cara deploy perubahan besar langsung di server production. Dan karena terlalu percaya diri, saya melewatkan satu langkah yang mestinya tidak pernah dilewatkan: backup.

Ceritanya

Saya sedang refactor struktur database — ubah beberapa nama kolom, gabungkan dua tabel jadi satu, tambah kolom baru. Di lokal, semua jalan mulus. Testing berkali-kali, tidak ada error. Senang, langsung jalankan migration di server production.

Selama beberapa detik pertama: aman. Lalu muncul error pertama. Saya coba perbaiki, muncul error kedua. Coba lagi, muncul error ketiga. Dan di titik itu saya sadar: blog-nya tidak bisa dibuka. Halaman putih. Pengunjung yang waktu itu membuka kawunganten.com cuma dapat halaman kosong.

Panik. Coba rollback migration — tapi struktur tabelnya sudah berubah setengah jalan, jadi rollback pun tidak mulus. Data yang sudah ada di tabel lama sebagian sudah terhapus karena migration memang ada perintah DROP. Dan tidak ada backup.

Dua jam saya habiskan untuk rekonstruksi — untungnya kehilangan datanya tidak terlalu parah karena artikelnya masih ada di cache browser saya dan bisa di-recover manual. Tapi itu dua jam yang sangat tidak menyenangkan, dan beberapa data kecil tetap hilang.

Apa yang Salah

Banyak. Tapi yang paling fundamental:

Pertama, tidak ada backup sebelum deployment. Ini aturan nomor satu yang saya tahu — saya tahu teorinya — tapi saya skip karena merasa sudah cukup yakin dengan hasil testing lokal. Yakin yang tidak berdasar.

Kedua, migration dijalankan langsung di production tanpa ada staging environment. Kalau ada server staging — server yang mirip production tapi bukan production — saya bisa test migration di sana dulu sebelum benar-benar dijalankan di server yang live.

Ketiga, migration-nya terlalu agresif. DROP kolom dan perubahan struktural besar seharusnya dilakukan bertahap, bukan sekaligus. Satu perubahan kecil, test, pastikan aman, baru lanjut ke perubahan berikutnya.

Sejak Itu

Sekarang saya punya ritual sebelum deploy apapun yang menyentuh database: backup dulu. Tidak peduli seberapa yakin saya dengan perubahannya. Backup dulu, baru jalan.

Di cPanel hosting saya, backup bisa dilakukan dalam hitungan klik. Tidak ada alasan untuk skip. Dan saya tidak pernah skip lagi sejak kejadian itu.

Kalau kamu baru mulai belajar dan belum pernah mengalami hal seperti ini — semoga tidak pernah. Tapi kalau suatu hari mengalami: itu bukan akhir dunia. Yang penting belajar dari sana dan tidak diulangi.

Ada yang punya cerita serupa? Atau tips deployment yang kamu anggap wajib? Cerita di komentar — siapa tahu bisa menyelamatkan orang lain dari pengalaman yang sama.


Komentar

Belum ada komentar. Jadilah yang pertama menulis.

Tulis Komentar