Deployment strategy adalah cara mengganti versi lama dengan versi baru di server yang sedang melayani pengguna. Bayangin restoran yang mau ganti menu. Bisa tutup sebentar lalu buka lagi dengan menu baru (recreate). Bisa ganti meja demi meja (rolling). Bisa siapkan dapur kedua yang identik, pindahkan semua pelanggan sekaligus, dan dapur lama tetap siap kalau ada masalah (blue-green). Atau sajikan menu baru ke 1 dari 20 pelanggan dulu, lihat reaksinya, baru ke semua (canary, dari burung kenari yang dulu dibawa penambang untuk mendeteksi gas beracun).
🧪 Tebakan cepat: v1.6.0 punya bug yang membuat 20% request gagal. Dengan canary 5%, rollout-nya dibatalkan setelah menit pertama. Dari 1.000 request per menit, berapa yang sempat sampai ke versi rusak? Tebak dulu, jawabannya ada di bagian "Canary: sebagian kecil dulu".
Panggung yang sama untuk keempat strategi
catatan-api sekarang jalan sebagai 4 container di belakang load balancer nginx, yang membagi request ke container-container itu (nginx dibahas di pelajaran Nginx Basics). Traffic-nya 1.000 request per menit. Versi yang jalan v1.5.0, dan kita mau deploy v1.6.0. Sayangnya v1.6.0 punya bug: upload lampiran gagal 500, dan itu 20% dari semua request. Lab memakai angka-angka ini persis, satu langkah jam = 1 menit.
Tiga ukuran yang dibandingkan: downtime (menit tanpa server yang menjawab), berapa pengguna kena versi rusak, dan berapa lama rollback, yaitu kembali ke versi lama.
Recreate: matikan semua, nyalakan yang baru
Semua container v1.5.0 dihentikan, lalu container v1.6.0 dinyalakan. Mirip yang terjadi waktu docker compose up -d mengganti container lama dengan image baru.
- Menit 1: gak ada container yang siap. Semua 1.000 request dapat
502 Bad Gatewaydari nginx. Itulah downtime. - Menit 2: 100% traffic ke v1.6.0.
- Rollback juga recreate: satu menit downtime lagi, baru v1.5.0 kembali.
Paling sederhana dan gak butuh server tambahan. Cocok untuk staging, atau app yang boleh mati sebentar di jam sepi.
Rolling update: ganti satu per satu
Container diganti bergantian, satu per menit: 25%, 50%, 75%, lalu 100% traffic ke v1.6.0. Selama proses, satu container tambahan dinyalakan dulu sebelum yang lama dimatikan, jadi kapasitas gak pernah turun.
- Zero downtime: selalu ada container yang menjawab.
- Selama rollout, v1.5.0 dan v1.6.0 jalan bersamaan dan memakai database yang sama.
- Rollback juga satu per satu, jadi selambat rollout-nya.
Ini default yang masuk akal untuk kebanyakan app.
Blue-green: dua lingkungan, satu saklar
Blue adalah 4 container v1.5.0 yang sedang melayani. Green adalah 4 container v1.6.0 yang dinyalakan di sampingnya, tanpa traffic. Setelah green siap dan lulus smoke test (cek singkat bahwa app-nya hidup), load balancer dipindah: 100% traffic ke green sekaligus.
- Rollback instan: pindahkan saklarnya kembali ke blue, dalam hitungan detik.
- Biayanya: 8 container selama masa deploy, dua kali lipat.
- Semua pengguna pindah bersamaan, jadi bug di green tetap kena ke semua orang sampai saklarnya dikembalikan.
Canary: sebagian kecil dulu
v1.6.0 cuma menerima 5% traffic dulu. Selama satu menit, error rate (persentase request yang gagal) canary dibandingkan dengan batas, misalnya 1%. Kalau aman, naik ke 25%, 50%, lalu 100%. Kalau melewati batas, rollout dibatalkan otomatis dan semua traffic kembali ke v1.5.0.
Untuk v1.6.0 yang rusak: menit 1 mengirim 5% × 1.000 = 50 request ke versi rusak, 20% di antaranya, yaitu 10 request, gagal. Error rate canary 20% jauh di atas batas 1%, jadi menit 2 sudah 0%. Itu jawaban tebakannya: 50 request, bukan 1.000.
Konfigurasi nginx untuk 5% memakai bobot (weight): 4 container stabil masing-masing weight=19 (total 76) dan 1 canary weight=4, jadi 4 dari 80 = 5% request ke canary.
Perbandingan dengan angka Lab
Rollback ditekan di akhir menit ke-2, canary dibatalkan otomatis setelah menit ke-1:
| Strategi | Downtime | Request ke v1.6.0 | Request gagal | Rollback | Container terbanyak |
|---|---|---|---|---|---|
| Recreate | 2 menit | 1.000 | 2.200 | 2 menit, ada downtime | 4 |
| Rolling | 0 | 1.000 | 200 | 2 menit, bertahap | 5 |
| Blue-green | 0 | 1.000 | 200 | hitungan detik | 8 |
| Canary | 0 | 50 | 10 | otomatis, hitungan detik | 5 |
Memilih strategi
Di latihannya, kebutuhan dicek dengan urutan prioritas, yang pertama cocok menang:
- butuh rollout bertahap (
gradualRollout): canary - butuh rollback instan (
instantRollback): blue-green - butuh tanpa downtime (
zeroDowntime): rolling - mengutamakan kesederhanaan (
simplicity): recreate - selain itu: rolling
Kenapa canary paling atas? Canary juga tanpa downtime dan rollback-nya cepat, jadi kalau rollout bertahap dibutuhkan, dia sudah mencakup sisanya.
⚠️ Jebakan yang sering ketemu
- Migration yang merusak versi lama. Di rolling, blue-green, dan canary, v1.5.0 dan v1.6.0 memakai database yang sama di saat bersamaan. Menghapus atau mengganti nama kolom yang masih dibaca v1.5.0 membuatnya error. Tambah kolom dulu, hapus yang lama di rilis berikutnya.
- Canary tanpa monitoring. Kalau gak ada yang membaca error rate-nya, canary cuma rolling yang lambat. Pasang batas dan pembatalan otomatis.
- Lupa biaya blue-green. Kapasitas dua kali lipat selama deploy, dan blue harus tetap siap sampai kamu yakin green sehat.
- Salah urutan prioritas di latihan.
{ instantRollback: true, gradualRollout: true }hasilnya canary, karena gradual dicek paling dulu.
TL;DR: Recreate mematikan semua versi lama lalu menyalakan yang baru: sederhana, tapi ada downtime, termasuk saat rollback. Rolling mengganti container satu per satu: tanpa downtime, versi lama dan baru jalan bersamaan, rollback sama lambatnya. Blue-green menyiapkan lingkungan kedua lalu memindahkan semua traffic sekaligus: rollback instan, tapi kapasitas dua kali lipat. Canary mengirim sebagian kecil traffic (misalnya 5%) ke versi baru dan menaikkannya bertahap selama error rate di bawah batas, jadi bug cuma sampai ke sedikit pengguna. Urutan pilihan di latihan: gradual ke canary, rollback instan ke blue-green, zero downtime ke rolling, kesederhanaan ke recreate, selain itu rolling.
