Blue-green deployment adalah pola rilis di mana dua environment produksi disiapkan secara paralel: blue sebagai versi aktif saat ini, dan green sebagai versi baru yang sudah dideploy tetapi belum menerima traffic utama. Saat green dinyatakan sehat, traffic dipindahkan dari blue ke green lewat load balancer, reverse proxy, atau mekanisme routing lain. Keuntungan utamanya adalah cutover yang cepat dan rollback yang sederhana, karena versi lama masih tersedia.

Supaya pola ini benar-benar aman, masalah utamanya bukan sekadar “bagaimana memindahkan traffic”, tetapi bagaimana memastikan green kompatibel dengan data, dependency, dan perilaku produksi. Artikel ini membahas alur praktis yang biasanya dipakai tim engineering: persiapan environment green, sinkronisasi konfigurasi, migrasi database yang kompatibel mundur, health check, smoke test, cutover, observability pada menit-menit awal, lalu rollback cepat bila metrik memburuk.

Kapan Blue-Green Deployment Tepat Dipakai

Pola ini cocok bila Anda membutuhkan:

  • Waktu cutover singkat, misalnya untuk API atau aplikasi web dengan SLA ketat.
  • Rollback cepat tanpa perlu rebuild atau redeploy versi lama.
  • Validasi pra-cutover pada environment yang sangat mirip dengan produksi.

Namun ada trade-off yang perlu diterima:

  • Biaya infrastruktur bisa lebih tinggi karena dua environment hidup bersamaan.
  • Sinkronisasi state dan konfigurasi menjadi lebih rumit.
  • Masalah pada database atau dependency bersama tidak otomatis selesai hanya karena compute dipisah dua warna.

Blue-green deployment paling efektif untuk komponen yang relatif stateless. Untuk komponen stateful, terutama database, strategi kompatibilitas mundur dan urutan perubahan jauh lebih penting daripada mekanisme switch traffic itu sendiri.

Arsitektur Minimum yang Perlu Disiapkan

Implementasi vendor-agnostik umumnya membutuhkan komponen berikut:

  • Blue environment: versi produksi aktif.
  • Green environment: versi baru yang identik secara topologi.
  • Traffic switch: load balancer, reverse proxy, service router, atau DNS internal. Untuk cutover cepat, pengalihan di layer load balancer biasanya lebih dapat diprediksi daripada bergantung pada propagasi DNS.
  • Shared observability: metrics, logs, traces, dan dashboard yang bisa memisahkan sinyal blue vs green.
  • Health endpoint: endpoint ringan untuk liveness/readiness, dan endpoint terpisah bila perlu untuk pengecekan dependency penting.

Targetnya bukan hanya “green hidup”, tetapi green benar-benar setara dengan blue dari sisi konfigurasi, dependency, network policy, secret, worker background, dan integrasi eksternal.

Alur Rilis Blue-Green yang Aman

1. Siapkan environment green

Deploy artifact yang sama persis dengan yang akan dirilis ke produksi. Hindari build ulang saat menit terakhir karena akan mengubah jejak artefak yang diuji. Green harus memiliki:

  • Versi aplikasi yang dituju.
  • Konfigurasi yang setara dengan blue, kecuali nilai yang memang berbeda karena identitas environment.
  • Secret dan kredensial yang valid.
  • Akses jaringan ke database, cache, message broker, object storage, dan layanan eksternal.
  • Worker/background process jika aplikasi membutuhkannya.

Kesalahan umum di tahap ini adalah menganggap compute sudah cukup, padahal worker queue, scheduler, atau cron di green belum disiapkan. Akibatnya aplikasi tampak sehat dari luar, tetapi proses async gagal diam-diam setelah cutover.

2. Sinkronkan konfigurasi dan verifikasi dependency

Konfigurasi harus dikelola secara deklaratif dan bisa dibandingkan dengan mudah. Fokus pada hal-hal berikut:

  • Environment variables penting: mode runtime, koneksi database, cache, broker, timeout, pool size, URL layanan internal.
  • Secret: token API, sertifikat, kredensial service account.
  • Dependency eksternal: endpoint payment, email, search, analytics, webhook target, rate limit, allowlist IP.
  • Konfigurasi operasional: level log, tracing sampling, autoscaling rule, resource limit, health check path.

Praktik yang aman adalah menjalankan config diff antara blue dan green untuk memastikan perbedaan hanya yang disengaja. Banyak insiden cutover bukan berasal dari bug aplikasi, tetapi dari timeout yang berbeda, secret kedaluwarsa, atau URL service yang belum diperbarui.

3. Jalankan migrasi yang kompatibel mundur

Ini bagian yang paling sering menentukan berhasil tidaknya rollback. Karena blue dan green bisa bergantian aktif dalam waktu singkat, perubahan skema database harus kompatibel untuk kedua versi, setidaknya selama jendela rilis.

Pendekatan aman biasanya mengikuti urutan expand and contract:

  1. Expand: tambahkan kolom/tabel/index baru tanpa menghapus yang lama.
  2. Deploy aplikasi baru yang bisa membaca/menulis dengan skema lama dan baru bila diperlukan.
  3. Setelah stabil dan rollback window berlalu, lakukan contract: hapus kolom atau perilaku lama secara terpisah.

Contoh perubahan yang relatif aman:

  • Menambah kolom nullable.
  • Menambah index baru.
  • Menambah tabel baru yang belum dipakai versi lama.

Contoh perubahan yang berisiko saat cutover:

  • Mengganti nama kolom yang masih dipakai blue.
  • Menghapus kolom lama sebelum semua traffic pindah dan diverifikasi.
  • Mengubah format data secara destruktif tanpa fase transisi.
-- Lebih aman: tambah kolom baru terlebih dahulu
ALTER TABLE orders ADD COLUMN status_v2 VARCHAR(32) NULL;

-- Aplikasi green dapat menulis ke status dan status_v2 selama masa transisi.
-- Penghapusan kolom lama dilakukan di rilis terpisah setelah rollback window lewat.

Jika ada perubahan format payload event, cache key, atau schema message queue, perlakukan dengan prinsip yang sama: producer dan consumer lama harus tetap bisa hidup berdampingan sementara waktu.

4. Health check dan readiness check

Jangan samakan health check dengan sekadar “proses hidup”. Pisahkan minimal dua jenis sinyal:

  • Liveness: proses tidak macet atau crash.
  • Readiness: instance siap menerima traffic dengan dependency minimum yang dibutuhkan.

Health endpoint yang baik tidak terlalu berat, tetapi cukup mewakili kesiapan aplikasi. Misalnya, readiness bisa memverifikasi koneksi database dan cache secara ringan, sementara pengecekan dependency non-kritis dikelola terpisah agar tidak membuat seluruh service dianggap down ketika layanan sekunder sedang bermasalah.

GET /health/live   - proses hidup
GET /health/ready  - siap terima traffic
GET /health/deps   - status dependency penting untuk diagnosa

Kesalahan umum adalah readiness selalu mengembalikan sukses meskipun koneksi ke database atau broker gagal. Dalam kondisi itu, load balancer akan tetap mengirim traffic ke green dan kegagalan baru terlihat setelah cutover.

5. Lakukan smoke test sebelum cutover

Setelah green lolos readiness, jalankan smoke test ke green secara langsung, tanpa melewati jalur produksi utama. Uji alur yang paling mewakili:

  • Request baca sederhana ke endpoint utama.
  • Alur tulis penting yang melibatkan database.
  • Autentikasi atau otorisasi dasar.
  • Akses ke cache, queue, atau service internal penting.
  • Jika ada frontend, verifikasi asset utama dan panggilan API kunci.

Smoke test tidak harus banyak. Tujuannya adalah menangkap kegagalan besar secepat mungkin: salah secret, salah route, migrasi tidak cocok, atau dependency belum bisa diakses.

# Contoh smoke test sederhana setelah green siap
curl -fsS https://green.internal/api/health/ready
curl -fsS https://green.internal/api/version
curl -fsS -H "Authorization: Bearer <token>" https://green.internal/api/me

6. Cutover traffic secara terkendali

Untuk blue-green deployment, cutover idealnya dilakukan lewat satu kontrol yang jelas: target group load balancer, upstream reverse proxy, atau service routing internal. Prinsipnya:

  • Pastikan green sudah terdaftar dan lolos readiness.
  • Pastikan koneksi lama di blue ditangani dengan baik bila ada draining.
  • Lakukan switch dengan waktu yang dicatat jelas di timeline insiden/rilis.

Jika aplikasi menggunakan koneksi panjang seperti websocket atau stream, definisikan perilaku drain di blue sebelum cutover. Tanpa itu, sebagian klien bisa tetap menempel ke blue lebih lama dari yang Anda kira.

7. Observability ketat pada menit-menit awal

Setelah cutover, jangan langsung menganggap rilis selesai. Beberapa bug baru muncul setelah traffic produksi sebenarnya masuk: pola request berbeda, data nyata lebih kompleks, atau beban internal meningkat. Karena itu, menit-menit awal harus dipantau dengan disiplin.

Sinyal Wajib Dipantau Setelah Cutover

Minimal, dashboard cutover harus memisahkan data green dari blue agar perubahan bisa dibandingkan dengan cepat.

Error rate

Pantau persentase request gagal, termasuk:

  • HTTP 5xx
  • Lonjakan 4xx yang tidak normal, terutama bila berkaitan dengan auth, validation, atau route mismatch
  • Error pada background job atau consumer queue

Error rate sering menjadi sinyal paling cepat bahwa ada regresi fungsional. Namun jangan hanya melihat agregat global; pecah per endpoint, status code, dan jenis operasi penting.

Latency

Lihat latency p50/p95/p99 atau ukuran distribusi setara yang tersedia di sistem Anda. Rata-rata saja sering menipu. Kenaikan latency bisa disebabkan oleh:

  • Query database berubah dan menjadi lebih berat
  • Connection pool tidak cukup
  • Timeout dependency eksternal
  • Cache miss yang meningkat setelah deploy

Bandingkan green terhadap baseline blue sebelum cutover, bukan terhadap angka abstrak.

Saturation

Saturation menunjukkan seberapa dekat resource menuju batas. Pantau setidaknya:

  • CPU dan memory
  • Thread atau worker busy
  • Connection pool database
  • Queue depth dan waktu tunggu job
  • Disk I/O atau network bottleneck bila relevan

Aplikasi bisa tetap mengembalikan 200 pada awalnya, tetapi saturation yang naik tajam sering mendahului error rate dan restart.

Restart dan crash

Restart container/proses yang meningkat segera setelah cutover adalah sinyal serius. Penyebab umum:

  • Out-of-memory
  • Crash loop karena konfigurasi salah
  • Dependency saat startup tidak tersedia
  • Health check terlalu agresif sehingga instance terus diganti

Pantau restart count, exit code bila tersedia, dan log startup.

Anomali log

Log tetap penting meskipun metrics terlihat aman. Cari pola seperti:

  • Error koneksi database atau broker
  • Serialization/deserialization gagal
  • Timeout dependency eksternal
  • Schema mismatch
  • Peringatan auth atau secret tidak valid

Anomali log sering memberi petunjuk lebih cepat tentang akar masalah daripada dashboard agregat.

Jika harus memilih prioritas saat menit awal cutover: lihat error rate, latency, saturation, restart, lalu korelasikan dengan anomali log. Lima sinyal ini biasanya cukup untuk memutuskan lanjut atau rollback dengan cepat.

Checklist Eksekusi Blue-Green Deployment

Sebelum cutover

  • Artifact rilis sudah dibangun dan ditandai dengan versi yang jelas.
  • Green terdeploy penuh dan identik secara topologi dengan blue.
  • Config diff antara blue dan green sudah diverifikasi.
  • Secret, sertifikat, dan kredensial valid.
  • Migrasi database sudah dijalankan dan kompatibel mundur.
  • Readiness check hijau di semua instance green.
  • Smoke test endpoint utama sukses.
  • Dashboard metrics, logs, traces siap dan difilter per warna.
  • Runbook rollback sudah dibuka dan disetujui operator.
  • PIC rilis dan kanal komunikasi insiden sudah aktif.

Saat cutover

  • Catat timestamp cutover.
  • Alihkan traffic ke green melalui satu mekanisme routing yang disepakati.
  • Pastikan connection draining blue berjalan bila diperlukan.
  • Pantau error rate, latency, saturation, restart, dan log secara real time.

Setelah cutover

  • Tunggu jendela observasi awal selesai sebelum menyatakan sukses.
  • Verifikasi alur bisnis penting dari sisi pengguna dan sistem internal.
  • Jangan matikan blue terlalu cepat; simpan selama rollback window yang masuk akal.
  • Jadwalkan cleanup atau contract migration hanya setelah stabil.

Contoh Timeline Insiden Ringan Saat Cutover Gagal

Berikut contoh realistis ketika cutover ke green memicu masalah, tetapi bisa dipulihkan cepat.

  1. 10:00 — Green lolos readiness dan smoke test. Cutover dimulai.
  2. 10:02 — Error rate endpoint POST /orders naik. Endpoint lain normal.
  3. 10:03 — Latency database meningkat, log menunjukkan error serialisasi pada field baru.
  4. 10:04 — Tim memverifikasi bahwa green menulis format baru ke payload yang masih dibaca parser lama di worker bersama.
  5. 10:05 — Diputuskan rollback traffic ke blue.
  6. 10:06 — Traffic kembali ke blue, error rate turun.
  7. 10:10 — Analisis awal menyimpulkan masalah kompatibilitas message schema, bukan compute atau load balancer.

Apa yang bekerja baik di sini:

  • Blue masih siap menerima traffic sehingga rollback cepat.
  • Dashboard dipisah per komponen sehingga endpoint bermasalah segera terlihat.
  • Tim tidak menunggu terlalu lama untuk rollback.

Apa yang kurang:

  • Smoke test tidak mencakup jalur async lewat worker.
  • Verifikasi kompatibilitas schema event belum masuk checklist wajib.

Rollback Cepat yang Benar-Benar Bisa Dipakai

Rollback dalam blue-green deployment seharusnya sederhana: arahkan traffic kembali ke blue. Tetapi rollback yang efektif tetap membutuhkan syarat:

  • Blue masih sehat dan belum diubah secara destruktif.
  • Perubahan skema/data dari green tidak merusak kemampuan blue untuk berjalan.
  • Job async, scheduler, atau consumer tidak terus menulis data yang membuat blue gagal.

Langkah praktis rollback:

  1. Putuskan rollback berdasarkan sinyal yang jelas, bukan firasat.
  2. Alihkan traffic kembali ke blue.
  3. Bekukan aktivitas green yang bisa terus mengubah state, misalnya worker tertentu bila perlu.
  4. Validasi bahwa metrik kembali ke baseline.
  5. Simpan artefak, log, dan timeline untuk analisis akar masalah.

Kesalahan umum adalah tetap membiarkan proses async green aktif setelah traffic dikembalikan ke blue. Akibatnya, sistem terlihat pulih dari sisi request web, padahal state backend masih terus berubah dengan format yang tidak kompatibel.

Contoh Runbook Ringkas

1. Deploy artifact ke green
2. Verifikasi config diff dan secret
3. Jalankan migrasi kompatibel mundur
4. Tunggu readiness semua instance green
5. Jalankan smoke test sinkron dan async penting
6. Aktifkan dashboard cutover
7. Cutover traffic ke green, catat timestamp
8. Pantau 5 sinyal wajib selama jendela observasi awal
9. Jika memburuk, rollback traffic ke blue
10. Nonaktifkan worker green bila perlu untuk mencegah state drift
11. Kumpulkan bukti dan buat postmortem singkat

Postmortem Singkat: Format yang Berguna

Postmortem tidak perlu panjang, tetapi harus cukup tajam untuk mencegah pengulangan.

Ringkasan

Pada cutover blue-green, endpoint pembuatan order gagal karena worker bersama tidak kompatibel dengan schema event baru. Rollback dilakukan dalam beberapa menit dengan mengalihkan traffic kembali ke blue.

Dampak

  • Permintaan pembuatan order gagal sementara.
  • Endpoint baca tetap normal.
  • Tidak ada kehilangan data permanen, tetapi ada job yang perlu diproses ulang.

Akar masalah

Perubahan payload event tidak dirancang kompatibel mundur. Smoke test hanya mencakup jalur HTTP sinkron, tidak mencakup consumer async.

Tindakan perbaikan

  • Tambahkan validasi kompatibilitas schema event dalam checklist rilis.
  • Tambahkan smoke test async terhadap queue/worker.
  • Pastikan rollback juga mencakup penghentian worker green yang relevan.

Tindakan Pencegahan yang Layak Dijadikan Standar

Feature flag untuk memisahkan deploy dari release

Meskipun artikel ini fokus pada blue-green deployment, feature flag tetap sangat berguna. Deploy kode baru ke green tidak harus langsung mengaktifkan semua perilaku baru. Dengan begitu, jika ada regresi, Anda bisa mematikan fitur tertentu tanpa harus mengubah artifact atau database saat itu juga.

Gunakan feature flag terutama untuk:

  • Alur bisnis baru yang berisiko.
  • Query atau cache path baru.
  • Integrasi ke dependency eksternal yang belum lama berubah.

Runbook yang diuji, bukan hanya ditulis

Runbook yang bagus harus bisa dijalankan operator lain tanpa asumsi tersembunyi. Minimal berisi:

  • Urutan langkah deploy, cutover, observasi, rollback.
  • Lokasi dashboard dan query log penting.
  • Kriteria lanjut vs rollback.
  • Perintah atau tindakan untuk menghentikan worker tertentu jika rollback.

Bila memungkinkan, lakukan simulasi ringan di lingkungan non-produksi yang cukup realistis.

Verifikasi dependency end-to-end

Dependency yang sering terlewat saat blue-green deployment:

  • Queue dan worker
  • Scheduled job
  • Webhook callback
  • Object storage dan izin akses
  • Search index
  • Rate limit atau allowlist ke layanan pihak ketiga

Jangan berhenti di pengecekan “port terbuka”. Verifikasi dengan operasi nyata yang mewakili beban produksi.

Bedakan cleanup dari cutover

Jangan gabungkan semua perubahan dalam satu momen. Cutover sebaiknya hanya memindahkan traffic ke green yang sudah siap. Penghapusan kolom lama, pembersihan data transisi, atau penonaktifan kompatibilitas lama dilakukan setelah periode stabil. Ini membuat rollback tetap mungkin.

Kesalahan Umum dalam Blue-Green Deployment

  • Migrasi destruktif terlalu cepat sehingga blue tidak bisa dipakai lagi.
  • Health check terlalu dangkal dan tidak mewakili dependency kritis.
  • Smoke test terlalu sempit, hanya menguji endpoint baca.
  • Observability tidak dipisah per warna, sehingga sulit tahu apakah green benar-benar sumber masalah.
  • Rollback hanya dipikirkan di compute, padahal worker async masih aktif.
  • Blue dimatikan terlalu cepat sebelum jendela observasi selesai.

Penutup

Blue-green deployment memberi jalur rilis yang aman jika Anda memperlakukannya sebagai disiplin operasional, bukan sekadar teknik switch traffic. Kunci keberhasilannya ada pada environment green yang setara, migrasi yang kompatibel mundur, health check yang bermakna, smoke test yang tepat, observability pada menit-menit awal, dan rollback yang benar-benar bisa dijalankan tanpa merusak state.

Jika Anda hanya mengambil satu prinsip dari artikel ini, ambil yang ini: desain rilis sehingga versi lama dan baru bisa hidup berdampingan untuk sementara. Dengan itu, cutover menjadi lebih tenang, rollback lebih cepat, dan insiden lebih mudah dibatasi sebelum meluas.