Blue/Green Deployment: Saat Anda Butuh Perpindahan Instan dan Rollback Instan

Bayangkan skenario ini: tim Anda baru saja menyelesaikan desain ulang besar-besaran pada halaman utama. Atau mungkin Anda mengganti pustaka inti yang menyentuh setiap bagian aplikasi. Perubahan seperti ini sulit diuji secara sempurna di staging karena data staging dan perilaku pengguna tidak pernah benar-benar cocok dengan produksi. Anda bisa mencoba rolling update, tetapi jika ada yang salah, setengah pengguna Anda akan melihat versi yang rusak sementara setengah lainnya masih melihat versi lama. Dan rollback? Itu berarti menunggu setiap instance kembali satu per satu. Tidak instan.

Di sinilah blue/green deployment berperan. Strategi ini memecahkan masalah spesifik: bagaimana cara mengalihkan semua pengguna ke versi baru secara bersamaan, dan bagaimana cara mengembalikannya secepat mungkin jika terjadi masalah?

Dua Lingkungan Identik, Satu Aktif dalam Satu Waktu

Idenya sederhana. Anda menyediakan dua lingkungan yang identik. Sebut saja satu biru (blue) dan satu hijau (green). Keduanya menjalankan infrastruktur, konfigurasi, dan kapasitas yang sama. Satu-satunya perbedaan adalah lingkungan mana yang sedang melayani pengguna saat ini.

Mari kita lihat bagaimana ini bekerja dalam praktik.

Diagram di bawah menunjukkan dua status dan transisi di antara keduanya.

flowchart TD BlueActive["Blue Aktif (v1)"] -->|Deploy v2 ke Green| GreenReady["Green Siap (v2)"] GreenReady -->|Cutover| GreenActive["Green Aktif (v2)"] GreenActive -->|Rollback| BlueActive BlueActive -.->|Siaga untuk rollback| BlueStandby["Blue Siaga (v1)"] GreenActive -.->|Siaga untuk rollback| GreenStandby["Green Siaga (v2)"]

Katakanlah pengguna Anda saat ini mengakses lingkungan blue yang menjalankan versi 1 aplikasi Anda. Lingkungan green juga berjalan, tetapi tidak menerima lalu lintas pengguna. Mungkin tim Anda menggunakannya untuk pengujian internal, atau mungkin hanya diam saja. Saat tiba waktunya merilis versi 2, Anda deploy versi baru ke lingkungan green. Sekarang green memiliki versi 2, sementara blue terus melayani pengguna dengan versi 1.

Pada titik ini, Anda dapat menguji versi 2 di lingkungan yang identik dengan produksi. Jalankan health check. Verifikasi fungsionalitas. Minta beberapa orang internal untuk mencoba versi baru. Semua terjadi tanpa memengaruhi pengguna nyata.

Setelah Anda yakin, lakukan cutover. Cutover berarti mengalihkan lalu lintas pengguna dari blue ke green. Anda dapat memperbarui konfigurasi load balancer, mengubah catatan DNS, atau memodifikasi routing di service mesh. Dalam hitungan detik, semua pengguna mulai mengakses versi 2. Tidak ada downtime karena green sudah berjalan dengan server yang hangat, koneksi database yang terbuka, dan aplikasi yang sudah diinisialisasi penuh.

Fitur Andalan: Rollback Instan

Keuntungan terbesar dari blue/green deployment adalah seberapa cepat Anda bisa melakukan rollback. Jika versi 2 ternyata bermasalah setelah pengguna mulai menggunakannya, Anda tinggal mengalihkan lalu lintas kembali ke blue. Pengguna kembali ke versi 1 secara instan. Tidak perlu menunggu redeploy. Tidak perlu menjalankan pipeline lagi. Rollback hanyalah perubahan routing.

Bandingkan dengan rolling update. Jika Anda perlu rollback rolling update, Anda harus membalikkan proses instance demi instance. Masing-masing membutuhkan waktu untuk restart dan terhubung kembali. Selama jendela waktu itu, beberapa pengguna mungkin masih mengakses versi yang rusak. Dengan blue/green, versi lama masih berjalan dan siap melayani. Anda cukup membalik sakelar dan selesai.

Trade-Off Biaya

Blue/green deployment memiliki kelemahan yang jelas: biaya. Anda perlu menjalankan dua lingkungan penuh secara bersamaan. Jika workload produksi Anda membutuhkan 10 server, blue/green berarti Anda menjalankan 20 server selama periode transisi. Anda membayar untuk kapasitas ganda.

Beberapa tim mengurangi biaya ini dengan mengecilkan (scale down) lingkungan yang menganggur. Misalnya, green mungkin berjalan hanya dengan 2 server saat tidak melayani lalu lintas, lalu scale up ke 10 server tepat sebelum cutover. Pendekatan ini memerlukan otomatisasi untuk menangani scaling, dan tetap lebih mahal daripada rolling update. Namun untuk perubahan berisiko tinggi, biaya mungkin sebanding dengan keamanan yang didapat.

Kapan Menggunakan Blue/Green

Strategi ini cocok untuk perubahan di mana risikonya tinggi dan rollback harus instan. Pikirkan tentang:

  • Desain ulang UI besar yang memengaruhi cara pengguna berinteraksi dengan produk Anda
  • Mengganti dependensi atau pustaka inti
  • Perubahan skema database yang sulit dibalikkan
  • Pembaruan kepatuhan atau regulasi di mana Anda memerlukan cutover yang bersih

Namun tidak semua perubahan memerlukan dua lingkungan penuh. Jika Anda men-deploy perbaikan bug kecil yang telah diuji secara menyeluruh, rolling update lebih efisien dan lebih murah. Pertanyaannya menjadi: seberapa besar risiko yang bersedia Anda terima, dan seberapa cepat Anda perlu pulih jika terjadi kesalahan?

Daftar Periksa Praktis

Sebelum Anda mengimplementasikan blue/green deployment, pastikan hal-hal berikut sudah siap:

  • Lingkungan identik. Kedua lingkungan harus menjalankan infrastruktur, konfigurasi, dan kapasitas yang sama. Perbedaan di antara keduanya akan mengalahkan tujuannya.
  • Aplikasi stateless atau sadar sesi. Jika aplikasi Anda menyimpan data sesi secara lokal, pengguna akan kehilangan sesi selama cutover. Gunakan penyimpanan sesi eksternal seperti Redis atau desain untuk stateless.
  • Cutover otomatis. Cutover manual rentan terhadap kesalahan. Otomatiskan peralihan lalu lintas sehingga hanya membutuhkan hitungan detik, bukan menit untuk mengklik.
  • Health check pada lingkungan baru. Jangan hanya deploy dan langsung alihkan. Verifikasi bahwa versi baru lulus health check sebelum mengarahkan lalu lintas ke sana.
  • Monitoring selama dan setelah cutover. Pantau error rate, latensi, dan metrik bisnis segera setelah peralihan. Jika ada yang terlihat salah, rollback dengan cepat.

Intisari Konkret

Blue/green deployment memberi Anda kemampuan untuk mengalihkan semua pengguna ke versi baru secara instan dan mengembalikannya secepat itu. Biayanya adalah menjalankan dua lingkungan, tetapi imbalannya adalah jaring pengaman untuk perubahan berisiko tinggi. Jika tim Anda melakukan rilis besar dan Anda khawatir tentang waktu pemulihan, blue/green layak untuk diinvestasikan. Untuk perubahan yang lebih kecil, tetap gunakan rolling update. Strategi yang tepat tergantung pada risikonya, bukan pada mana yang terdengar lebih mengesankan.