Zero Downtime Deployment: Cara Update Web Tanpa Halaman 'Maintenance'

Selamat Tinggal Halaman 'Sedang Dalam Perbaikan'

Di zaman *Web Hosting* cPanel kuno, jika kamu ingin merilis fitur baru (*Update*), kamu harus mengubah kode di *server*. Selama 5 menit proses pengopian file itu terjadi, pengunjung akan melihat halaman *Error* putih atau halaman ilustrasi "Under Maintenance". Di era Startup 24 Jam, mematikan layanan selama 5 menit sama dengan membuang potensi pendapatan miliaran rupiah.

Tuntutan industri melahirkan teknik rilis kelas atas yang disebut Zero Downtime Deployment (Rilis Tanpa Mati Sebentarpun).

Strategi 1: Blue-Green Deployment

Ini adalah teknik sulap pergantian panggung yang sangat elegan.

1. Kamu memiliki Environment Blue (Aplikasi Versi 1.0 yang sedang Live dan dipakai pengunjung).
2. Saat *Developer* ingin merilis Versi 2.0, mereka TIDAK MENGHANCURKAN Versi 1.0. Sebaliknya, mereka menyewa server kloningan yang benar-benar baru, dan memasang Versi 2.0 di sana. Ini disebut Environment Green.
3. Tim QA (Penguji) masuk secara rahasia ke Environment Green dan mengetes semua fiturnya. Pengunjung umum masih asyik belanja di Blue tanpa sadar apapun.
4. Setelah Versi 2.0 dipastikan 100% mulus tanpa *Bug*, *Network Engineer* (melalui Load Balancer) akan "Memutar Saklar Jaringan".
5. Dalam 1 milidetik, rute lalu lintas semua pengguna internet dialihkan (Switched) dari Blue ke Green! Pengguna melihat fitur baru tanpa ada putus koneksi. Jika Green ternyata error, putar balik saklarnya ke Blue secara instan (Rollback kilat)!

Strategi 2: Canary Release (Uji Coba Burung Kenari)

Nama ini diambil dari sejarah penambang batu bara yang membawa burung kenari ke dalam gua untuk mendeteksi racun. Jika burungnya mati, pekerja tambang langsung kabur ke luar.

Di Canary Release, jika kamu meluncurkan Versi 2.0 (fitur baru yang radikal), kamu tidak langsung memberikannya kepada 100% pengguna. Load Balancer akan diatur untuk mengalirkan 5% pengunjung saja secara acak ke Versi 2.0, sementara 95% sisanya tetap di Versi 1.0 yang aman.

Tim IT kemudian memantau metrik (Grafana/Logs) dari kelompok 5% tersebut. Jika banyak yang mengalami Error atau komplain, rilis dibatalkan. Tapi jika 5% pengguna tersebut aman-aman saja, keran lalu lintas akan dibuka perlahan menjadi 20%, 50%, hingga akhirnya 100% pengguna dunia menikmati fitur barumu. Arsitektur DevOps adalah tentang meminimalisir risiko sekecil mungkin!