Blue-Green Deployment: Strategi DevOps untuk Nol Downtime

Saat pertama kali saya bekerja sebagai engineer MLOps, saya harus meluncurkan sebuah aplikasi kecil yang menyertakan model ML untuk klasifikasi gambar. Peluncuran awal berjalan lancar. Namun ketika saya memperbarui modelnya, kekacauan pun dimulai. Pertama-tama, Pod yang menampung model baru saya tidak mau berjalan karena ada beberapa perbedaan antara lingkungan pengujian dan lingkungan produksi. Selain itu, pelanggan tidak bisa bekerja karena Pod yang menampung model lama sudah diganti dengan Pod baru saya yang tidak bisa start. Ini mimpi buruk. Saya kemudian harus melakukan rollback secara manual dan meminta maaf kepada para pengguna model tersebut. 

Namun, saya belajar dari pengalaman itu dan beralih menggunakan strategi blue-green deployment. Pendekatan DevOps ini memungkinkan pengiriman pembaruan baru tanpa downtime atau rollback tengah malam. 

Dalam panduan ini, saya akan mengajak Anda melihat seperti apa blue-green deployment dalam praktik. Cara menyiapkannya, trade-off yang ada, pelajaran yang tidak Anda dapatkan dari dokumentasi. Baik Anda membangun layanan ML, API, atau aplikasi full-stack, pendekatan ini dapat memberikan jaring pengaman yang dibutuhkan tim Anda untuk meluncurkan fitur baru dengan percaya diri.

Memahami Blue-Green Deployment

Blue-green deployment terdengar lebih rumit daripada kenyataannya (setidaknya bagi saya, awalnya tampak sulit ketika pertama kali mendengarnya). 

Ini hanyalah trik cerdas untuk merilis versi baru tanpa mengganggu pengguna. Caranya dengan mempertahankan dua lingkungan produksi yang identik dan mengalihkan trafik di antara keduanya. 

Jika Anda pernah menghadapi masalah aplikasi yang berfungsi di staging tetapi crash di produksi, strategi ini adalah pilihan yang tepat untuk Anda!

Arsitektur inti dan mekanisme operasional

Gagasan dasarnya: Anda mempertahankan dua lingkungan produksi yang identik. Satu disebut blue dan satu lagi green.

Lingkungan blue adalah lingkungan yang saat ini digunakan pengguna. Ketika Anda memiliki versi baru yang ingin dirilis, Anda menerapkannya ke lingkungan green, mengujinya, dan ketika yakin sudah berfungsi, Anda mengalihkan trafik produksi dari lingkungan blue ke green.

Strategi ini menghasilkan tanpa downtime, tanpa “maaf kami sedang memperbarui”. Hanya transisi tersembunyi di balik layar yang bahkan tidak disadari pengguna.

Dalam praktiknya, keajaiban terjadi di load balancer. Anda mengonfigurasinya untuk merutekan trafik ke salah satu lingkungan, bergantung pada status deployment. Ini memberikan kontrol trafik yang halus dan membuat rollback semudah mengalihkan trafik kembali ke lingkungan blue. 

Strategi ini menjawab momen “tapi di staging berfungsi” yang saya alami dengan model ML baru saya. Karena lingkungan green juga merupakan lingkungan produksi, Anda menguji dunia nyata sebelum pengguna benar-benar menggunakannya.

Berikut gambaran singkat alur tipikalnya: 

1. Deploy versi baru ke green.
2. Jalankan pengujian integrasi dan smoke test.
3. Alihkan trafik menggunakan load balancer. 
4. Pantau green untuk setiap anomali.
5. Jika semuanya berjalan baik, turunkan blue atau pertahankan jika Anda ingin rollback.

Blue-green deployment Fase 1: Aplikasi baru di green untuk pengujian, trafik masih diarahkan ke blue (Gambar oleh penulis).

Blue-green deployment Fase 2: Trafik dialihkan ke lingkungan green (Gambar oleh penulis). 

Evolusi historis dan adopsi industri

Pendekatan blue‑green dinamai dan digunakan di ThoughtWorks sekitar tahun 2005 oleh Daniel Terhorst‑North dan Jez Humble. Kemudian didokumentasikan dan dipopulerkan dalam buku Continuous Delivery (2010) oleh Jez Humble dan Dave Farley.

Sejak itu, pendekatan ini digunakan di mana-mana, mulai dari startup hingga raksasa cloud-native masa kini, seperti Netflix dan siapa pun yang melakukan deployment berkali-kali per hari tanpa drama.

Platform cloud mempercepat pergeseran ini. Dengan infrastructure-as-code, auto-scaling groups, dan alat orkestrasi kontainer seperti Kubernetes, menyiapkan dan memelihara lingkungan duplikat menjadi sederhana.

Blue-green deployment bahkan menginspirasi model deployment lain, seperti rilis canary dan feature flag. Jika Anda memahami blue-green, Anda juga mendapatkan fondasi untuk memahami yang lain.

Baru mengenal DevOps? Mulailah dengan kursus Konsep DevOps. Dasar yang jelas dan praktis untuk membantu Anda memahami strategi inti sebelum terjun ke alur kerja lanjutan.

Manfaat Utama Blue-Green Deployment

Sejujurnya, saat pertama kali mendengar blue-green deployment, saya pikir tidak masuk akal memelihara dua lingkungan produksi. Namun, saya melihat betapa mudahnya meluncurkan model ML baru dan betapa berkurangnya keluhan serta eskalasi dari pengguna, yang menunjukkan bahwa usaha tersebut sepadan.

Pada bab berikutnya, saya akan menyoroti manfaat blue-green deployment.

Downtime nyaris nol

Ini yang paling jelas, karena tidak ada yang menginginkan downtime.

Dengan blue-green, Anda dapat langsung mengalihkan trafik dari lingkungan lama ke yang baru tanpa menunggu layanan menurun. Pengguna Anda tidak pernah menyadari peralihan tersebut, dan memang seharusnya begitu.

Ini sangat berdampak saat Anda menjalankan API yang berhadapan dengan pengguna, dasbor, atau pipeline ML yang tidak bisa menerima gangguan beberapa menit sekalipun.

Rollback mudah

Bayangkan Anda merilis versi baru dan beberapa menit kemudian menyadari banyak internal server error. Dengan blue-green deployment, Anda cukup mengalihkan load balancer kembali ke lingkungan blue dan memperbaiki error tanpa perlu terburu-buru.

Tingkat keamanan ini membuat tim lebih percaya diri untuk sering merilis. Tidak ada lagi pernyataan “jangan mengubah sistem yang sedang berjalan”.

Pengujian aman di produksi

Anda dapat menguji di produksi tanpa mengekspos pengguna pada risiko. Itulah keunggulan lingkungan green. Anda bisa menjalankan uji beban, pengecekan integrasi, dan bahkan mensimulasikan perilaku pengguna sebelum trafik nyata masuk ke aplikasi.

Tidak seperti lingkungan staging tradisional, Anda menjalankan pengujian pada infrastruktur, konfigurasi, dan segala sesuatu yang sama.

Ini membuat pengujian jauh lebih mencerminkan kenyataan.

Dukungan untuk A/B Testing dan rollout bertahap

Setelah Anda memiliki dua lingkungan produksi identik yang berjalan, Anda bisa melakukan lebih banyak hal. Anda dapat merutekan 90% trafik ke versi blue dan 10% trafik ke versi green. 

Anda juga dapat mengintegrasikan feature flag untuk mengontrol fitur mana yang harus live dan kapan, di mana blue-green deployment menjadi dukungan yang baik sebagai fondasi deployment yang mendasarinya. 

Jika Anda ingin menggali lebih dalam tentang progressive delivery, lihat CI/CD dalam Data Engineering. Ini menguraikan cara menyiapkan pipeline yang mendukung A/B testing dan rollout bertahap.

Pengalaman pengguna yang lebih baik dan kesinambungan bisnis

Blue-green deployment membantu untuk:

• Mengurangi error yang terpapar ke pengguna.
• Meningkatkan waktu respons dari engineering ketika masalah muncul.
• Mempermudah pemulihan backup

Jika Anda menerapkan layanan machine learning yang kritis atau alat data internal yang digunakan orang setiap hari, hal ini sangat penting.

Perencanaan untuk Blue-Green Deployment

Sebelum menerapkan blue-green deployment, penting untuk memahaminya lebih mendalam terlebih dahulu.

Mari kita uraikan apa saja yang Anda perlukan dalam hal arsitektur, pertimbangan biaya, dan kesiapan internal.

Persyaratan infrastruktur

Anda perlu memiliki dua lingkungan produksi yang identik. Ini berarti pengaturan ganda dan perawatan ganda.

Namun sebelum panik soal biaya, ingat bahwa ini tidak selalu berarti biaya menjadi dua kali lipat. Dengan platform cloud atau Kubernetes, Anda dapat menyalakan sumber daya untuk lingkungan green hanya saat dibutuhkan dan mematikannya setelahnya.

Berikut yang dapat membantu menyiapkan dua lingkungan tersebut:

• Infrastructure-as-Code (mis., Terraform) untuk mereplikasi lingkungan dengan cepat.
• Manajemen konfigurasi digunakan untuk mencegah masalah akibat pergeseran konfigurasi.
• Di Kubernetes, gunakan namespace atau objek deployment berbeda untuk blue dan green.

Perlu diingat juga bahwa semuanya menjadi lebih rumit pada setup on-prem, karena Anda harus memastikan:

• Load balancer cukup dapat dikonfigurasi untuk mengalihkan trafik seketika.
• Anda dapat menyediakan lingkungan dengan cepat (mungkin melalui virtualisasi atau kontainer).
• Dependensi eksternal (mis., basis data, API) tersinkron dan terisolasi.

Anda dapat merujuk silang Perbandingan Layanan AWS, Azure, dan GCP untuk memutuskan mana yang paling mudah untuk platform Anda.

Analisis biaya-manfaat

Para skeptis selalu menyoroti peningkatan biaya untuk memelihara dua lingkungan produksi. Dan ya, menjalankan dua lingkungan tidak gratis. Namun, ada trade-off antara peningkatan biaya lingkungan kedua dan biaya downtime bagi bisnis Anda. 

Tanyakan pada diri Anda:

• Apa dampak rata-rata (dalam waktu atau dolar) dari deployment yang gagal?
• Berapa jam yang dibutuhkan untuk debug, rollback, dan menjelaskan outage?
• Seberapa sering Anda merilis dalam tekanan, hanya berharap tidak rusak?

Inilah poin utama penjualan blue-green: lebih sedikit outage, iterasi lebih cepat, dan lebih sedikit tekanan serta burnout pada engineering. 

Tips untuk mengoptimalkan biaya:

• Gunakan auto-scaling untuk menyesuaikan ukuran lingkungan green dengan beban uji.
• Gunakan spot instance atau VM efemeris untuk lingkungan green.
• Jalankan versi green dalam namespace Kubernetes terpisah dan skala ke nol setelah cutover.

Pipeline CI/CD yang terkonfigurasi baik bahkan dapat menangani penskalaan ini secara otomatis.

Prasyarat dan kesiapan organisasi

Bagian ini sering diabaikan, tetapi sangat penting.

Bahkan jika Anda memiliki anggaran untuk infrastruktur dan alat, blue-green deployment tidak akan berhasil kecuali budaya tim dan sistem Anda siap.

Anda akan membutuhkan: 

• Alur kerja CI/CD: Pipeline yang dapat melakukan deploy dan menguji green secara independen.
• Monitoring dan observabilitas: Anda perlu memeriksa metrik sebelum mengalihkan trafik dari blue ke green.
• Strategi rollback yang jelas: Idealnya otomatis, dan pasti dipraktikkan.
• Keselarasan lintas fungsi: Tim Development, Operations, QA, dan Product semuanya harus memahami cara kerjanya.

Jika Anda tidak yakin dengan kondisi tim Anda, pertimbangkan CI/CD untuk Machine Learning. Ini memberikan uraian komprehensif tentang seperti apa setup deployment yang matang dan bagaimana mencapainya.

Implementasi Teknis

Sampai saat ini, kita telah membahas mengapa Anda harus memanfaatkan blue-green deployment. Pada bagian ini, saya akan menunjukkan cara mengimplementasikannya. 

Saya akan menguraikan siklus hidup blue-green deployment yang umum, dengan fokus pada aspek yang menantang yaitu penanganan basis data.

Anda akan mempelajari apa yang harus diotomatisasi, apa yang harus dipantau, dan apa yang tidak boleh dilewatkan.

Siklus hidup deployment standar

Blue-green deployment yang diterapkan dengan baik mengikuti urutan yang tepat. Berikut biasanya tampak dalam praktik:

1. Provision lingkungan green: Nyalakan lingkungan setara produksi yang mencerminkan lingkungan (blue) Anda saat ini, baik di cloud, on-premises, atau menggunakan Kubernetes.
2. Deploy versi baru ke green: Pipeline CI/CD Anda harus membangun dan menerapkan kode di sini, idealnya menandainya sebagai kandidat rilis saat ini.
3. Jalankan pengujian otomatis: Ini mencakup smoke test, pengecekan integrasi, dan health probe apa pun yang mensimulasikan perilaku pengguna. Anda memeriksa apakah green siap untuk pengguna Anda.
4. Pantau log dan metrik: Jika dasbor Anda bersih dan tidak ada peringatan, Anda siap melanjutkan. Jika tidak, perbaiki masalah dan deploy ulang ke green.
5. Alihkan trafik ke green: Konfigurasikan ulang load balancer Anda untuk merutekan semua trafik ke server green.
6. Nonaktifkan blue: Setelah Anda yakin terhadap green, matikan blue, atau pertahankan sebagai cadangan hingga rilis berikutnya.

Buat langkah rollback secepat rollout, sehingga anggota tim dapat membalikkan deployment dalam waktu kurang dari satu menit.

Panduan CI/CD dalam Data Engineering adalah sumber yang sangat baik untuk menyiapkan fase otomatis ini.

Strategi sinkronisasi basis data

Bagian ini rumit. Aplikasi Anda stateless, tetapi basis data Anda tidak. 

Jika Anda tidak menangani bagian ini dengan hati-hati, Anda tidak dapat melakukan rollback dengan mudah, dan seluruh tujuan blue-green deployment menjadi hilang.

Berikut cara menanganinya:

1. Rancang untuk kompatibilitas mundur: Selama peralihan, pengguna mungkin masih mengenai lingkungan blue selama beberapa milidetik. Skema Anda harus bekerja untuk kedua versi aplikasi selama periode itu. 
1. Jangan langsung menghapus atau mengganti nama field.
2. Tambahkan kolom/tabel baru, gunakan nilai default.
3. Hindari constraint ketat sampai kedua versi mendukung perubahan.
2. Versikan migrasi Anda: Gunakan alat seperti Flyway atau Liquibase untuk sistem berbasis Java atau Alembic untuk Python + SQLAlchemy. 
3. Tangani state sesi: Jika aplikasi Anda menggunakan penyimpanan sesi in-memory, peralihan lingkungan dapat membuat pengguna logout atau merusak fungsionalitas. Gunakan Redis, Memcached, atau DB bersama untuk menghindarinya.
4. Validasi konsistensi data pasca-peralihan: Otomatiskan pengecekan pada data kritis untuk memastikan konsistensi.
1. Apakah pengguna dapat masuk? 
2. Apakah perubahan terbaru tersimpan? 
3. Apakah pipeline analitik masih melakukan ingest dengan benar?
5. Pantau drift lambat: Terkadang perubahan tidak menimbulkan error dan tampak berfungsi, tetapi dapat menyebabkan masalah halus, seperti keterlambatan pemrosesan event atau rekaman yang salah bentuk. Gunakan logging dan observabilitas untuk menemukan masalah tersebut sedini mungkin.

Jika Anda tertarik bagaimana menggunakan MLOps pada tingkat setara produksi, saya merekomendasikan kursus MLOps Deployment and Life Cycling.

Analisis Perbandingan dengan Strategi Deployment Lain

Blue-green sering digunakan sebagai fondasi untuk strategi deployment lain, menawarkan variasi untuk mengatasi berbagai masalah dalam proses deployment. 

Tergantung arsitektur, frekuensi rilis, dan toleransi Anda terhadap kompleksitas, pertimbangkan alternatif atau bahkan memadukan beberapa pendekatan menjadi yang baru.

Mari bandingkan skenario paling umum: blue-green vs. canary deployment.

Blue-green vs. canary deployment

Strategi ini sering dipadukan, tetapi dibangun dengan tujuan yang berbeda.

Blue-green adalah model rilis dengan peralihan penuh. Anda menerapkan ke green, mengujinya, dan setelah siap, mengalihkan 100% trafik.

Canary, sebaliknya, adalah peralihan bertahap. Anda menerapkan versi baru berdampingan dengan versi lama dan secara bertahap mengalihkan persentase kecil trafik (mis., 1%, lalu 10%, lalu 50%) sambil memantau potensi masalah.

Perbedaan utama antara kedua strategi:

Saya pribadi menggunakan blue-green untuk menerapkan model ML baru ke produksi, tetapi basis penggunanya terbatas. Jika model saya diekspos ke basis pengguna yang lebih besar, saya mungkin akan lebih memilih rilis canary.

Trade-off infrastruktur dan operasional

Kedua strategi membutuhkan tooling yang baik, tetapi kompleksitasnya berada di area yang berbeda.

Blue-green memerlukan lingkungan yang identik, yang meningkatkan biaya infrastruktur. Namun, routing cukup sederhana, karena hanya melibatkan pengalihan trafik dari satu lingkungan ke lingkungan lainnya. 

Canary, di sisi lain, lebih ringan dari sisi biaya infrastruktur, tetapi memerlukan lebih banyak logika untuk memungkinkan peralihan trafik bertahap. Ini juga membutuhkan observabilitas yang lebih detail untuk menangkap masalah sedini mungkin.

Berikut faktor lain yang perlu Anda pertimbangkan: 

• Monitoring: Canary membutuhkan metrik granular (mis., latensi per pengguna atau per permintaan), sedangkan blue-green hanya perlu mengetahui apakah aplikasi sehat. 
• Alat otomasi: Alat seperti Argo Rollouts mendukung kedua model di Kubernetes, tetapi membutuhkan setup lebih untuk canary.
• Waktu deployment: Blue-green cepat. Canary lebih hati-hati dan memakan waktu.

Jadi, mana yang tepat untuk Anda?

Jika tim Anda masih meningkatkan kematangan CI/CD, blue-green mungkin cara terbaik untuk membangun kepercayaan diri. Blue-green juga titik awal yang baik, memungkinkan Anda mengumpulkan pengalaman. 

Namun, jika Anda memiliki basis pengguna besar atau menerapkan perubahan dengan risiko signifikan (seperti logika penetapan harga), canary bisa menjadi pilihan yang baik.

Untuk tim yang berfokus pada Azure, Tutorial Azure DevOps menunjukkan cara mengimplementasikan CI/CD yang baik di Azure.

Implementasi Spesifik Platform

Cukup dengan teori. Mari lebih teknis. Mari lihat bagaimana blue-green deployment diimplementasikan di berbagai platform yang digunakan tim data setiap hari, seperti Kubernetes, layanan cloud terkelola, dan alat otomasi.

Masing-masing menawarkan fitur berbeda, tetapi gagasan intinya tetap sama. Anda membutuhkan dua lingkungan identik dan satu saklar trafik.

Pola orkestrasi Kubernetes

Menerapkan blue-green deployment dengan Kubernetes itu mudah, karena semua alat yang diperlukan sudah tersedia di Kubernetes. 

Ada beberapa cara untuk menyiapkannya:

• Deployment terpisah: Deploy my-app-blue dan my-app-green sebagai dua deployment terpisah, berbagi label dan service.
• Objek deployment tunggal dengan revisi: Lebih jarang, namun memungkinkan jika Anda menggunakan annotation untuk melacak versi.
• Namespace: Jalankan blue dan green di namespace terpisah untuk isolasi total.

Komponen kunci di sini adalah Kubernetes Service. Ia bertindak sebagai load balancer, mengarahkan trafik ke pod blue atau green melalui label selector.

Misalkan Anda memiliki:

selector:  version: blue

Setelah memvalidasi versi green, Anda memperbarui selector service menjadi version: green dan trafik akan segera dialihkan.

Saya menyarankan menggunakan readinessProbes untuk memastikan versi baru benar-benar siap sebelum merutekan trafik apa pun.

Proses ini dapat diotomatisasi menggunakan alat seperti Argo Rollouts dan Flagger, karena keduanya menangani:

• Pengalihan trafik progresif
• Pemeriksaan kesehatan dan monitoring
• Rollback otomatis jika terjadi crash

Ingin menggali lebih dalam ke infrastruktur berfokus ML? Lihat Fully Automated MLOps.

Layanan terkelola cloud-native

Jika Anda menggunakan AWS, Azure, atau GCP, kabar baiknya adalah blue-green deployment sudah tersedia, dan Anda hanya perlu mengaktifkannya.

AWS CodeDeploy (dengan Elastic Beanstalk atau EC2):

• Menawarkan strategi blue-green deployment khusus
• Anda mendefinisikan lingkungan mana yang green, dan CodeDeploy menangani pengalihan trafik dan rollback

Azure Container Apps atau Azure App Service:

• Azure memungkinkan Anda melakukan staging versi sebagai “slot” dan menukarnya tanpa downtime
• Gabungkan dengan pipeline Azure DevOps untuk otomasi CI/CD penuh

Google Cloud (Cloud Run atau GKE):

• Cloud Run mendukung pembagian trafik bertahap antar revisi, sangat cocok untuk pengujian dan rollout
• Dengan GKE, gunakan aturan load balancer atau Istio untuk mengelola logika blue-green

Setiap penyedia cloud memiliki setup dan fiturnya, tetapi semuanya memudahkan hidup Anda karena Anda tidak perlu banyak mengimplementasikan sendiri. 

Menggunakan layanan terkelola juga selalu membawa manfaat bahwa Anda tidak perlu memelihara semuanya sendiri, karena penyedia cloud memperbarui layanan mereka, dan Anda hanya perlu mengonfigurasinya dengan benar.

Baru di GCP? Lihat Cloud Run: Panduan untuk Mendeploy Aplikasi Berkontainer di GCP.

Contoh dengan Cloud Foundry dan alat lainnya

Cloud Foundry adalah platform-as-a-service (PaaS) open-source yang mengabstraksi banyak infrastruktur dasar, sehingga developer dapat fokus pada pengiriman kode. Ini sangat populer di perusahaan besar karena otomasi, fitur kepatuhan, dan alur kerja deployment yang cepat.

Berikut cara kerja blue-green deployment tipikal di Cloud Foundry menggunakan CLI resmi:

1. Push versi blue dari aplikasi Anda dengan subdomain demo-time:

1. cf create-route example.com --hostname my-appcf push my-appcf map-route my-app example.com --hostname my-app

2. Blue sekarang berjalan, dan router mengirim semua trafik ke my-app.example.com.
2. Push versi green dari aplikasi Anda dengan nama dan rute baru:

1. cf create-route example.com --hostname my-app-tempcf push my-app-greencf map-route my-app-green example.com --hostname my-app-temp

2. Dua instance aplikasi kini aktif berjalan, tetapi menyediakan dua rute tempat Anda dapat mengirim trafik (my-app.example.com untuk blue dan my-app-temp.example.com untuk green).
3. Petakan rute produksi ke green:

1. bashcf map-route my-app-green example.com -n my-app

2. Pada titik ini, versi lama (blue) dan baru (green) sama-sama live, tetapi trafik diarahkan ke keduanya kecuali Anda secara eksplisit menghapus blue.
4. Verifikasi versi green berfungsi dengan benar. Anda dapat mengujinya melalui rutenya atau memantau trafik nyata setelah peralihan.
5. Lepaskan pemetaan rute dari blue, sepenuhnya beralih ke deployment green:

1. cf unmap-route my-app example.com -n my-app

2. Router tidak lagi mengirim trafik ke blue.
6. Hapus aplikasi lama dan rute green (opsional namun direkomendasikan):

cf delete my-appcf unmap-route my-app-green example.com --hostname my-app-temp

Proses ini meminimalkan downtime dan memberi Anda kendali penuh atas kapan dan bagaimana Anda mengganti versi.

Jika Anda ingin lebih meningkatkan alur kerja ini dengan pipeline visual, persetujuan manual, atau rollback otomatis, alat seperti Octopus Deploy, Codefresh, atau Spinnaker adalah opsi yang solid. Alat-alat ini terintegrasi mulus dengan pipeline CI/CD, memungkinkan tim mengotomatiskan siklus hidup deployment yang kompleks.

Praktik Terbaik dan Strategi Optimasi

Blue-green deployment terdengar hebat dan sangat membantu, namun juga dapat menjadi berantakan dengan cepat jika Anda tidak mengelola biaya, risiko, atau otomasi dengan baik. Saya pernah melihat tim kewalahan oleh setup yang terlalu kompleks atau edge case yang tidak terduga. 

Mari lihat apa yang perlu Anda lakukan untuk menghindarinya dan menjadikan strategi blue-green deployment Anda sukses.

Teknik manajemen biaya

Menduplikasi lingkungan tentu menambah biaya. 

Namun Anda dapat meminimalkannya dengan strategi di bawah ini:

• Auto-scaling: Manfaatkan horizontal pod autoscaler atau autoscaling cloud-native untuk menyesuaikan beban kerja aktual dan mencegah pemborosan sumber daya.
• Spot instance & preemptible: Sangat cocok untuk lingkungan green jika Anda hanya menguji (dan siap dengan kemungkinan interupsi).
• Provision sementara: Jangan biarkan lingkungan green berjalan lebih lama dari yang diperlukan. Nyalakan melalui pipeline CI/CD Anda, lalu matikan setelahnya.
• Kontainerisasi: Ringan, cepat, dan hemat biaya, terutama saat berjalan di platform seperti Kubernetes atau Azure Container Apps.

Kerangka validasi otomatis

Jangan pernah mengalihkan trafik tanpa benar-benar yakin bahwa aplikasi green Anda berfungsi sesuai harapan. 

Gunakan lapisan pengujian berikut untuk membangun kepercayaan sebelum peralihan:

• Smoke test: Apakah endpoint kunci aktif dan sehat?
• Uji integrasi: Apakah alur kerja inti (otentikasi, akses data, dll.) berfungsi di versi green?
• Uji end-to-end: Simulasikan perilaku pengguna nyata terhadap rute green sementara (sangat berguna di Cloud Foundry dan Azure).

Integrasikan ini ke dalam pipeline CI/CD Anda sehingga berjalan otomatis setelah deployment berhasil.

Butuh penyegar dalam membangun alur ini? CI/CD untuk Machine Learning membahas bagaimana menyusun validasi otomatis dalam siklus hidup deployment Anda.

Metodologi migrasi basis data

Ini bagian yang rumit, karena aplikasi Anda dapat berjalan di dua lingkungan, tetapi basis data Anda biasanya akhirnya sama untuk keduanya. 

Berikut cara bertransisi dengan aman:

• Perubahan skema yang kompatibel mundur: Selalu asumsikan versi blue mungkin masih menggunakan basis data ketika versi green aktif.
• Feature toggle: Rilis fitur yang bergantung pada skema hanya setelah skema baru diterapkan.
• Migrasi berversi: Gunakan alat seperti Flyway, Alembic, atau Liquibase agar perubahan dapat dilacak dan dibalik.
• Konsistensi sesi/data: Jika Anda bergantung pada state sesi, gunakan penyimpanan eksternal (seperti Redis) yang dapat dibagikan oleh kedua lingkungan.

Feature flag dan progressive delivery

Menggabungkan blue-green dengan feature flag memberikan fleksibilitas yang lebih besar.

Dengan flag, Anda dapat:

• Merilis fitur baru ke subset pengguna dalam lingkungan green
• Menerapkan fitur tetapi tetap menyembunyikannya
• Menguji edge case atau dampak kinerja dengan aman tanpa mengekspos keseluruhan fitur

Manfaatkan alat seperti LaunchDarkly, ConfigCat, atau Unleash untuk menyederhanakan pengelolaan tanpa memerlukan perubahan kode.

Monitoring dan observabilitas yang tangguh

Monitoring dan observabilitas sangat penting untuk mengalihkan trafik dengan aman, karena memungkinkan Anda menilai apakah green benar-benar aman untuk dialihkan dari blue.

Anda harus memiliki: 

• Health check: readinessProbes Kubernetes, URL revisi Azure, dll.
• Logging: Terpusat, dapat dicari, dan diberi tag per lingkungan (blue vs. green).
• Peringatan: Tetapkan ambang batas dan dapatkan notifikasi jika tingkat error meningkat.
• Analisis trafik: Bandingkan perilaku antara blue dan green (mis., latensi, tingkat error, dan throughput).

Namun, monitoring dan observabilitas yang tangguh sebaiknya menjadi bagian dari infrastruktur Anda, terlepas dari apakah Anda menggunakan blue-green deployment atau tidak.

Perencanaan rollback dan pemulihan bencana

Terkadang akan ada yang salah. Tujuannya adalah membuat pemulihan dari kegagalan menjadi semudah dan secepat mungkin. 

Berikut caranya:

• Rollback instan: Selalu pertahankan lingkungan blue sampai Anda memverifikasi green stabil.
• Pemicu rollback otomatis: Gunakan alat seperti Argo Rollouts atau Spinnaker untuk mengembalikan trafik jika metrik kunci gagal.
• Runbook dan playbook: Langkah tertulis sebelumnya untuk tim agar semua orang tahu apa yang harus dilakukan.

Untuk tips otomasi DevOps yang lebih praktis, lihat Tutorial Azure DevOps.

Penguatan keamanan

Memiliki dua lingkungan berarti Anda juga memiliki dua titik serangan potensial.

Beberapa saran untuk memiliki keamanan yang memadai:

• Isolasi lingkungan: Subnet, namespace, atau grup sumber daya cloud terpisah untuk memastikan isolasi.
• Rotasi secret secara berkala: Terutama jika Anda menggunakan kredensial bersama antara blue dan green.
• Patch kedua lingkungan: Jangan biarkan green tertinggal pembaruan keamanan hanya karena belum live.
• Audit log: Tangkap event deployment dan peralihan lingkungan untuk ketertelusuran.

Kesimpulan

Blue-green deployment bukan sekadar strategi deployment mewah yang hanya digunakan proses berlebihan. Ini strategi yang praktis dan andal bagi tim yang memprioritaskan uptime, umpan balik cepat, dan tidur nyenyak di malam hari.

Strategi ini memberi Anda:

• Rollback instan saat ada masalah
• Pengujian setara produksi tanpa risiko pengguna nyata
• Rilis yang lebih bersih dan lebih percaya diri, bahkan di hari Jumat (serius)

Namun apakah sempurna untuk setiap situasi? Menurut saya tidak. Anda perlu memiliki setup CI/CD yang solid, dengan alat yang mendukung perjalanan tersebut. Jika tidak, semuanya bisa cepat berantakan.

Namun itu bukan alasan untuk menghindarinya. Sebaliknya, itu sinyal bahwa Anda harus meningkatkan praktik deployment Anda.

Kami sangat meningkatkan alur rilis kami dengan mengadopsi blue-green deployment dan sejak itu hari rilis menjadi jauh lebih santai, bahkan kami cukup percaya diri untuk melakukan rilis pada hari Jumat.

Jika Anda ingin menggali lebih dalam, mulailah dengan Konsep DevOps atau MLOps Deployment and Life Cycling, karena keduanya akan membantu Anda membangun fondasi tempat blue-green berdiri.

Sekarang, jalankan aplikasi Anda dengan percaya diri.