Deployment Strategy Overview #

Setiap rilis perangkat lunak adalah sebuah risiko. Kode baru bisa mengandung bug, performa bisa turun, atau ada perubahan perilaku yang tidak terduga. Strategi deployment adalah cara kamu mengelola risiko ini — memilih berapa banyak pengguna yang terekspos lebih dulu, seberapa cepat rollback bisa dilakukan, dan seberapa kompleks infrastruktur yang dibutuhkan. Tidak ada satu strategi yang terbaik untuk semua kasus.

Spektrum Risiko vs Kompleksitas #

                    Risiko rendah ◄─────────────────► Risiko tinggi
                    Kompleks                               Simpel

Blue/Green ─────── Canary ─────── Rolling ─────── Recreate
    │                  │              │                │
Rollback instan    Validasi di    Zero downtime    Ada downtime
Butuh 2x resource  subset user    secara default   Simpel

Setiap strategi melakukan trade-off yang berbeda. Memahami trade-off ini adalah kunci memilih yang tepat — bukan hanya memilih yang paling “canggih”.

Empat Strategi Utama #

Recreate #

Matikan semua Pod versi lama, baru jalankan versi baru. Cara paling sederhana tapi ada downtime.

Recreate:

  v1 v1 v1 v1 v1
      ↓ (semua mati)
  [downtime]
      ↓ (semua dimulai)
  v2 v2 v2 v2 v2

Cocok untuk:
  ✓ Aplikasi yang tidak bisa berjalan dua versi bersamaan
  ✓ Database schema migration yang tidak backward-compatible
  ✓ Development environment di mana downtime tidak masalah
  ✗ Production dengan pengguna aktif

Rolling Update #

Ganti Pod versi lama satu per satu (atau beberapa sekaligus) dengan versi baru. Default di Kubernetes.

Rolling Update:

  v1 v1 v1 v1 v1
  v2 v1 v1 v1 v1   ← Pod pertama diganti
  v2 v2 v1 v1 v1
  v2 v2 v2 v1 v1
  v2 v2 v2 v2 v1
  v2 v2 v2 v2 v2   ← selesai, tidak pernah ada downtime

Selama proses: v1 dan v2 berjalan bersamaan

Blue/Green #

Dua environment identik — satu aktif (blue), satu baru (green). Traffic dipindah sekaligus saat green siap.

Blue/Green:

  blue:  v1 v1 v1 v1 v1  ← traffic masuk ke sini
  green: v2 v2 v2 v2 v2  ← disiapkan, lalu ditest

  Saat siap: traffic dipindah ke green
  blue:  v1 v1 v1 v1 v1  ← standby untuk rollback
  green: v2 v2 v2 v2 v2  ← aktif menerima traffic

Canary #

Rilis versi baru ke sebagian kecil pengguna dulu, pantau, lalu secara bertahap tambah porsinya.

Canary:

  v1 v1 v1 v1  ← 80% traffic
  v2           ← 20% traffic (canary)

  Jika metrik baik → tambah porsi v2
  Jika ada masalah → rollback canary (hapus Pod v2)

  v1 v1        ← 40% traffic
  v2 v2 v2     ← 60% traffic

  v2 v2 v2 v2 v2  ← 100% traffic → selesai

Framework Memilih Strategi #

Pertanyaan 1: Bolehkah ada downtime?
  Tidak boleh sama sekali → Rolling, Blue/Green, atau Canary
  Boleh singkat → Recreate bisa dipertimbangkan

Pertanyaan 2: Apakah v1 dan v2 bisa berjalan bersamaan?
  Ya → Rolling, Canary, atau Blue/Green
  Tidak → Recreate atau Blue/Green (pindah traffic sekaligus)

Pertanyaan 3: Seberapa besar risiko perubahan ini?
  Perubahan kecil (bug fix, config update) → Rolling sudah cukup
  Perubahan besar (fitur baru, refactor API) → Canary atau Blue/Green
  Database migration besar → Recreate dengan maintenance window

Pertanyaan 4: Seberapa cepat harus bisa rollback?
  Butuh rollback instan (dalam detik) → Blue/Green
  Rollback dalam beberapa menit OK → Rolling, Canary
  Rollback bisa makan waktu → Recreate

Pertanyaan 5: Apakah ada resource tambahan yang tersedia?
  Tidak (cluster sudah penuh) → Rolling atau Recreate
  Ya → Blue/Green, Canary

Perbandingan Strategi #

                Recreate  Rolling   Canary    Blue/Green
──────────────────────────────────────────────────────────
Downtime        Ya        Tidak     Tidak     Tidak
Rollback speed  Lambat    Menit     Cepat     Instan
Resource extra  Tidak     Minimal   Sedikit   2x
Kompleksitas    Rendah    Rendah    Menengah  Menengah
Risiko exposure Penuh     Bertahap  Terkontrol Sekaligus
Dua versi bersamaan Tidak Ya       Ya        Tidak

Kombinasi Strategi #

Di produksi yang matang, strategi sering dikombinasikan. Contoh yang umum:

Rilis harian di microservice:
  → Rolling Update (default, low risk, zero downtime)

Rilis fitur besar atau API breaking change:
  → Canary deployment (validasi dengan subset pengguna dulu)

Database migration besar atau perubahan fundamental:
  → Blue/Green dengan maintenance window singkat

Hotfix kritis di luar jam kerja:
  → Recreate jika downtime bisa diterima
  → atau Rolling Update dengan revisionHistoryLimit untuk rollback cepat

Ringkasan #

Tidak ada strategi terbaik universal — setiap strategi melakukan trade-off antara risiko, downtime, kompleksitas, dan kebutuhan resource.
Rolling Update adalah default yang masuk akal — zero downtime, mudah dikonfigurasi, rollback tersedia; cocok untuk sebagian besar rilis rutin.
Blue/Green untuk rollback instan — dua environment berjalan bersamaan; pindah traffic sekaligus; harga: butuh 2x resource selama proses.
Canary untuk validasi bertahap — ekspos versi baru ke sebagian kecil traffic dulu, pantau metrik, baru naik porsi; risiko terkontrol.
Recreate untuk kasus yang benar-benar tidak kompatibel — downtime ada, tapi simpel; hindari di production kecuali ada maintenance window yang disepakati.
Kombinasikan sesuai jenis perubahan — rilis rutin dengan Rolling, fitur besar dengan Canary, perubahan fundamental dengan Blue/Green atau Recreate.

← Sebelumnya: Anti-Pattern Configuration Berikutnya: Rolling Update →