Zero-Downtime Deployment: Blue-Green, Rolling, dan Canary Release

Kenapa "Deploy Saja" Tidak Cukup?

Di masa awal karier, banyak developer berpikir deployment cuma soal menjalankan git pull && pm2 restart. Tapi begitu aplikasi punya pengguna aktif 24/7, restart sederhana berarti setiap deployment = downtime, sekecil apa pun itu. Untuk sistem yang serius soal reliability, kita butuh strategi yang memungkinkan rilis kode baru tanpa pernah benar-benar mematikan layanan.

Tiga strategi paling umum: Rolling Update, Blue-Green Deployment, dan Canary Release. Ketiganya menyelesaikan masalah yang sama dengan trade-off yang berbeda.

Rolling Update: Ganti Perlahan, Satu per Satu

Rolling update mengganti instance lama dengan instance baru secara bertahap—biasanya satu atau beberapa pod/container sekaligus—sambil load balancer terus mengarahkan traffic ke instance yang masih hidup.

# Contoh strategi rolling update di Kubernetes Deployment
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1   # Maksimal 1 pod boleh down bersamaan
      maxSurge: 1         # Maksimal 1 pod ekstra boleh dibuat sementara

Kelebihan: Sederhana, hemat resource (tidak perlu duplikasi infrastruktur penuh), didukung native oleh hampir semua orchestrator (Kubernetes, ECS, Docker Swarm).

Kekurangan: Selama masa transisi, versi lama dan baru berjalan bersamaan. Kalau versi baru punya breaking change di API response atau schema database, permintaan yang mendarat di instance lama vs baru bisa berperilaku beda—ini sumber bug yang sulit dilacak kalau tidak diantisipasi.

Blue-Green Deployment: Dua Lingkungan Identik, Satu Saklar

Blue-Green menjaga dua environment produksi yang identik—sebut saja "Blue" (versi yang sedang live) dan "Green" (versi baru). Setelah Green selesai di-deploy dan lolos smoke test, traffic dialihkan sepenuhnya dari Blue ke Green dalam satu langkah (biasanya dengan mengganti target load balancer atau DNS).

Kelebihan:

• Tidak ada periode dua versi berjalan bersamaan menerima traffic produksi—transisinya atomik.
• Rollback secepat mengganti saklar kembali ke Blue jika ada masalah.

Kekurangan:

• Butuh dua kali resource infrastruktur (minimal selama masa transisi).
• Migrasi database jadi tantangan tersendiri—lihat bagian di bawah.

Canary Release: Uji Coba pada Sebagian Kecil Trafik

Canary release mengarahkan sebagian kecil trafik (misalnya 5%) ke versi baru, memantau metrik kunci (error rate, latency, business metric), lalu secara bertahap menaikkan persentase jika semuanya sehat.

Kelebihan: Risiko blast radius kecil—kalau versi baru bermasalah, hanya sebagian kecil pengguna yang terdampak, dan bisa langsung di-rollback sebelum menyebar.

Kekurangan: Butuh infrastruktur observability yang matang (metrik real-time, alerting) supaya bisa mendeteksi masalah dengan cepat. Tanpa itu, canary cuma jadi rolling update yang lebih lambat.

Jebakan Terbesar: Migrasi Skema Database

Di ketiga strategi di atas, ada satu masalah yang sering diabaikan pemula: selama masa transisi, kode versi lama dan versi baru bisa jadi sama-sama mengakses database yang sama. Kalau migrasi schema Anda tidak backward-compatible, salah satu versi akan gagal.

Solusinya adalah pendekatan expand-contract (juga disebut parallel change):

1. Expand: Tambahkan kolom/tabel baru tanpa menghapus yang lama. Deploy kode yang bisa menulis ke keduanya tapi masih membaca dari yang lama.
2. Migrate: Backfill data dari kolom lama ke kolom baru. Deploy kode yang membaca dari kolom baru.
3. Contract: Setelah yakin semua instance sudah menjalankan kode baru, baru hapus kolom/tabel lama.

Pola inilah yang membuat setiap langkah deployment bisa di-rollback dengan aman—karena database selalu kompatibel dengan versi kode sebelumnya maupun sesudahnya.

Kesimpulan

Tidak ada strategi yang "paling benar"—pilihannya tergantung toleransi risiko, budget infrastruktur, dan kematangan observability tim Anda. Rolling update adalah titik awal yang baik untuk kebanyakan tim. Blue-green cocok ketika Anda butuh rollback instan dan mampu membayar biaya infrastruktur ganda. Canary adalah standar untuk sistem skala besar yang tidak bisa menoleransi regresi menyebar ke seluruh pengguna. Yang paling penting: apa pun strategi deployment-nya, migrasi database yang backward-compatible adalah fondasi yang membuat semuanya benar-benar aman.