Checklist Deploy Aman untuk Aplikasi Web Production
Deploy ke production itu bukan sekadar git pull, build, lalu refresh halaman. Satu variabel environment yang keliru atau migrasi database yang belum diuji bisa bikin layanan berhenti di jam ramai. Karena itu, checklist deploy perlu dibuat sebagai alat kerja: dipakai sebelum, saat, dan setelah rilis.
Tutorial ini cocok buat aplikasi web apa pun, baik Laravel, Node.js, Django, PHP biasa, maupun container Docker. Tinggal sesuaikan perintahnya dengan stack yang dipakai.
Prasyarat
- Akses ke repository, server production, dan log aplikasi.
- Ada environment staging atau minimal server uji yang cukup mirip dengan production.
- Backup database sudah bisa dijalankan dan dipulihkan.
- Daftar kontak orang yang bertanggung jawab jika deploy perlu dibatalkan.
- Dokumen singkat arsitektur aplikasi: service, database, queue, cron, cache, dan domain terkait.
Langkah 1: Tulis identitas rilis
Buat bagian paling atas checklist berisi nomor versi atau commit, waktu deploy, nama pelaksana, serta link pull request. Kelihatannya sepele, tapi ini sangat membantu saat harus mencari perubahan mana yang menyebabkan error.
- Versi atau commit:
v1.8.4 / a1b2c3d - Jadwal deploy dan estimasi durasi
- Perubahan utama: fitur, perbaikan bug, konfigurasi, atau migrasi database
- Risiko yang sudah diketahui
Langkah 2: Cek perubahan sebelum menyentuh production
Pastikan semua perubahan sudah direview dan test otomatis berjalan. Jangan jadikan production sebagai tempat pertama untuk mengetahui syntax error.
Baca daftar file yang berubah. Beri perhatian ekstra pada file konfigurasi, Docker Compose, Nginx, dependensi, autentikasi, pembayaran, dan proses database.
Uji build dari commit yang benar di staging. Yang diuji harus artefak yang sama dengan yang akan dirilis, bukan branch lain yang “kurang lebih sama”.
Cek perubahan dependency. Library baru kadang membawa kebutuhan ekstensi, perubahan Node.js, atau ukuran image Docker yang melonjak.
Langkah 3: Siapkan backup dan rencana rollback
Sebelum deploy, buat backup database dan pastikan hasilnya benar-benar tersimpan di lokasi yang bisa diakses. Backup yang tidak pernah diuji restore-nya sering cuma memberi rasa aman palsu.
Jalankan backup database dan catat nama file serta waktu pembuatannya.
Pastikan kapasitas disk server masih cukup untuk backup, image baru, log, dan proses build.
Siapkan versi aplikasi sebelumnya yang bisa dijalankan kembali.
Tulis kondisi rollback dengan jelas. Contohnya: error rate naik, login gagal, transaksi tidak tersimpan, atau waktu respons naik tajam selama lebih dari lima menit.
Catatan penting: migrasi database yang menghapus kolom atau mengubah data besar-besaran perlu strategi khusus. Idealnya perubahan dibuat bertahap agar kode versi lama dan baru masih bisa hidup bersamaan saat rollback.
Langkah 4: Validasi konfigurasi production
Bandingkan environment variable yang dibutuhkan aplikasi dengan konfigurasi production. Jangan tampilkan nilai secret di checklist; cukup tandai apakah variabel tersedia.
Pastikan mode debug mati, URL aplikasi benar, dan koneksi database mengarah ke server production yang tepat.
Cek konfigurasi email, object storage, payment gateway, Redis, queue, dan layanan pihak ketiga yang dipakai aplikasi.
Pastikan port internal tidak tiba-tiba dibuka ke publik akibat perubahan reverse proxy atau firewall.
Bagian ini sering jadi sumber masalah paling menyebalkan: aplikasinya sehat, tapi callback pembayaran atau pengiriman email diam karena satu variabel salah nama.
Langkah 5: Jalankan deploy dengan urutan yang aman
Umumkan waktu maintenance jika deploy berpotensi mengganggu pengguna.
Aktifkan maintenance mode bila aplikasi tidak mendukung deploy tanpa downtime.
Tarik image atau kode dari versi yang sudah disetujui, lalu jalankan build bila diperlukan.
Jalankan migrasi database dengan perintah yang aman untuk production. Jangan memakai perintah reset, fresh, atau sejenisnya di server live.
Restart atau rolling update service secara terukur. Untuk Docker, cek status container setelah update; jangan langsung menganggap sukses hanya karena perintah selesai.
Bersihkan cache aplikasi hanya jika memang dibutuhkan dan pahami dampaknya. Cache yang dibersihkan sembarangan bisa membuat beban database naik mendadak.
Matikan maintenance mode setelah pengecekan dasar lulus.
Langkah 6: Cek hasil deploy
Begitu deploy selesai, lakukan smoke test dari sudut pandang pengguna. Fokus ke alur penting, bukan sekadar halaman depan berhasil dibuka.
- Buka halaman utama dan halaman login melalui domain publik.
- Login memakai akun uji, lalu cek hak akses dasar.
- Buat satu data uji sesuai fungsi utama aplikasi, misalnya pesanan, tagihan, tiket, atau formulir.
- Cek job queue, cron, email, notifikasi, atau webhook bila rilis menyentuh bagian tersebut.
- Pantau log aplikasi, log reverse proxy, penggunaan CPU/RAM, dan error rate selama beberapa menit.
- Pastikan endpoint health check mengembalikan status sehat bila tersedia.
Simpan hasil cek ini di checklist. Kalau suatu hari ada insiden, catatan “setelah deploy login dan pembuatan tagihan normal” jauh lebih berguna daripada ingatan.
Kalau Masih Gagal
Error muncul sesudah deploy
Cek log aplikasi dan container lebih dulu, lalu cocokkan waktunya dengan langkah deploy. Jangan buru-buru mengubah lima hal sekaligus; nanti sumber masalahnya makin kabur.
Migrasi database bermasalah
Hentikan deploy lanjutan. Jika aplikasi tidak kompatibel dengan skema saat ini, lakukan rollback aplikasi atau ikuti prosedur restore yang sudah disiapkan. Hindari menjalankan migrasi balasan secara spontan tanpa memahami data yang sudah berubah.
Aplikasi hidup, tapi fitur tertentu error
Periksa environment variable, izin file atau storage, koneksi Redis/queue, serta layanan eksternal. Banyak kasus ini bukan bug kode, melainkan konfigurasi production yang belum ikut diperbarui.
Layanan lambat setelah rilis
Cek query database, cache miss, worker queue, resource container, dan lonjakan error. Kalau dampaknya terasa ke pengguna, rollback lebih baik daripada memaksa investigasi panjang di tengah layanan aktif.
Tips Operasional
- Jadikan checklist sebagai file di repository atau dokumentasi internal, bukan catatan chat yang hilang minggu depan.
- Bedakan checklist rilis kecil dan rilis yang melibatkan migrasi database.
- Tambahkan kolom penanggung jawab dan status untuk setiap poin: belum, sedang, lulus, atau gagal.
- Deploy di jam yang memungkinkan monitoring aktif. Rilis Jumat sore memang punya reputasi buruk, dan ada alasannya.
- Setelah ada insiden, perbarui checklist. Checklist yang baik tumbuh dari masalah nyata yang pernah kejadian.
Penutup
Checklist deploy yang aman bukan birokrasi tambahan. Justru ini cara sederhana supaya rilis lebih bisa diprediksi, rollback tidak panik, dan tim punya jejak kerja yang jelas. Mulai dari versi sederhana dulu, lalu rapikan setiap kali menemukan celah di proses deploy.
