Apa yang Perlu Diperiksa Sebelum Naik ke Produksi: Checklist Lengkap Go Live

Di artikel sebelumnya, kita membahas mengapa source code mentah sebaiknya tidak langsung diunggah ke server. Sekarang mari lanjut satu langkah: setelah kode siap dan Anda hendak menayangkannya, apa saja yang perlu diperiksa sebelum benar-benar naik ke produksi?

Momen "naik ke produksi" (go live) sering diperlakukan sebagai satu klik tombol. Padahal ini seharusnya sebuah pos pemeriksaan — titik di mana Anda memastikan aplikasi benar-benar siap menghadapi pengguna nyata, lalu lintas nyata, dan konsekuensi nyata. Melewatkan pemeriksaan ini adalah cara tercepat menuju insiden di malam Minggu yang seharusnya bisa dihindari.

Artikel ini menyusun daftar periksa (checklist) yang dikelompokkan per area, agar Anda punya rutinitas yang bisa diulang setiap kali hendak merilis.

📚 Seri Deployment Yowisben — baca berurutan:

1. Mengapa Source Code Mentah Tidak Boleh Langsung Diunggah
2. Apa yang Perlu Diperiksa Sebelum Naik ke Produksi ← Anda di sini
3. Menyiapkan Pipeline CI/CD Pertama Anda
4. Strategi Rollback & Zero-Downtime Deployment

1. Keamanan

Keamanan adalah area yang paling mahal bila terlewat, jadi letakkan di urutan pertama.

• Matikan mode debug. Pastikan DEBUG atau mode pengembangan dalam keadaan nonaktif. Mode debug yang menyala di produksi bisa membocorkan jejak error lengkap, path server, dan detail konfigurasi ke pengunjung.
• Sembunyikan pesan error teknis. Pengguna cukup melihat halaman error yang ramah, bukan stack trace yang memaparkan struktur kode Anda.
• Periksa rahasia. Pastikan tidak ada kredensial yang ter-hardcode di kode, dan semua rahasia disuntikkan lewat environment variable, bukan file yang bisa diunduh.
• Pindai kerentanan dependensi. Jalankan audit pada pustaka yang Anda pakai untuk memastikan tidak ada versi dengan celah keamanan yang diketahui.

# Contoh audit dependensi
npm audit --production
# atau untuk PHP
composer audit

• Pastikan HTTPS aktif dan sertifikat SSL valid serta belum kedaluwarsa.
• Aktifkan header keamanan seperti Content-Security-Policy, X-Frame-Options, dan HSTS untuk pertahanan berlapis.
• Periksa izin akses berkas — jangan biarkan file atau folder punya izin terlalu longgar di server.

Peringatan. Satu file .env yang bisa diakses publik atau satu mode debug yang lupa dimatikan sudah cukup untuk membocorkan seluruh aplikasi. Jadikan dua hal ini pemeriksaan wajib yang tidak pernah dilewati.

2. Konfigurasi lingkungan

Penyebab paling umum aplikasi "jalan di lokal tapi rusak di produksi" adalah perbedaan konfigurasi.

• Pisahkan konfigurasi produksi dari pengembangan. URL, kunci API, dan pengaturan lain harus menunjuk ke sumber daya produksi, bukan lokal.
• Verifikasi variabel lingkungan. Pastikan semua environment variable yang dibutuhkan sudah diset di server produksi, tidak ada yang tertinggal.
• Cek koneksi ke layanan eksternal. Database, layanan email, penyimpanan file, gateway pembayaran — pastikan semua mengarah ke instance produksi yang benar.

3. Database

Database menyimpan aset paling berharga: data. Perlakukan dengan ekstra hati-hati.

• Jalankan migrasi dengan aman. Pastikan skema database produksi sudah sesuai, dan migrasi sudah diuji lebih dulu di lingkungan staging.
• Buat cadangan sebelum rilis. Selalu ambil backup database tepat sebelum penayangan, sehingga Anda bisa memulihkan bila terjadi masalah.
• Periksa indeks. Pastikan kolom yang sering dikueri sudah terindeks agar performa tidak anjlok saat data membesar.
• Jangan bawa data uji coba. Bersihkan data dummy atau akun uji yang mungkin tersisa dari pengembangan.

4. Performa dan optimasi

Aplikasi yang lambat mengusir pengguna, meski fungsinya sempurna.

• Pastikan proses build sudah dijalankan — kode termini­fikasi, ter-bundle, dan aset teroptimalkan.
• Aktifkan caching di level yang sesuai: cache aplikasi, cache database, dan cache browser lewat header yang tepat.
• Optimalkan aset statis — kompres gambar, aktifkan kompresi Gzip atau Brotli di server.
• Pertimbangkan CDN untuk menyajikan aset statis lebih dekat ke pengguna.
• Uji beban ringan. Bila memungkinkan, simulasikan lalu lintas untuk melihat bagaimana aplikasi berperilaku di bawah tekanan.

5. Penanganan error dan logging

Ketika sesuatu rusak di produksi — dan cepat atau lambat pasti ada yang rusak — Anda perlu tahu tanpa harus menunggu laporan pengguna.

• Siapkan halaman error yang layak untuk kode 404 dan 500, agar pengguna tidak melihat layar kosong atau pesan teknis.
• Aktifkan logging yang terstruktur. Catat error ke file log atau layanan terpusat, lengkap dengan konteks yang cukup untuk menelusuri masalah.
• Jangan mencatat data sensitif. Pastikan log tidak ikut menyimpan kata sandi, token, atau data pribadi pengguna.

6. Pengujian

Jangan mengandalkan asumsi bahwa "tadi masih jalan kok".

• Jalankan seluruh rangkaian tes — unit, integrasi — dan pastikan semuanya hijau.
• Uji di lingkungan staging yang semirip mungkin dengan produksi, bukan hanya di laptop Anda.
• Lakukan smoke test setelah rilis: buka alur-alur terpenting (login, checkout, kirim form) dan pastikan semuanya benar-benar berfungsi di produksi.

Tips. Buat daftar singkat "alur kritis" aplikasi Anda — fitur yang kalau rusak berarti bisnis berhenti. Setiap kali rilis, uji alur-alur ini secara manual sebagai jaring pengaman terakhir.

7. Rencana cadangan dan rollback

Rilis yang baik selalu punya tombol mundur.

• Pastikan Anda bisa memutar balik (rollback) ke versi sebelumnya dengan cepat bila rilis baru bermasalah.
• Ketahui titik pemulihan Anda. Backup database dan artefak versi lama harus tersedia dan teruji, bukan sekadar diasumsikan ada.
• Rencanakan urutan langkah bila terjadi kegagalan — siapa melakukan apa, dan bagaimana mengabari pengguna.

Strategi rollback yang lebih matang — termasuk zero-downtime deployment — dibahas tuntas di bagian keempat seri ini.

8. Pemantauan dan observabilitas

Setelah tayang, Anda butuh mata dan telinga di server.

• Pasang pemantauan uptime agar Anda tahu lebih dulu bila situs tumbang, bukan dari keluhan pelanggan.
• Siapkan peringatan (alert) untuk lonjakan error, penggunaan sumber daya yang abnormal, atau waktu respons yang melambat.
• Pantau metrik dasar — CPU, memori, ruang disk, dan waktu respons aplikasi.

9. Dependensi dan versi

• Kunci versi dependensi lewat lockfile agar produksi memakai versi yang persis sama dengan yang Anda uji.
• Singkirkan dependensi pengembangan — alat uji dan linter tidak perlu ikut ke produksi.
• Catat versi rilis. Beri tag atau nomor versi pada setiap rilis agar mudah dilacak dan diputar balik bila perlu.

10. Detail operasional yang sering terlupa

Hal-hal kecil yang kalau terlewat justru bikin repot:

• Cek masa berlaku domain dan SSL — jangan sampai situs mati hanya karena sertifikat kedaluwarsa.
• Atur robots.txt dengan benar — pastikan Anda tidak tak sengaja memblokir mesin pencari, atau sebaliknya membuka halaman yang seharusnya privat.
• Verifikasi zona waktu server agar timestamp dan penjadwalan berjalan tepat.
• Siapkan halaman maintenance untuk dipakai bila suatu saat butuh menurunkan situs sementara.

Checklist ringkas sebelum go live

Sebagai rangkuman cepat yang bisa Anda tempel di dekat meja:

1. Mode debug mati, pesan error teknis tersembunyi.
2. Rahasia lewat environment variable, tidak ada yang ter-hardcode.
3. Dependensi sudah diaudit, tidak ada kerentanan diketahui.
4. HTTPS aktif, sertifikat SSL valid.
5. Konfigurasi menunjuk ke sumber daya produksi.
6. Migrasi database aman, dan backup sudah diambil.
7. Proses build dan optimasi sudah dijalankan.
8. Caching dan kompresi aktif.
9. Halaman error dan logging siap.
10. Seluruh tes hijau, smoke test lulus.
11. Rencana rollback siap dan teruji.
12. Pemantauan dan alert menyala.
13. Domain, SSL, dan robots.txt sudah dicek.

Penutup

Naik ke produksi bukan garis akhir, melainkan pintu masuk ke dunia nyata tempat aplikasi Anda dipakai orang sungguhan. Daftar periksa di atas mungkin terasa panjang, tapi ia melindungi Anda dari kelas kesalahan yang paling sering dan paling menyakitkan — rahasia yang bocor, situs yang lambat, error yang tak terpantau, dan rilis yang tak bisa diputar balik.

Kabar baiknya, checklist seperti ini semakin cepat dijalankan seiring kebiasaan, dan sebagian besar bahkan bisa diotomatiskan lewat pipeline CI/CD. Kalau hanya satu prinsip yang ingin Anda bawa: perlakukan setiap rilis sebagai peristiwa yang direncanakan, bukan kejutan. Sedikit disiplin sebelum menekan tombol tayang akan menyelamatkan Anda dari banyak malam yang tidak perlu begadang.

Ini adalah bagian kedua dari seri deployment Yowisben. Bila Anda melewatkan bagian pertama tentang mengapa source code mentah tak boleh langsung diunggah, ada baiknya membacanya lebih dulu sebagai fondasi. Berikutnya, lanjut ke cara mengotomatiskan seluruh pemeriksaan ini dengan pipeline CI/CD.