Blue-Green Deployment adalah strategi rilis aplikasi yang menjaga dua lingkungan produksi yang identik berjalan berdampingan:
- Blue: versi yang sedang melayani trafik (versi “aktif”)
- Green: versi baru yang disiapkan dan diuji, tetapi belum menerima trafik
Ketika versi baru (Green) sudah terbukti sehat, trafik dipindahkan dari Blue → Green secara cepat (biasanya lewat konfigurasi reverse proxy / load balancer). Jika ada masalah, pemulihan (rollback) dilakukan dengan mengarahkan trafik kembali ke lingkungan sebelumnya.
Dokumen ini membahas konsepnya dengan contoh konteks yang umum pada aplikasi web yang dikontainerisasi (mis. SPA/React + Nginx, dan reverse proxy seperti Traefik/Nginx/ALB).
Inti idenya: “Siapkan dulu, baru switch”
Perbedaan terbesar Blue-Green dibanding rilis tradisional adalah perubahan tidak terjadi di lingkungan yang sedang melayani trafik. Versi baru disiapkan di lingkungan terpisah sampai:
- Container/instance baru menyala
- Health check atau pengujian lain lolos
Baru setelah itu dilakukan traffic switch.
Dengan kata lain, downtime bukan “dihindari dengan cara cepat”, tetapi “dihindari karena switch terjadi ketika versi baru sudah siap”.
Komponen yang biasanya ada
Walaupun implementasi tiap tim berbeda, Blue-Green hampir selalu melibatkan komponen berikut:
-
Artefak rilis yang immutabel
- Umumnya berupa Docker image versi tertentu (tag build number/commit), atau paket rilis yang dipromosikan antar environment.
-
Dua environment yang identik
- Konfigurasi runtime, env var, dependency, network, dan cara akses harus semirip mungkin.
-
Traffic router (L7) / Load Balancer / Reverse Proxy
- Komponen yang memutuskan trafik masuk diarahkan ke Blue atau Green.
- Di dunia container, ini bisa berupa Traefik/Nginx/Envoy/Ingress.
Traffic switching: cara berpikirnya
Ada beberapa cara melakukan switch. Terlepas dari teknologinya, prinsipnya sama:
- Sebelum switch: router mengirim trafik ke Blue
- Sesudah switch: router mengirim trafik ke Green
Implementasi konkret biasanya berupa salah satu dari ini:
- Mengubah route / service selector (mis. label-based routing)
- Mengubah upstream Nginx / target group LB
- Mengubah DNS (lebih lambat karena TTL, sering kurang ideal untuk rollback cepat)
Kunci utamanya adalah Reverse Proxy / Load Balancer berada di depan dua versi, dan “switch” hanya mengubah rute. Yang penting: switch harus cepat, atomik, dan bisa diulang.
Rollback: alasan Blue-Green populer
Rollback pada Blue-Green cenderung mudah karena:
- Versi lama (Blue) masih ada dan bisa langsung dipakai lagi
- Cara rollback seringkali sama sederhana seperti switch (balikkan rute)
Namun, ada satu syarat besar: data dan state harus dipikirkan dengan benar.
Tantangan Blue-Green
Blue-Green terlihat “rapi” karena switch trafiknya cepat, tetapi ada trade-off penting. Pertama, kamu biasanya perlu resource dobel (dua environment identik) sehingga biaya infrastruktur bisa naik. Kedua, strategi ini paling nyaman untuk aplikasi stateless; kalau ada state (session di memori, koneksi panjang seperti WebSocket, atau cache yang tidak dibagi), perpindahan Blue → Green bisa memutus sesi/koneksi atau memunculkan perilaku yang tidak konsisten.
Tantangan terbesar biasanya ada di database migration: perubahan skema/data yang tidak kompatibel ke belakang bisa membuat rollback “secara routing” jadi tidak aman. Karena itu, banyak tim menerapkan migrasi yang kompatibel dua arah (misalnya pola expand/contract) supaya versi lama dan baru bisa berjalan berdampingan selama masa transisi.
Penutup
Blue-Green Deployment itu pada dasarnya strategi untuk memisahkan proses “menyiapkan versi baru” dari “melayani trafik”. Dengan dua environment identik dan gerbang health check yang benar, kamu mendapatkan rilis yang lebih aman, downtime minimal, dan rollback yang cepat.
Jika kamu mau, saya bisa juga buat artikel lanjutan: perbandingan lebih detail Blue-Green vs Canary khusus aplikasi SPA + reverse proxy, termasuk skenario database migration yang aman (expand/contract).
