Saat Feature Flag Sederhana Tidak Lagi Cukup: Beralih ke Platform Terpusat

Tim Anda telah berkembang. Apa yang dimulai sebagai grup kecil dengan segelintir feature flag di file konfigurasi kini berubah menjadi lima tim produk, semuanya melakukan deploy ke environment yang sama, dan mengirimkan fitur hampir setiap hari. Cara lama mengelola flag mulai terasa menyakitkan.

Masalah yang Mulai Muncul

Awalnya, setiap tim mengelola flag mereka sendiri. Ada yang pakai file konfigurasi, ada yang pakai environment variable, atau mungkin dashboard internal sederhana yang dibuat oleh seseorang yang sudah tidak bekerja di perusahaan. Semua berjalan lancar ketika semua orang tahu apa yang dilakukan orang lain.

Tapi sekarang, visibilitas hilang. Tidak ada satu tempat pun untuk melihat flag mana yang aktif, siapa yang membuatnya, atau fitur apa yang dikendalikannya. Flag yang seharusnya bersifat sementara sudah berbulan-bulan berada di production. Tidak ada yang berani menghapusnya karena tidak ada yang tahu apakah sesuatu masih bergantung padanya.

Berikut ini gambaran yang sering terjadi di praktik:

# config/flags.yaml
flags:
  new_checkout: true
  dark_mode: false
  payment_v2: true
  search_autocomplete: true
  beta_onboarding: false
  legacy_report: true
  # tidak ada pemilik, tidak ada deskripsi, tidak ada tanggal pembuatan
  # tidak ada yang tahu apa fungsi 'legacy_report' lagi

Kontrol akses menjadi masalah lain. Di tim kecil, semua orang saling percaya. Sekarang, tidak semua orang seharusnya bisa mengaktifkan flag di production. Mungkin hanya lead engineer atau product manager yang memiliki kewenangan itu. Tapi ketika flag hidup di file konfigurasi atau dashboard bersama, siapa pun dengan akses bisa melakukan perubahan. Kesalahan pun terjadi.

Lalu ada masalah audit. Ketika terjadi kesalahan, Anda perlu tahu siapa yang mengubah apa dan kapan. Tanpa jejak audit yang layak, investigasi insiden berubah menjadi tebak-tebakan. Anda akhirnya bertanya-tanya di chat: "Ada yang menyentuh flag pembayaran kemarin?"

Apa yang Disediakan Platform Terpusat

Di sinilah platform feature flag khusus berperan. Tools seperti LaunchDarkly, Split, atau opsi open-source seperti Unleash dan Flagsmith memberi Anda satu tempat untuk mengelola semua flag.

Setiap flag memiliki nama, deskripsi, pemilik, dan riwayat perubahan. Anda bisa melihat kapan flag dibuat, kapan diaktifkan, dan kapan terakhir dimodifikasi. Ini saja sudah memudahkan pembersihan. Anda bisa mencari flag yang tidak tersentuh berbulan-bulan dan menghapusnya dengan percaya diri.

Role-based access control (RBAC) menyelesaikan masalah izin. Developer bisa membuat flag dan mengujinya di staging, tapi hanya tech lead yang bisa mengaktifkannya di production. Product manager bisa menyesuaikan persentase rollout tanpa perlu developer melakukan deploy kode. Ini mengurangi risiko perubahan yang tidak disengaja di production.

Audit log mencatat setiap perubahan: siapa yang membuatnya, kapan, dari nilai apa ke nilai apa. Ketika error melonjak setelah sebuah flag diaktifkan, Anda bisa langsung melihat siapa yang mengubahnya dan menghubungi mereka. Ini juga membantu persyaratan kepatuhan ketika Anda perlu membuktikan bahwa perubahan fitur telah melalui persetujuan yang tepat.

Aturan Targeting yang Lebih Kaya

Seiring tim Anda lebih sering menggunakan progressive rollout, Anda akan menginginkan targeting yang lebih canggih. Rollout berbasis persentase sederhana cukup untuk skenario dasar, tapi bagaimana dengan merilis fitur hanya untuk pengguna di wilayah tertentu? Atau hanya untuk pelanggan premium? Atau hanya untuk pengguna dengan tipe perangkat tertentu?

Platform feature flag memungkinkan Anda mendefinisikan aturan targeting berdasarkan ID pengguna, wilayah, paket langganan, versi aplikasi, tipe perangkat, atau atribut kustom. Semua ini dikonfigurasi dari dashboard tanpa menyentuh kode. Anda bisa menjalankan eksperimen kompleks tanpa melakukan branching pada codebase atau memelihara jalur deployment terpisah.

Kapan Harus Beralih?

Tidak ada aturan baku, tapi berikut adalah tanda-tanda bahwa tim Anda siap untuk platform terpusat:

  • Anda pernah mengalami insiden di mana seseorang mengubah flag tanpa memberi tahu tim.
  • Flag menumpuk di codebase tanpa pemilik yang jelas.
  • Anda tidak bisa dengan mudah menjawab pertanyaan "Flag mana yang saat ini aktif di production?"
  • Tim yang berbeda saling menginjak flag satu sama lain.
  • Anda perlu membuktikan kepada auditor atau compliance bahwa perubahan fitur telah melalui review yang tepat.

Jika tim Anda masih cukup kecil sehingga semua orang mengingat semua flag dan hanya sedikit orang yang pernah mengubahnya, Anda mungkin belum membutuhkan platform. Tapi begitu kondisi itu tidak lagi terpenuhi, ada baiknya Anda mengevaluasi opsi yang ada.

Daftar Periksa Praktis Singkat

Sebelum mengadopsi platform feature flag, lakukan ini:

  • Inventarisasi flag Anda saat ini. Berapa banyak jumlahnya? Berapa banyak yang masih aktif? Siapa pemilik masing-masing?
  • Identifikasi kebutuhan kontrol akses Anda. Siapa yang harus bisa membuat flag? Siapa yang bisa mengaktifkannya di production? Siapa yang bisa menyesuaikan persentase rollout?
  • Tentukan kebutuhan audit Anda. Apakah Anda perlu melacak setiap perubahan? Apakah Anda perlu membuktikan alur kerja persetujuan untuk kepatuhan?
  • Evaluasi kebutuhan targeting Anda. Apakah Anda memerlukan rollout persentase sederhana, atau aturan berdasarkan atribut pengguna, wilayah, atau tipe perangkat?
  • Pertimbangkan ukuran dan pertumbuhan tim Anda. Apakah Anda menambahkan lebih banyak tim? Lebih banyak environment? Rilis yang lebih sering?

Apa Selanjutnya

Platform feature flag terpusat menyelesaikan masalah operasional dalam mengelola flag dalam skala besar. Tapi ini juga memunculkan pertanyaan yang lebih besar: tidak setiap fitur harus dikendalikan oleh flag, dan tidak setiap rilis membutuhkan progressive rollout. Platform memberi Anda alat, tapi Anda tetap harus memutuskan kapan dan bagaimana menggunakannya.

Nilai sebenarnya dari platform feature flag bukanlah dashboard atau audit log. Melainkan kemampuan untuk memisahkan deployment dari rilis, untuk menguji di production dengan aman, dan untuk memberi tim produk kepercayaan diri untuk mengirimkan fitur secara sering tanpa rasa takut. Itulah kapabilitas yang sebenarnya Anda bangun.