Tutorial Membuat Checklist Deploy Aman untuk Aplikasi Web Production

Checklist Deploy Aman untuk Aplikasi Web Production

Deploy ke production sebaiknya bukan momen menekan tombol lalu berharap semuanya baik-baik saja. Checklist membantu tim memastikan hal penting tidak terlewat: backup, konfigurasi environment, migrasi database, sampai rencana rollback. Ini berguna bahkan untuk aplikasi kecil, apalagi kalau pengguna sudah aktif memakai sistem.

Prasyarat

• Akses ke repository aplikasi dan server atau platform deployment.
• Akses aman ke environment production, termasuk log aplikasi dan monitoring dasar.
• Daftar perubahan yang akan dirilis, misalnya dari pull request atau catatan release.
• Backup database yang bisa dipulihkan dan orang yang bertanggung jawab saat deploy.

Langkah-langkah

1. Catat isi rilis sebelum mulai

   Tulis singkat apa saja yang berubah: fitur baru, perbaikan bug, perubahan API, dependency, dan migrasi database. Tujuannya bukan administrasi berlebihan. Saat ada error setelah rilis, daftar ini mempersempit area yang perlu diperiksa.

2. Tentukan waktu deploy dan PIC

   Pilih jam dengan trafik lebih rendah jika memungkinkan. Tentukan satu orang yang menjalankan deploy dan satu orang cadangan yang bisa membantu mengecek dampaknya. Untuk aplikasi yang dipakai operasional, hindari deploy besar menjelang jam sibuk.

3. Pastikan branch dan commit sudah benar

   Verifikasi branch release, commit hash, dan status pipeline. Jangan deploy dari laptop dengan perubahan lokal yang belum jelas asalnya. Biasakan rilis dari tag atau commit yang sudah lolos review supaya versi yang berjalan dapat dilacak.

   

4. Jalankan test dan build ulang

   Jalankan test otomatis yang tersedia, lalu buat build dari kondisi bersih. Periksa juga linter atau type check bila proyek memilikinya. Build yang sukses di mesin developer belum tentu aman; perbedaan versi Node.js, dependency, atau environment sering menjadi sumber masalah kecil yang melebar.

5. Periksa konfigurasi production

   Cek environment variable, URL layanan eksternal, kredensial, pengaturan email, storage, cache, dan mode debug. Pastikan DEBUG atau log sensitif tidak terbuka ke publik. Nilai environment yang salah lebih sering membuat aplikasi gagal daripada kode yang benar-benar rusak.

6. Backup sebelum perubahan database

   Jika rilis membawa migrasi database, buat backup dan pastikan file backup benar-benar tersimpan. Jangan cukup melihat pesan “backup berhasil”; cek ukuran file atau lakukan uji restore di environment terpisah bila perubahan cukup besar. Database adalah bagian yang paling mahal untuk diperbaiki kalau salah langkah.

7. Siapkan rollback yang realistis

   Tentukan cara kembali ke versi sebelumnya: image container lama, release sebelumnya di platform hosting, atau tag Git yang sudah teruji. Catat juga apakah migrasi database bisa dibalik. Kalau migrasinya destruktif, rollback aplikasi saja mungkin tidak cukup.

8. Aktifkan mode maintenance bila diperlukan

   Untuk perubahan yang berisiko membuat data tidak konsisten, tampilkan halaman maintenance singkat. Tidak semua deploy perlu downtime, tetapi lebih baik pengguna melihat pemberitahuan jujur daripada menerima error acak saat proses berlangsung.

9. Deploy dengan urutan yang sesuai

   Umumnya: unggah artifact atau image, jalankan migrasi yang sudah dicek, lalu restart atau pindahkan trafik ke versi baru. Jika memakai blue-green atau canary deployment, arahkan sebagian kecil trafik dulu. Pendekatan ini memberi ruang untuk menangkap masalah sebelum semua pengguna terkena.

10. Amati aplikasi segera setelah rilis

    Setelah deploy selesai, jangan langsung menutup terminal. Buka log error, dashboard monitoring, dan halaman utama aplikasi. Perhatikan lonjakan error 500, response time, penggunaan CPU atau memori, serta antrean background job. Lima belas menit pertama biasanya paling menentukan.

Cara Cek Hasil Deploy

• Buka halaman utama, login, dan satu alur bisnis paling penting, misalnya membuat pesanan atau mengirim formulir.
• Pastikan endpoint kesehatan seperti /health atau status platform menunjukkan aplikasi sehat.
• Periksa log untuk error baru, terutama koneksi database, cache, storage, dan layanan pihak ketiga.
• Pastikan versi aplikasi atau commit hash yang tampil memang sesuai rilis.
• Cek metrik dasar selama beberapa menit: error rate, latency, CPU, memori, dan antrean job.

Kalau Masih Gagal

Jangan panik dan jangan langsung mengubah banyak hal sekaligus. Ambil error pertama yang jelas dari log, cocokkan dengan perubahan rilis, lalu tentukan dampaknya. Kalau pengguna mulai terdampak dan penyebab belum cepat ditemukan, rollback ke versi stabil biasanya keputusan paling aman.

• Jika aplikasi tidak bisa start, cek environment variable, secret, dependency, dan konfigurasi port lebih dulu.
• Jika migrasi gagal, hentikan proses lanjutan, jangan paksa menjalankan ulang tanpa membaca error dan status schema database.
• Jika hanya fitur tertentu yang rusak, pertimbangkan menonaktifkan feature flag atau endpoint terkait sambil menjaga layanan utama tetap hidup.
• Jika rollback dilakukan, dokumentasikan waktu, versi, error, dan langkah yang sudah dicoba. Catatan kecil ini sangat membantu saat investigasi berikutnya.

Tips Operasional

• Simpan checklist di repository agar ikut berubah bersama proses aplikasi, bukan terselip di chat lama.
• Buat checklist berbeda untuk deploy rutin dan deploy yang melibatkan database atau perubahan infrastruktur.
• Gunakan feature flag untuk fitur baru yang belum sepenuhnya yakin. Kode bisa dirilis lebih dulu tanpa langsung terlihat oleh semua pengguna.
• Jangan menyimpan password, token, atau isi secret di checklist. Cukup tulis lokasi aman untuk mengambilnya.
• Setelah beberapa kali deploy, revisi checklist berdasarkan insiden nyata. Checklist yang baik lahir dari hal-hal yang pernah hampir lupa dilakukan.

Penutup

Checklist deploy bukan tanda tim tidak percaya diri. Justru ini cara sederhana untuk menjaga proses tetap tenang saat kondisi sedang ramai. Mulai dari versi ringkas dulu, pakai setiap rilis, lalu tambah poin hanya ketika memang terbukti berguna di lapangan.