Tiga Tuas untuk Rilis yang Lebih Aman: Traffic, Kohor, dan Feature Flag

Kamu memiliki versi baru aplikasi yang siap. Semua tes lulus di staging. Tim merasa percaya diri. Tapi kamu masih ragu sebelum menekan tombol deploy ke production. Keraguan itu wajar. Setiap deployment membawa risiko, dan cara paling aman untuk mengurangi risiko adalah tidak mengirim perubahan ke semua orang sekaligus.

Idenya sederhana: rilis secara bertahap. Namun, bertahap memiliki arti yang berbeda tergantung pada apa yang kamu kendalikan. Saat kamu memutuskan untuk tidak mengirim perubahan ke semua pengguna secara bersamaan, ada tiga tuas independen yang bisa kamu tarik. Masing-masing mengendalikan aspek rilis yang berbeda. Memahami kapan menggunakan masing-masing tuas, dan bagaimana menggabungkannya, adalah yang membedakan rilis yang terkendali dari sebuah perjudian.

Traffic: Mengontrol Seberapa Banyak Beban yang Mengenai Versi Baru

Cara paling langsung untuk rilis bertahap adalah dengan mengontrol proporsi permintaan yang mencapai versi baru. Alih-alih merutekan semua traffic ke aplikasi yang diperbarui, kamu hanya mengirim sebagian kecil saja. Lima persen dari semua permintaan masuk ke versi baru. Sembilan puluh lima persen sisanya terus mengenai versi lama.

Pendekatan ini disebut traffic splitting. Kamu mengonfigurasinya di tingkat infrastruktur: load balancer, service mesh, atau API gateway. Konfigurasinya sederhana. Kamu menentukan persentase, dan infrastruktur mendistribusikan permintaan sesuai dengan itu. Tidak ada identitas pengguna yang terlibat. Tidak ada logika penargetan. Hanya proporsi mentah dari traffic jaringan.

Traffic splitting ideal untuk tahap validasi paling awal. Kamu ingin tahu apakah versi baru crash saat startup, menghasilkan error di bawah beban nyata, atau mengonsumsi lebih banyak memori dari yang diharapkan. Karena sampelnya acak, kamu mendapatkan sinyal cepat tentang kesehatan dasar. Jika tingkat error melonjak, kamu menghentikan rilis sebelum sebagian besar pengguna terpengaruh.

Berikut adalah contoh realistis menggunakan VirtualService Istio untuk membagi traffic 5% ke versi baru dan 95% ke versi lama:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - myapp.example.com
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: myapp
        subset: v2
      weight: 5
    - destination:
        host: myapp
        subset: v1
      weight: 95

Keterbatasannya jelas: kamu tidak bisa mengontrol siapa yang mendapatkan versi baru. Pengguna yang sama mungkin mengenai versi baru pada satu permintaan dan versi lama pada permintaan berikutnya. Ketidakkonsistenan itu tidak masalah untuk validasi infrastruktur, tetapi menjadi masalah saat kamu perlu mengamati perilaku dari waktu ke waktu atau mengumpulkan umpan balik dari pengguna tertentu.

Kohor: Mengontrol Siapa yang Mendapatkan Versi Baru

Saat kamu perlu menargetkan pengguna tertentu, traffic splitting saja tidak cukup. Kamu ingin penguji internal melihat versi baru terlebih dahulu. Atau pengguna beta. Atau pengguna di wilayah tertentu. Atau akun dengan tingkat langganan tertentu. Di sinilah kohor berperan.

Kohor adalah sekelompok pengguna yang ditentukan oleh kriteria: rentang ID pengguna, lokasi geografis, tipe akun, segmen bisnis, atau atribut lain yang diketahui sistemmu. Alih-alih merutekan persentase traffic acak, kamu merutekan semua traffic dari kohor tertentu ke versi baru. Ini disebut staged rollout.

Keuntungan dibandingkan traffic splitting adalah ketertelusuran. Saat kamu rilis ke kohor pengguna internal, kamu tahu persis siapa yang melihat versi baru. Jika mereka melaporkan masalah, kamu dapat menghubungkan masalah tersebut dengan perubahan spesifik. Jika kohornya kecil dan terkendali, radius ledakannya terbatas. Kamu dapat mengamati pola penggunaan nyata, bukan hanya tingkat error.

Kohor juga memungkinkan ekspansi progresif. Kamu mulai dengan pengguna internal, lalu berkembang ke pengguna beta, lalu ke lima persen pengguna produksi di wilayah tertentu, lalu ke dua puluh lima persen, dan seterusnya. Di setiap tahap, kamu memiliki kelompok pengguna yang dikenal yang memberikan sinyal. Rilis menjadi serangkaian ekspansi yang disengaja, bukan keputusan biner tunggal.

Tukar risikonya adalah kompleksitas. Kamu membutuhkan infrastruktur untuk mengidentifikasi dan merutekan pengguna berdasarkan atribut. Load balancer atau gateway-mu harus memahami identitas pengguna, bukan hanya jalur permintaan. Ini seringkali membutuhkan integrasi dengan sistem autentikasi, basis data pengguna, atau manajemen sesi. Ini lebih banyak pekerjaan untuk diatur daripada traffic splitting, tetapi memberikan kontrol yang jauh lebih kaya.

Fitur: Mengontrol Fungsionalitas Apa yang Aktif

Traffic dan kohor mengontrol versi aplikasi mana yang dijalankan pengguna. Namun terkadang kamu ingin men-deploy versi baru di mana-mana dan secara selektif mengaktifkan fitur tertentu di dalamnya. Mungkin versi baru sudah berjalan di semua server, tetapi fitur tertentu belum boleh terlihat oleh semua orang. Atau kamu ingin mengaktifkan fitur untuk sebagian pengguna tanpa men-deploy ulang.

Di sinilah feature flag berperan. Feature flag adalah saklar bersyarat dalam kode kamu yang menentukan apakah suatu fitur aktif untuk pengguna tertentu. Flag dapat diaktifkan atau dinonaktifkan saat runtime, tanpa deployment baru. Kamu dapat mengaktifkan fitur untuk sepuluh persen pengguna, untuk akun internal, untuk pengguna dengan ID genap, atau berdasarkan logika apa pun yang kamu tentukan.

Feature flag memisahkan deployment dari aktivasi. Kamu dapat men-deploy kode yang berisi fitur baru berhari-hari atau berminggu-minggu sebelum fitur tersebut benar-benar diaktifkan. Ini mengurangi risiko deployment itu sendiri, karena kamu tidak mengubah perilaku pada saat yang sama dengan mengubah kode. Jika ada yang salah dengan fitur tersebut, kamu menonaktifkan flag. Tidak perlu rollback. Tidak perlu redeployment. Hanya perubahan konfigurasi.

Kekuatan feature flag adalah granularitas. Kamu dapat menargetkan pengguna individu, menjalankan pengujian A/B, secara bertahap meningkatkan eksposur, atau langsung mematikan fitur yang menyebabkan masalah. Namun kekuatan itu datang dengan tanggung jawab. Feature flag menambahkan logika bersyarat ke basis kode kamu. Terlalu banyak flag, atau flag yang tidak pernah dibersihkan, menciptakan utang teknis. Setiap flag yang tetap berada di kode setelah fiturnya sepenuhnya dirilis menjadi beban mati.

Menggabungkan Ketiga Tuas

Ketiga komponen ini tidak saling eksklusif. Dalam praktiknya, strategi progressive delivery yang matang menggunakan semuanya secara bersamaan.

Diagram di bawah menunjukkan bagaimana ketiga tuas bekerja sama dalam urutan progressive delivery yang tipikal.

flowchart TD A[Mulai Rilis] --> B{Validasi Infrastruktur?} B -->|Ya| C[Traffic Splitting] C --> D[Periksa Tingkat Error] D -->|OK| E{Butuh Umpan Balik Pengguna?} D -->|Tinggi| F[Hentikan Rilis] E -->|Ya| G[Rilis Kohor] E -->|Tidak| H{Deploy Kode Sekarang, Aktifkan Nanti?} G --> H H -->|Ya| I[Feature Flag] H -->|Tidak| J[Rilis Penuh] I --> K[Aktifkan Flag Secara Bertahap] K --> L[Pantau & Sesuaikan] L -->|Aman| J L -->|Masalah| M[Nonaktifkan Flag]

Urutan tipikal mungkin terlihat seperti ini:

  1. Deploy versi baru ke persentase kecil traffic menggunakan traffic splitting. Validasi bahwa aplikasi tidak crash atau bocor memori.
  2. Perluas ke kohor pengguna internal menggunakan staged rollout. Kumpulkan umpan balik dan amati pola perilaku.
  3. Setelah yakin, deploy versi baru ke semua server tetapi tetap simpan fitur baru di belakang feature flag. Aktifkan flag untuk sepuluh persen pengguna.
  4. Secara bertahap tingkatkan persentase feature flag sambil memantau metrik. Jika ada yang salah, nonaktifkan flag secara instan.

Setiap tuas memberimu jenis kontrol yang berbeda. Traffic mengontrol seberapa luas versi baru menyebar. Kohor mengontrol siapa yang terpengaruh. Fitur mengontrol fungsionalitas apa yang aktif. Ketika kamu memahami ketiganya, kamu dapat merancang strategi rilis yang sesuai dengan toleransi risiko dan kebutuhan validasi kamu.

Daftar Periksa Praktis

Sebelum rilis berikutnya, ajukan pertanyaan-pertanyaan ini:

  • Apakah saya perlu memvalidasi kesehatan infrastruktur dasar terlebih dahulu? Gunakan traffic splitting.
  • Apakah saya perlu umpan balik dari pengguna tertentu? Gunakan kohor dan staged rollout.
  • Apakah saya ingin men-deploy kode sekarang tetapi mengaktifkan fitur nanti? Gunakan feature flag.
  • Apakah saya memiliki cara untuk mengukur apakah versi atau fitur baru aman? Jika tidak, jangan mulai rilis dulu.

Intisari

Rilis bertahap bukanlah satu teknik. Ini adalah tiga kontrol independen yang memecahkan masalah yang berbeda. Traffic splitting memvalidasi infrastruktur. Kohor memvalidasi pengalaman pengguna. Feature flag memisahkan deployment dari aktivasi. Tim yang rilis dengan aman adalah tim yang tahu tuas mana yang harus ditarik, dan kapan.