Memperbarui aplikasi di server produksi sering terasa seperti mengganti mesin pesawat saat masih terbang. Kode baru mungkin sudah diuji, tetapi kondisi produksi bisa menghadirkan hal-hal yang tidak terlihat di lingkungan pengujian: trafik melonjak, format data lama, koneksi ke layanan eksternal, atau kombinasi perangkat pengguna yang sulit diprediksi.
Blue-green deployment menawarkan pendekatan yang lebih aman. Alih-alih menimpa aplikasi lama secara langsung, kita menyiapkan lingkungan baru di samping lingkungan yang sedang melayani pengguna. Setelah versi baru diperiksa, trafik dialihkan ke sana. Jika muncul masalah, trafik dapat dikembalikan ke lingkungan lama.
Apa itu blue-green deployment?
Dalam pola ini, blue adalah lingkungan yang sedang aktif melayani trafik produksi. Green adalah lingkungan baru yang menjalankan versi aplikasi terbaru, tetapi belum menerima trafik produksi utama.
Kedua lingkungan biasanya memiliki konfigurasi yang sama atau sedekat mungkin: versi runtime, variabel lingkungan, koneksi database, kapasitas server, hingga aturan jaringan. Perbedaannya terutama pada versi aplikasi yang berjalan.
Peralihan trafik biasanya dilakukan melalui load balancer, reverse proxy, service mesh, atau mekanisme routing lain. Setelah lingkungan green dinyatakan sehat, aturan routing diubah sehingga permintaan baru masuk ke green. Lingkungan blue tidak langsung dimatikan agar masih tersedia sebagai jalur pemulihan.
Dokumentasi Amazon ECS menjelaskan pola serupa: versi baru disiapkan, diuji, kemudian trafik dipindahkan dari blue ke green dengan tahap pemantauan sebelum lingkungan lama dihentikan. Ini bukan berarti setiap implementasi harus memakai AWS, tetapi prinsipnya dapat diterapkan pada VPS, Kubernetes, platform cloud, maupun server internal.
Mengapa pola ini menarik?
Keuntungan utamanya adalah blast radius yang lebih kecil. Istilah ini merujuk pada seberapa luas dampak ketika perubahan gagal. Pada deployment langsung, kesalahan pada versi baru dapat segera memengaruhi semua pengguna. Pada blue-green, versi baru bisa diuji lebih dahulu sebelum seluruh trafik dipindahkan.
- Rollback lebih sederhana. Jika error meningkat setelah perpindahan trafik, routing dapat dikembalikan ke blue tanpa harus memasang ulang versi lama di server yang sama.
- Validasi lebih realistis. Tim dapat menguji aplikasi pada infrastruktur yang menyerupai produksi, bukan hanya pada laptop atau server staging kecil.
- Downtime dapat diminimalkan. Lingkungan lama tetap berjalan selama lingkungan baru disiapkan dan diperiksa.
- Proses rilis lebih mudah diulang. Tahapan seperti health check, pengujian endpoint, perpindahan trafik, dan penghapusan lingkungan lama dapat dimasukkan ke pipeline deployment.
Namun, manfaat tersebut datang bersama biaya. Untuk sementara, dua lingkungan harus berjalan bersamaan. Artinya, kebutuhan CPU, RAM, container, instance, atau kapasitas jaringan bisa meningkat. Blue-green bukan pilihan otomatis terbaik untuk semua aplikasi.
Alur kerja yang masuk akal
- Bangun lingkungan green. Provision server atau container baru dengan konfigurasi yang konsisten. Hindari perubahan manual yang hanya dilakukan pada server tertentu.
- Deploy versi aplikasi. Pasang artefak build yang sama dengan yang sudah diuji di pipeline. Sebaiknya deployment menggunakan image atau paket versi tertentu, bukan kode dari branch yang berubah-ubah.
- Lakukan health check. Periksa apakah proses aplikasi hidup, koneksi database tersedia, dependensi utama merespons, dan endpoint penting mengembalikan hasil yang benar.
- Uji dengan trafik terbatas. Jika memungkinkan, arahkan permintaan internal atau trafik pengujian ke green. Beberapa load balancer mendukung listener atau target group terpisah untuk kebutuhan ini.
- Alihkan trafik produksi. Perpindahan bisa dilakukan sekaligus atau bertahap. Untuk aplikasi berisiko tinggi, perpindahan bertahap atau canary release sering lebih aman daripada langsung memindahkan 100 persen trafik.
- Amati masa stabilisasi. Pantau error rate, latency, penggunaan CPU dan memori, antrean, transaksi gagal, serta metrik bisnis seperti pembayaran atau checkout yang berhasil.
- Pertahankan blue untuk sementara. Jangan langsung menghapus lingkungan lama. Simpan sampai tim yakin tidak ada masalah tertunda dan rollback masih dibutuhkan.
Bagian yang sering dilupakan: database
Blue-green relatif mudah untuk aplikasi stateless, yaitu aplikasi yang tidak menyimpan keadaan pengguna hanya di memori server. Tantangannya meningkat ketika aplikasi bergantung pada database, sesi login, file upload, atau cache lokal.
Perubahan skema database harus dibuat kompatibel dengan versi lama dan baru selama masa transisi. Contohnya, jangan langsung menghapus kolom yang masih dibaca oleh versi blue jika green belum sepenuhnya aktif. Pola yang lebih aman adalah menambah kolom terlebih dahulu, merilis kode yang bisa membaca kedua bentuk data, memindahkan data bila perlu, lalu menghapus struktur lama pada rilis berikutnya.
Perhatikan juga sesi pengguna. Jika sesi disimpan di memori lokal server, pengguna dapat tiba-tiba dianggap logout ketika berpindah dari blue ke green. Gunakan penyimpanan sesi bersama atau mekanisme yang memungkinkan kedua versi membaca format sesi yang sama.
Untuk file upload, pastikan blue dan green melihat storage yang sama, misalnya object storage atau volume bersama. Jika masing-masing server memiliki folder upload sendiri, file yang baru diunggah di satu lingkungan bisa tidak terlihat oleh lingkungan lain.
Kapan sebaiknya digunakan?
Blue-green cocok untuk aplikasi yang membutuhkan rilis dengan gangguan minimal, memiliki pipeline deployment yang cukup rapi, dan dapat menjalankan dua lingkungan secara paralel. Contohnya adalah API, dashboard bisnis, aplikasi SaaS, atau website transaksi yang tidak nyaman jika harus mengalami maintenance panjang.
Untuk website kecil dengan satu VPS dan trafik rendah, pola ini bisa terasa berlebihan. Pendekatan sederhana seperti backup, staging sementara, health check, dan rollback manual mungkin sudah memadai. Biaya dan kompleksitas operasional harus dibandingkan dengan nilai layanan yang dilindungi.
Yang bisa dilakukan sekarang
- Catat langkah rollback sebelum melakukan deployment, bukan setelah masalah muncul.
- Pastikan aplikasi memiliki endpoint health check yang benar-benar memeriksa dependensi penting.
- Pisahkan konfigurasi dan rahasia dari kode aplikasi.
- Uji perubahan database dengan asumsi versi lama dan baru hidup bersamaan.
- Siapkan dashboard untuk error rate, latency, kapasitas server, dan metrik bisnis.
- Tentukan berapa lama lingkungan blue dipertahankan setelah perpindahan.
- Hitung biaya menjalankan dua lingkungan sebelum menjadikan blue-green sebagai standar.
Blue-green deployment bukan jaminan bahwa rilis akan selalu berhasil. Ia lebih tepat dipahami sebagai cara untuk membuat kegagalan lebih terisolasi dan pemulihan lebih cepat. Kualitas akhirnya tetap bergantung pada pengujian, observability, kompatibilitas database, dan disiplin tim dalam menjalankan rollback.
Jika deployment selama ini terasa seperti tindakan sekali jalan yang sulit dibatalkan, blue-green dapat menjadi langkah praktis untuk mengubahnya menjadi proses yang punya jalur maju dan jalur kembali.
Sumber & bacaan lebih lanjut
- Amazon ECS blue/green deployments
- Amazon ECS blue/green service deployments workflow
- Deployment methods - Practicing Continuous Integration and Continuous Delivery on AWS
- Architecture strategies for safe deployment practices - Microsoft Azure Well-Architected Framework
– Rio Yotto @rioyotto