Belajar GitLab CI/CD - Progressive Delivery (Canary & Blue-Green Deployments)

#Pendahuluan

Di episode 16 kita berhasil mendeploy ke Kubernetes lewat GitLab Agent. Namun pertanyaan sebenarnya muncul sesaat setelah tombol deploy ditekan: "Bagaimana jika versi baru ini bermasalah?" Metode deploy satu gerakan penuh (all-at-once) membuat kesalahan kecil sekalipun berdampak ke seluruh pengguna. Progressive delivery menjawabnya dengan memperlakukan release sebagai proses bertahap, bukan momen sekali jalan.

#Konsep Progressive Delivery

Analoginya: ketika bandara membangun landasan pacu baru, mereka tidak menutup semua landasan lama lalu membuka yang baru sekaligus. Pesawat pertama yang mendarat di landasan baru adalah kru uji dan insinyur. Setelah terbukti aman, diizinkan penerbangan komersial tertentu, lalu akhirnya seluruhnya. Progressive delivery menerapkan logika yang sama pada software: kirim versi baru ke sebagian kecil pengguna, amati, lalu perluas.

Progressive delivery mencakup tiga strategi umum:

Strategi	Mekanisme	Risiko	Waktu Rilis
Rolling update	Pod lama diganti bertahap	Rendah	Sedang
Canary	Traffic sebagian ke versi baru	Sangat rendah	Panjang
Blue-green	Dua environment, switch penuh	Rendah	Singkat

Rolling update sudah menjadi default Kubernetes. Canary lebih halus: hanya sebagian traffic. Blue-green menjaga dua versi hidup berdampingan lalu memindahkan seluruh traffic sekaligus — cepat, tapi butuh kapasitas dua kali lipat.

#Canary Deployment di GitLab CI

Tujuannya: kirim versi baru dengan 10 persen traffic, verifikasi, lalu naikkan ke 100 persen. Di GitLab, kita menjadikannya dua langkah pipeline yang dipisah oleh health check.

Pipeline canary - 10 persen lalu 100 persen

stages:
  - canary
  - production
 
deploy_canary:
  stage: canary
  image: alpine/helm:latest
  script:
    - helm upgrade --install my-app ./chart
      --set canary.enabled=true
      --set canary.weight=10
      --set image.tag=$CI_COMMIT_SHA
  environment:
    name: production/canary
    url: https://myapp.example.com

Job ini memasang chart dengan 10 persen weight menuju pod versi baru. Environment production/canary menandai bahwa ini sub-environment dari production, jadi GitLab menampilkannya terpisah di halaman Environments namun tetap terhubung dengan environment induknya.

#Health Check Sebelum Promosi

Setelah canary berjalan, kita tidak boleh langsung mempromosikannya secara membabi buta. Sebuah job verifikasi mengecek metrik 5xx lewat Prometheus. Jika error rate rendah, promosi berlanjut; jika tidak, pipeline gagal — dan di sinilah rollback otomatis dimainkan:

Health check metrik 5xx dari Prometheus

error_rate=$(curl -s "http://prometheus.example.com/api/v1/query" \
  --data-urlencode 'query=sum(rate(http_requests_total{status=~"5..",app="my-app"}[5m])) / sum(rate(http_requests_total{app="my-app"}[5m]))' \
  | jq -r '.data.result[0].value[1]')
 
threshold=0.01
if (( $(echo "$error_rate > $threshold" | bc -l) )); then
  helm rollback my-app 1
  echo "Canary bermasalah, rollback ke revisi 1"
  exit 1
fi

Script ini menghitung rasio request 5xx selama lima menit terakhir. Nilai threshold=0.01 berarti 1 persen error adalah batas toleransi. Jika terlampaui, helm rollback mengembalikan release ke revisi sebelumnya dan job keluar dengan kode error — membuat pipeline merah sebagai sinyal.

Warning

Rollback otomatis hanya efektif jika metriknya diambil dari sumber yang benar. Pastikan label Prometheus pada query (misalnya app="my-app") cocok dengan label yang di-export aplikasi kalian. Query yang salah justru akan selalu hijau dan tidak pernah melakukan rollback.

#Promosi ke 100 Persen

Health check lulus, sekarang saatnya membesarkan canary menjadi penuh:

Job promosi canary ke production penuh

promote_production:
  stage: production
  image: alpine/helm:latest
  script:
    - helm upgrade --install my-app ./chart
      --set canary.weight=100
      --set image.tag=$CI_COMMIT_SHA
  environment:
    name: production
    url: https://myapp.example.com

Weight diubah menjadi 100, seluruh traffic mengalir ke versi baru, dan environment production/canary otomatis tidak relevan lagi. Seluruh proses bisa diulang untuk setiap release.

#Blue-Green Deployment

Jika tim kalian lebih suka switch instan dan memiliki kapasitas cadangan, blue-green mempertahankan dua environment permanen: blue dan green. Versi baru di-deploy ke environment yang sedang tidak melayani traffic, diuji, lalu service dialihkan:

Service blue-green memilih warna aktif

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app
    color: green

Pipeline akan mengubah selector warna saat deploy. Karena selector hanya dua baris yang berubah, switch bisa dilakukan kapan saja — termasuk rollback, cukup ganti kembali ke blue. Kelemahannya jelas: dua set resource selalu berjalan, sehingga biaya cluster naik.

Tip

Mulailah dari canary. Blue-green menarik untuk kapasitas besar dan tim yang butuh switch instan, tetapi biaya dua environment sering mengejutkan. Canary memberi pelajaran observability yang lebih baik dengan biaya yang jauh lebih kecil.

#Penutup

Progressive delivery mengubah rilis dari peristiwa menegangkan menjadi proses terukur:

Traffic bertahap (canary) atau switch instan (blue-green) meminimalkan dampak kegagalan.
Environment production/canary di GitLab menandai sub-deploy canary.
Health check berbasis Prometheus menahan promosi ketika error rate melewati ambang batas.
Rollback otomatis lewat helm memulihkan layanan tanpa menunggu manusia.
Pilih canary sebagai titik awal; blue-green saat membutuhkan switch cepat.

Di episode 18 selanjutnya kita membahas Auto DevOps dan CI/CD Component Catalog — cara membuat pipeline "gratis" dan komponen yang bisa dipakai ulang lintas tim. Sampai jumpa!