Deploy ke production bukan cuma soal menjalankan perintah build lalu menunggu aplikasi hidup. Banyak masalah justru muncul karena hal kecil: environment variable tertinggal, migrasi database belum dites, backup tidak bisa dipulihkan, atau tidak ada cara cepat untuk rollback.
Checklist membantu tim memeriksa hal-hal penting sebelum perubahan menyentuh pengguna. Bentuknya sederhana, tetapi sangat berguna saat deploy dilakukan malam hari, ketika anggota tim sedang terburu-buru, atau ketika beberapa layanan saling bergantung.
Prasyarat
- Akses ke repository aplikasi dan pipeline CI/CD.
- Akses yang sesuai ke server, platform cloud, atau layanan hosting.
- Environment staging yang cukup mirip dengan production.
- Akses untuk memeriksa log, monitoring, database, dan status layanan.
- Prosedur rollback yang sudah diketahui oleh orang yang bertugas.
Langkah Membuat Checklist Deploy Aman
1. Catat perubahan yang akan dirilis
Mulai dari hal paling dasar: tulis apa saja yang berubah. Sertakan fitur baru, perbaikan bug, perubahan konfigurasi, migrasi database, dan perubahan dependency.
Jangan hanya menulis “rilis versi terbaru”. Catatan seperti “menambah kolom status pada tabel orders” jauh lebih berguna karena langsung memberi petunjuk tentang risiko yang perlu diperiksa.
2. Pastikan semua perubahan sudah ditinjau
Periksa apakah pull request sudah mendapat review dan seluruh pemeriksaan otomatis berhasil. Minimal, cek test unit, test integrasi, linting, dan hasil build.
Kalau ada test yang sengaja dilewati, tulis alasannya di checklist. Ini penting supaya pengecualian tidak berubah menjadi kebiasaan yang terlupakan.
3. Uji perubahan di staging
Deploy kandidat rilis ke staging, lalu jalankan alur yang paling penting bagi pengguna. Contohnya login, checkout, pembayaran, upload file, pengiriman email, atau proses sinkronisasi dengan layanan eksternal.
Staging tidak harus sama persis dengan production, tetapi perbedaan penting perlu dicatat. Misalnya ukuran database, konfigurasi cache, atau kredensial API. Banyak bug baru terlihat ketika kondisi lingkungan berubah.
4. Periksa konfigurasi production
Pastikan environment variable, secret, URL layanan, konfigurasi database, dan feature flag sudah sesuai untuk production. Jangan menyalin file konfigurasi staging secara mentah.
Periksa juga secret yang akan kedaluwarsa dan izin akses service account. Aplikasi bisa berhasil dijalankan, tetapi gagal ketika memanggil storage, payment gateway, atau layanan notifikasi.
5. Siapkan backup dan rencana pemulihan
Sebelum mengubah database atau data penting, pastikan backup terbaru tersedia. Yang lebih penting, pastikan backup tersebut pernah diuji untuk dipulihkan. Backup yang tidak pernah dicoba restore belum bisa dianggap sebagai rencana pemulihan.
Catat siapa yang bertanggung jawab menjalankan restore, berapa perkiraan waktunya, dan data apa saja yang mungkin hilang jika harus kembali ke backup sebelumnya.
6. Periksa migrasi database
Jalankan migrasi di staging dengan salinan struktur dan data yang realistis. Perhatikan migrasi yang mengubah tabel besar, menambah index, menghapus kolom, atau mengunci tabel dalam waktu lama.
Untuk perubahan yang berisiko, gunakan pola bertahap: tambah struktur baru, deploy kode yang mendukung struktur lama dan baru, pindahkan data, lalu hapus bagian lama pada rilis berikutnya. Cara ini biasanya lebih aman daripada melakukan perubahan besar dalam satu deploy.
7. Pastikan rollback benar-benar tersedia
Tentukan cara mengembalikan versi aplikasi jika rilis bermasalah. Rollback bisa berupa deploy image sebelumnya, mengaktifkan versi release lama, atau mematikan feature flag.
Perhatikan kompatibilitas database. Aplikasi lama belum tentu bisa berjalan dengan skema database yang sudah berubah. Karena itu, rollback database perlu direncanakan terpisah dan tidak boleh diasumsikan otomatis.
8. Tentukan waktu dan penanggung jawab deploy
Pilih waktu dengan trafik dan risiko operasional yang masuk akal. Tunjuk satu orang sebagai pengambil keputusan utama, lalu pastikan ada orang lain yang memantau log dan metrik.
Hindari kondisi “semua mengira orang lain yang menjalankan”. Nama operator, waktu mulai, kanal komunikasi, dan kontak eskalasi sebaiknya ditulis di checklist.
9. Jalankan deploy secara bertahap jika memungkinkan
Kalau platform mendukungnya, gunakan canary release, rolling update, atau blue-green deployment. Mulai dari sebagian kecil instance atau pengguna, lalu amati hasilnya sebelum memperluas rilis.
Deploy bertahap memberi ruang untuk menghentikan perubahan ketika error rate naik. Ini lebih aman daripada langsung mengubah seluruh instance sekaligus.
10. Pantau setelah deploy
Jangan menganggap deploy selesai begitu pipeline berwarna hijau. Pantau error rate, latency, penggunaan CPU dan memori, antrean pekerjaan, koneksi database, serta metrik bisnis yang relevan.
Lakukan smoke test dari sisi pengguna. Coba alur utama menggunakan environment production dengan akun dan data uji yang aman. Hapus atau tandai data uji setelah pemeriksaan selesai.
Cara Cek Hasil
- Pastikan versi aplikasi yang berjalan sesuai dengan release yang direncanakan.
- Cek health check dan status seluruh instance atau container.
- Periksa log untuk error baru, timeout, dan warning yang meningkat.
- Uji alur utama seperti login, transaksi, pencarian, dan notifikasi.
- Bandingkan metrik sebelum dan sesudah deploy.
- Pastikan tidak ada antrean pekerjaan yang macet atau bertambah tanpa kendali.
- Catat hasil pemeriksaan dan waktu ketika deploy dinyatakan stabil.
Kalau Masih Gagal
Hentikan perluasan deploy lebih dulu. Kalau memakai canary atau rolling update, tahan prosesnya supaya dampak tidak melebar.
Setelah itu, lihat perubahan terakhir pada log dan metrik. Bedakan apakah masalah berasal dari kode, konfigurasi, database, dependency, atau layanan eksternal. Jangan langsung mengubah banyak hal sekaligus karena penyebabnya akan semakin sulit dilacak.
Jika dampaknya nyata bagi pengguna dan penyebab belum jelas, lakukan rollback sesuai prosedur. Simpan log, detail release, dan waktu kejadian untuk investigasi setelah layanan kembali stabil.
Jika rollback tidak aman karena ada migrasi database, aktifkan feature flag atau nonaktifkan bagian fitur yang bermasalah bila tersedia. Eskalasikan ke pemilik layanan terkait jika error berasal dari payment gateway, DNS, storage, atau sistem eksternal.
Tips Operasional
- Simpan checklist di repository atau sistem dokumentasi yang bisa dilihat seluruh tim.
- Bedakan item wajib dengan item yang hanya berlaku untuk jenis perubahan tertentu.
- Jangan membuat checklist terlalu panjang. Kalau semua hal diberi status wajib, operator akan cepat melewati isinya.
- Tambahkan kolom nama pemeriksa, waktu, status, dan catatan singkat.
- Review checklist setelah insiden atau near miss. Biasanya ada satu langkah yang perlu diperjelas.
- Uji prosedur rollback secara berkala, bukan hanya ketika sedang panik.
- Gunakan automated check untuk hal yang bisa diperiksa mesin, seperti test, migrasi, secret, dan health check.
Penutup
Checklist deploy yang baik bukan dokumen formal untuk memenuhi proses. Ia adalah alat bantu agar keputusan penting tidak bergantung pada ingatan operator. Mulai dari versi sederhana, pakai saat deploy nyata, lalu perbaiki berdasarkan masalah yang benar-benar muncul.
Fokus utamanya ada tiga: perubahan bisa dipahami, dampaknya bisa dipantau, dan aplikasi bisa dikembalikan ketika hasilnya tidak sesuai harapan. Kalau tiga hal itu sudah jelas, proses deploy akan jauh lebih tenang dan mudah dipertanggungjawabkan.
