Membuka Fitur ke Sebagian Pengguna Terlebih Dahulu

Kamu punya mesin rekomendasi baru yang siap digunakan. Tim sudah percaya diri. Tes sudah lulus. Code review sudah selesai. Tapi ada sesuatu yang menghentikanmu untuk langsung mengaktifkannya untuk semua orang sekaligus. Bagaimana jika logika baru berfungsi baik di staging tetapi berperilaku berbeda di bawah lalu lintas nyata? Bagaimana jika itu memperlambat halaman bagi pengguna dengan koneksi lambat? Bagaimana jika merekomendasikan sesuatu yang memalukan?

Keraguan ini sehat. Cara paling aman untuk merilis fitur adalah dengan membiarkan sekelompok kecil pengguna melihatnya terlebih dahulu. Jika berhasil, buka lebih lebar. Jika ada yang rusak, hanya kelompok kecil itu yang terpengaruh. Pola ini disebut progressive rollout, dan ini adalah salah satu penggunaan paling praktis dari feature flag di produksi.

Pendekatan Paling Sederhana: Rollout Berbasis Persentase

Cara paling langsung untuk mengontrol eksposur adalah dengan persentase lalu lintas. Bayangkan kamu ingin menguji fitur rekomendasi baru itu. Kamu buka dashboard feature flag dan atur flag ke 5%. Dari setiap seratus permintaan, lima akan melihat rekomendasi baru. Sembilan puluh lima lainnya akan melihat versi lama.

Persentase ini dapat ditingkatkan secara bertahap. Mulai dari 5%. Pantau tingkat kesalahan, waktu respons, dan umpan balik pengguna. Jika semuanya terlihat baik, naikkan ke 10%, lalu 25%, lalu 50%. Ketika kamu yakin fitur sudah stabil, atur ke 100% dan hapus kode lama.

Keindahan dari pendekatan ini adalah kamu bisa membalikkannya secara instan. Jika tingkat kesalahan melonjak di 25%, kamu turunkan persentase kembali ke 10% atau matikan flag sepenuhnya. Tidak perlu rollback. Tidak perlu redeploy. Hanya perubahan konfigurasi.

Ketika Persentase Tidak Cukup

Terkadang kamu membutuhkan kontrol lebih dari sekadar persentase sederhana. Kamu mungkin ingin pengguna tertentu mencoba fitur terlebih dahulu. Penguji internal, anggota tim QA, atau pelanggan ramah yang setuju untuk beta test. Untuk ini, feature flag kamu membutuhkan aturan penargetan.

Aturan penargetan yang paling umum didasarkan pada ID pengguna. Kamu memelihara daftar ID pengguna yang diizinkan melihat fitur baru. Semua orang lain melihat versi lama. Ini berguna untuk pengujian beta terkontrol: kamu mengundang segelintir pengguna untuk mencoba fitur lebih awal, sementara basis pengguna lainnya tidak tahu bahwa fitur itu ada.

Aturan penargetan lainnya adalah berdasarkan wilayah. Kamu mungkin membuka fitur untuk pengguna di Indonesia terlebih dahulu, sementara pengguna di negara lain melanjutkan dengan versi lama. Ini membantu ketika fitur perlu mematuhi peraturan setempat, atau ketika kamu ingin melihat bagaimana kinerjanya dalam kondisi jaringan atau pola perilaku pengguna tertentu.

Kamu juga dapat menargetkan berdasarkan jenis akun, versi aplikasi, model perangkat, atau atribut apa pun yang diketahui sistem tentang pengguna. Semakin banyak atribut yang kamu miliki, semakin tepat kamu dapat mengontrol siapa yang melihat apa.

Masalah Konsistensi

Saat kamu menggunakan rollout berbasis persentase, kamu harus memastikan konsistensi. Pengguna yang sama harus selalu melihat versi yang sama selama sesi. Jika seorang pengguna melihat fitur baru pada satu muatan halaman dan versi lama pada muatan berikutnya, mereka akan bingung. Fitur muncul dan menghilang secara acak.

Perbaikannya adalah dengan mendasarkan perhitungan persentase pada pengidentifikasi yang stabil. Hash ID pengguna atau ID sesi, lalu gunakan hash itu untuk menentukan kelompok mana yang dimasuki pengguna. Selama ID pengguna tetap sama, hasil hash tetap sama, dan pengguna mendapatkan perlakuan yang konsisten.

Inilah mengapa kamu tidak boleh menggunakan generator angka acak untuk rollout berbasis persentase. Angka acak berubah setiap kali kode dijalankan. Hash dari pengidentifikasi yang stabil memberikan perilaku deterministik.

Progressive Rollout vs. Canary Release

Kamu mungkin pernah mendengar tentang canary release. Dalam canary release, kamu menyebarkan versi baru aplikasi ke subset server. Lalu lintas diarahkan ke server tersebut berdasarkan aturan load balancer. Jika server canary menunjukkan masalah, kamu mengarahkan lalu lintas menjauh darinya.

Progressive rollout dengan feature flag berbeda. Semua server menjalankan kode yang sama. Flag menentukan siapa yang melihat fitur baru. Kamu tidak perlu mengelola routing server atau konfigurasi load balancer. Kamu hanya mengubah nilai flag.

Diagram alir berikut membandingkan kedua pendekatan:

flowchart TD A[Mulai: 5% pengguna] --> B[Pantau metrik] B --> C{Ada kesalahan atau masalah?} C -->|Tidak| D[Tingkatkan ke 10%] D --> E[Pantau lagi] E --> F{Stabil?} F -->|Ya| G[Lanjutkan ke 25%, 50%, 100%] F -->|Tidak| H[Kembali ke level sebelumnya] C -->|Ya| I[Kembali ke 0%] I --> J[Selidiki dan perbaiki] J --> A K[Canary release: arahkan lalu lintas ke subset server] --> L[Pantau metrik server] L --> M{Sehat?} M -->|Ya| N[Tingkatkan lalu lintas canary] M -->|Tidak| O[Arahkan lalu lintas menjauh]

Perbedaan ini penting bagi tim yang menyebarkan ke banyak server atau menggunakan orkestrasi kontainer. Dengan feature flag, kamu tidak perlu memelihara beberapa versi aplikasi di produksi. Setiap server memiliki biner yang sama. Flag adalah satu-satunya perbedaan.

Efek Psikologis

Progressive rollout bukan hanya praktik teknis. Ini mengubah cara tim merasa tentang merilis perangkat lunak. Ketika kamu tahu bahwa fitur buruk hanya akan mempengaruhi 5% pengguna, kamu lebih bersedia untuk mengirimkan. Kamu berhenti memperlakukan rilis sebagai peristiwa berisiko tinggi dan mulai memperlakukannya sebagai eksperimen bertahap.

Pengguna yang kebetulan berada di kelompok pertama tidak merasa dirugikan. Mereka memahami bahwa mereka mencoba sesuatu yang baru. Beberapa pengguna bahkan menikmati menjadi pengadopsi awal. Dan ketika ada yang salah, kamu bisa mematikan flag tanpa panik. Tidak ada rollback darurat. Tidak ada insiden yang membutuhkan semua orang. Hanya perubahan konfigurasi dan catatan untuk diselidiki.

Daftar Periksa Praktis untuk Progressive Rollout

Sebelum kamu membuka fitur ke subset pengguna, jalankan daftar periksa ini:

  • Dapatkah kamu mengidentifikasi pengguna secara konsisten? Gunakan pengidentifikasi stabil seperti ID pengguna atau ID sesi untuk perhitungan persentase.
  • Apakah kamu memiliki pemantauan? Ketahui metrik apa yang harus dipantau: tingkat kesalahan, waktu respons, masalah yang dilaporkan pengguna.
  • Dapatkah kamu mematikan flag secara instan? Pastikan sistem flag merespons dengan cepat dan tidak memerlukan redeploy.
  • Apakah kamu telah menentukan tahapan rollout? Rencanakan persentase: 5%, 10%, 25%, 50%, 100%. Putuskan berapa lama tinggal di setiap tahap.
  • Apakah kamu memiliki rencana rollback? Ambang metrik apa yang memicu penonaktifan flag? Siapa yang membuat keputusan itu?

Kesimpulan

Progressive rollout mengubah rilis fitur dari taruhan semua-atau-tidak sama sekali menjadi eksperimen terkontrol. Mulailah dengan persentase kecil atau grup yang ditargetkan. Pantau metrik. Buka lebih lebar ketika kamu yakin. Tutup secara instan jika ada yang rusak. Pola ini memberi timmu kepercayaan diri untuk mengirimkan lebih sering, karena risikonya selalu terbatas pada sebagian kecil penggunamu.