Belajar GitOps - FluxCD - Blue/Green & A/B Testing

#Pendahuluan

Di episode 16 kalian sudah membedah canary deployment: pergeseran traffic bertahap, analisis metrics, dan rollback otomatis. Namun tidak semua rilis cocok dengan model bertahap itu. Untuk rilis besar atau eksperimen pengguna, ada strategi lain: blue/green dan A/B testing.

Di episode 17 ini kita akan membahas keduanya, ditambah dua praktik pendukung yang sering menyertainya: load testing sebelum promosi dan conformance testing sebagai gerbang kualitas.

#Blue/Green Deployments

Blue/green adalah strategi yang menjaga dua environment penuh secara paralel: blue adalah versi lama, green adalah versi baru. Seluruh traffic tetap di blue sementara green divalidasi, lalu traffic dialihkan secara instan ke green.

Keunggulan blue/green:

• Traffic mirroring — versi baru bisa diuji dengan lalu lintas salinan dari produksi
• Manual promotion — peralihan traffic bisa menunggu keputusan manusia
• Instant rollback — kembali ke blue hanya butuh satu switch
• Zero-downtime updates — tidak ada jeda layanan saat promosi

Di Flagger, blue/green dikonfigurasi dengan stepWeight dan maxWeight bernilai 100. Analisis dijalankan beberapa iterasi tanpa menggeser traffic, lalu seluruh traffic dialihkan sekaligus:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: podinfo
  namespace: test
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: podinfo
  service:
    port: 9898
  analysis:
    interval: 1m
    iterations: 10
    stepWeight: 100
    maxWeight: 100
    metrics:
      - name: request-success-rate
        threshold: 99
        interval: 1m

Dengan konfigurasi ini, Flagger membuat environment green, menjalankan iterations kali analisis, dan hanya mengalihkan traffic setelah semua metrik sehat. Karena seluruh traffic berpindah sekaligus, pastikan environment green sudah diuji dengan beban yang memadai sebelum promosi.

#A/B Testing

A/B testing berbeda dari canary: traffic tidak dibagi berdasarkan persentase, melainkan berdasarkan karakteristik request seperti header atau cookie. Ini memungkinkan sekelompok pengguna tertentu mencoba versi baru sementara sisanya tetap di versi lama.

Penggunaan umum:

• Header-based routing — header kustom, misalnya x-canary: insider, menentukan kelompok eksperimen
• Cookie-based routing — pengguna dengan cookie tertentu diarahkan ke versi baru
• User segmentation — memilih subset pengguna nyata untuk menguji fitur
• Feature flag integration — mengombinasikan routing dengan logika feature flag di aplikasi
• Experimental traffic — mengukur dampak nyata sebelum rilis luas

Di Flagger, A/B testing dikonfigurasi dengan stepWeight: 0 dan aturan match:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: podinfo
  namespace: test
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: podinfo
  service:
    port: 9898
  analysis:
    interval: 1m
    iterations: 10
    stepWeight: 0
    match:
      - headers:
          x-canary:
            exact: "insider"
    metrics:
      - name: request-success-rate
        threshold: 99
        interval: 1m

Jika match menggunakan cookie, struktur yang dipakai adalah cookies dengan aturan yang sama. Selama iterasi berlangsung, Flagger mengarahkan request yang cocok dengan kondisi match ke versi canary dan mengevaluasi metrik pada traffic tersebut. Promosi dilakukan jika semua iterasi lolos.

#Load Testing Integration

Blue/green dan A/B hanya bermakna jika versi baru benar-benar diuji di bawah beban. Flagger mengintegrasikan load tester melalui webhook pada analysis.webhooks.

#Pre-Promotion Load Tests

Webhook load test dijalankan pada setiap iterasi untuk memastikan versi canary mampu menahan lalu lintas:

analysis:
  interval: 1m
  iterations: 10
  webhooks:
    - name: load-test
      url: http://flagger-loadtester.test/
      timeout: 5s
      metadata:
        cmd: "hey -z 1m -c 50 -q 20 http://podinfo-canary.test:9898/"

#Webhook Tests

Webhook tipe lain bisa dipakai untuk verifikasi tambahan, misalnya mengecek endpoint khusus, menjalankan smoke test, atau memvalidasi respons terhadap payload tertentu.

#Concurrency Testing

Parameter pada command load tester mengatur tingkat konkurensi, misalnya -c 50 berarti 50 koneksi paralel. Naikkan nilai ini secara bertahap untuk menemukan titik lemah sebelum traffic produksi menemukannya.

#Performance Baselines

Catat hasil load test versi lama sebagai baseline. Bandingkan latensi dan error rate versi baru terhadap baseline tersebut sebagai salah satu criteria kelulusan.

#Conformance Testing

Selain beban, rilis juga perlu lolos uji kesesuaian terhadap kriteria yang sudah disepakati. Flagger mendukung berbagai pendekatan untuk ini.

#Helm Test Integration

Untuk aplikasi yang dikelola Helm, jalankan helm test sebagai hook sebelum promosi. Hook yang mengembalikan error akan menggagalkan analisis dan memicu rollback:

analysis:
  interval: 1m
  iterations: 5
  webhooks:
    - name: helm-test
      type: rollout
      url: http://flagger-hook.test/
      timeout: 30s
      metadata:
        cmd: "helm test podinfo -n test"

#Custom Test Jobs

Untuk pengujian yang lebih kompleks, jalankan job Kubernetes kustom yang mengeksekusi skenario pengujian, lalu gunakan webhook untuk menunggu hasilnya sebelum analisis dilanjutkan.

#Acceptance Criteria dan Gate Promotion

Gabungkan semuanya menjadi gerbang promosi: load test, helm test, dan webhook tambahan harus lolos pada setiap iterasi. Jika salah satu gagal, Flagger menahan promosi dan traffic kembali ke versi lama. Kriteria ini didokumentasikan langsung di dalam Canary CRD, sehingga seluruh tim bisa melihat apa yang dipersyaratkan sebuah rilis.

#Penutup

Episode 17 menutup fase progressive delivery dengan dua strategi yang melengkapi canary: blue/green dan A/B testing, plus penguatan lewat load testing dan conformance testing.

Inti yang harus dibawa pulang:

• Blue/green menggunakan stepWeight: 100 dan maxWeight: 100, menjaga dua environment penuh dengan rollback instan.
• A/B testing menggunakan stepWeight: 0 dengan match berbasis header atau cookie untuk eksperimen pengguna.
• Load testing dijalankan lewat webhook pada tiap iterasi untuk memvalidasi kapasitas versi baru.
• Conformance testing menggabungkan helm test, job kustom, dan acceptance criteria sebagai gerbang promosi.
• Seluruh strategi diatur dalam satu Canary CRD, sehingga kebijakan rilis terdokumentasi sebagai kode.

Di episode 18 berikutnya kita akan membahas Service Mesh Integration — bagaimana Istio, Linkerd, dan AWS App Mesh bekerja sama dengan FluxCD dan Flagger untuk traffic management, observability, dan visualisasi canary. Sampai jumpa!