Artikel BRO4D
Node 01 / Platform Overview
BRO4D $ Feature Flags Bikin Fitur Gaming Bisa Dibuka Ditutup Tanpa Harus Bongkar Seluruh Aplikasi
Biasanya kita membayangkan fitur baru dengan alur yang lurus. Developer selesai bikin kode lalu aplikasi diperbarui dan fitur langsung muncul. Kenyataannya nggak harus selalu begitu. Sebuah fitur bisa sudah berada di dalam aplikasi tetapi sengaja dibuat tidur sampai waktunya tepat untuk digunakan. BRO4D kali ini membahas feature flags yaitu mekanisme yang memungkinkan jalur tertentu dalam aplikasi diaktifkan atau dinonaktifkan melalui konfigurasi tanpa harus membongkar keseluruhan aplikasi setiap kali status fitur berubah.
Kelihatannya cuma seperti sakelar on dan off. Di sistem yang lebih besar ceritanya bisa jauh lebih menarik. Flag dapat menentukan siapa yang melihat fitur baru kapan fitur mulai tersedia berapa persen pengguna yang mendapatkannya bahkan apa yang harus dilakukan ketika perubahan terbaru ternyata menimbulkan masalah. Kontrol sebesar itu berguna tetapi juga membawa tanggung jawab baru karena setiap sakelar tambahan berarti ada lebih banyak kondisi yang harus dipahami.
BRO4D Punya Fitur Baru tetapi Tombolnya Masih Off
Anggap developer baru selesai membuat satu komponen. Kodenya sudah digabungkan dengan aplikasi utama dan ikut masuk ke environment produksi. Tetapi pengguna masih melihat pengalaman lama karena flag untuk fitur tersebut berada pada kondisi off.
Ketika tim sudah siap konfigurasi flag dapat diubah menjadi on. Aplikasi membaca kondisi tersebut lalu mulai menggunakan jalur baru.
Pemisahan sederhana ini membuat keberadaan kode dan ketersediaan fitur menjadi dua hal yang berbeda.
Deploy Kode Belum Tentu Berarti Merilis Fitur
Ini salah satu alasan feature flags menarik. Deployment berbicara tentang membawa kode ke environment tempat aplikasi berjalan sedangkan release berbicara tentang kapan kemampuan tersebut benar-benar tersedia bagi pengguna.
Tanpa flag kedua kejadian tersebut sering berjalan berdekatan. Begitu kode masuk production perubahan langsung terlihat.
Dengan flag tim mempunyai lapisan kontrol tambahan. Kode dapat tersedia lebih dulu sementara keputusan aktivasi dilakukan pada waktu berbeda.
Sakelar Paling Sederhana Cuma Punya On dan Off
Bentuk paling gampang dari feature flag adalah boolean. Nilainya hanya aktif atau tidak aktif.
Aplikasi memeriksa nilai tersebut sebelum menjalankan jalur tertentu. Kalau aktif pengalaman baru digunakan. Kalau tidak aplikasi kembali menggunakan jalur yang sudah ada.
Untuk kebutuhan sederhana pola seperti ini sudah cukup dan relatif gampang dipahami.
Flag Nggak Harus Berlaku Sama untuk Semua Orang
Feature management bisa bergerak lebih jauh daripada satu sakelar global. Sistem dapat mempunyai aturan yang menentukan siapa yang mendapatkan variasi tertentu.
Misalnya fitur baru hanya dibuka untuk kelompok internal lebih dulu. Setelah pengujian awal selesai kelompok berikutnya dapat ditambahkan tanpa harus membuat build aplikasi baru hanya untuk mengubah target.
Buat teknologi BRO4D bagian ini membuat feature flag berubah dari sakelar sederhana menjadi alat pengendali exposure.
Tim Internal Bisa Jadi Pintu Pertama
Sebelum fitur baru terlihat luas tim dapat mengaktifkannya untuk akun pengujian atau pengguna internal.
Cara ini memberikan kesempatan melihat perilaku fitur pada environment yang sebenarnya tanpa otomatis menampilkannya kepada seluruh pengguna.
Kalau ditemukan masalah flag dapat tetap ditutup untuk kelompok lain sambil perbaikan dilakukan.
Percentage Rollout Membuka Pintu Sedikit demi Sedikit
Setelah tahap awal selesai fitur dapat diperkenalkan kepada sebagian pengguna. Misalnya hanya persentase tertentu yang masuk ke jalur baru sementara sisanya masih memakai pengalaman sebelumnya.
Persentasenya kemudian dapat diperbesar secara bertahap sesuai kebijakan tim dan hasil pengamatan.
Feature flag membuat perubahan exposure seperti ini bisa dilakukan pada lapisan konfigurasi tanpa terus membuat versi kode berbeda untuk setiap tahap.
Targeting Perlu Stabil Supaya Pengalaman Nggak Lompat Lompat
Kalau pengguna masuk kelompok fitur baru hari ini lalu tiba-tiba kembali ke pengalaman lama beberapa menit kemudian hasilnya bisa membingungkan.
Karena itu percentage rollout sering membutuhkan mekanisme pembagian yang konsisten. Identitas atau atribut tertentu dapat diproses untuk menentukan kelompok pengguna secara stabil.
Tujuannya supaya seseorang yang sudah masuk satu variasi nggak terus berpindah hanya karena melakukan request baru.
Targeting Berdasarkan Atribut Harus Digunakan dengan Hati Hati
Aturan flag dapat mempertimbangkan atribut tertentu sesuai kebutuhan aplikasi. Tetapi semakin banyak kondisi semakin rumit pula alasan kenapa seseorang mendapatkan sebuah fitur.
Tim perlu mengetahui data apa yang memang dibutuhkan dan menghindari pengumpulan atribut berlebihan hanya demi targeting.
Aturan yang sederhana biasanya lebih mudah diperiksa dibanding puluhan kondisi yang saling tumpang tindih.
Kill Switch Jadi Tombol Darurat
Nggak semua flag dibuat untuk peluncuran fitur. Ada juga flag operasional yang berfungsi seperti kill switch.
Bayangkan sebuah fungsi mulai menghasilkan beban berlebihan atau dependency yang digunakannya sedang bermasalah. Kalau jalur tersebut berada di belakang flag tim dapat mempunyai cara cepat untuk menonaktifkannya.
Ini nggak memperbaiki sumber masalah tetapi bisa membantu mengurangi dampak sambil investigasi dilakukan.
Mematikan Fitur Beda dengan Mengembalikan Seluruh Deployment
Rollback biasanya mengembalikan versi aplikasi atau deployment ke kondisi sebelumnya. Kill switch melalui feature flag bekerja lebih sempit.
Kode terbaru bisa tetap berada di production tetapi satu kemampuan tertentu dinonaktifkan.
Kalau masalah memang terisolasi pada fitur tersebut pendekatan ini bisa lebih cepat daripada mengganti seluruh versi aplikasi. Tetapi kalau bug berada pada bagian yang nggak dilindungi flag rollback tetap mungkin diperlukan.
Flag Juga Bisa Mengendalikan Perubahan Operasional
Feature flags nggak selalu berhubungan dengan sesuatu yang terlihat langsung di layar.
Sebuah flag bisa menentukan apakah aplikasi memakai implementasi lama atau baru apakah request melewati jalur tertentu atau apakah sebuah proses latar belakang diaktifkan.
Karena itu istilah feature flag dalam praktik sering mencakup berbagai jenis toggle dengan umur dan tujuan berbeda.
Konfigurasi Flag Harus Sampai ke Aplikasi
Kalau status flag dikelola di luar kode aplikasi tetap membutuhkan cara untuk mengetahui nilainya.
Sistem dapat mengambil konfigurasi dari layanan tertentu menggunakan SDK atau mekanisme lain sesuai arsitektur. Nilai kemudian dievaluasi ketika aplikasi menentukan jalur yang akan digunakan.
Desainnya perlu mempertimbangkan seberapa cepat perubahan flag harus terlihat dan apa yang terjadi kalau sumber konfigurasi sedang nggak tersedia.
Cache Membuat Evaluasi Flag Nggak Harus Selalu Memanggil Server
Kalau setiap pemeriksaan flag harus melakukan request jaringan baru performa aplikasi bisa ikut bergantung pada layanan konfigurasi.
Karena itu nilai atau aturan tertentu dapat disimpan sementara di sisi aplikasi sesuai desain sistem.
Cache mengurangi dependency langsung tetapi memperkenalkan pertanyaan baru mengenai freshness. Perubahan konfigurasi mungkin membutuhkan sedikit waktu sebelum seluruh instance menggunakan nilai terbaru.
Default Value Penting Saat Layanan Flag Nggak Bisa Dijangkau
Sistem perlu menentukan perilaku ketika status flag gagal diperoleh. Aplikasi nggak seharusnya selalu berhenti hanya karena layanan feature management sedang mengalami gangguan.
Default value atau nilai terakhir yang masih dianggap valid dapat menjadi bagian dari strategi fallback tergantung tingkat risiko fiturnya.
Keputusan fail-open atau fail-closed harus disesuaikan dengan fungsi flag bukan diterapkan sama untuk semua kasus.
Nama Flag Harus Menjelaskan Apa yang Dikendalikan
Ketika baru mempunyai lima flag nama yang berantakan mungkin belum terasa. Setelah jumlahnya puluhan kebingungan mulai muncul.
Nama seperti new_feature atau test_flag cepat kehilangan konteks. Beberapa bulan kemudian orang nggak lagi ingat fitur baru yang dimaksud itu yang mana.
Konvensi penamaan yang konsisten membantu tim memahami fungsi sebuah flag tanpa harus membuka banyak file terlebih dahulu.
Setiap Flag Sebaiknya Punya Pemilik
Flag sementara sering dibuat saat pengembangan tetapi kemudian dilupakan setelah fitur aktif sepenuhnya.
Memberikan owner membuat tanggung jawabnya lebih jelas. Ada orang atau tim yang tahu kenapa flag dibuat kapan harus dievaluasi dan kapan waktunya dibuang.
Tanpa ownership repository bisa berubah menjadi museum sakelar lama yang nggak berani disentuh siapa pun.
Flag Sementara Harus Punya Umur
Release flag biasanya dibuat untuk membantu perjalanan sebuah fitur dari tertutup menuju tersedia secara luas. Setelah rollout selesai flag tersebut kehilangan sebagian besar kegunaannya.
Kalau dibiarkan selamanya conditional branch tetap berada di dalam kode meskipun salah satu jalurnya nggak pernah digunakan lagi.
Karena itu cleanup seharusnya menjadi bagian dari lifecycle flag bukan pekerjaan yang selalu ditunda.
Terlalu Banyak Flag Bisa Membuat Kombinasi Meledak
Satu flag boolean mempunyai dua keadaan. Dua flag bisa menghasilkan empat kombinasi. Ketika jumlahnya terus bertambah kemungkinan kondisi aplikasi ikut membesar.
Nggak semua kombinasi memang akan digunakan tetapi kompleksitas mentalnya tetap meningkat.
Developer perlu memahami flag mana yang berinteraksi dan kondisi mana yang benar-benar didukung.
Testing Harus Tahu Ada Lebih dari Satu Jalur
Feature flag menciptakan cabang perilaku sehingga testing perlu mempertimbangkan jalur yang penting.
Kalau test suite hanya selalu menjalankan kondisi flag on jalur lama bisa rusak tanpa diketahui. Begitu juga sebaliknya.
Tim nggak harus menguji seluruh kombinasi secara membabi buta tetapi perlu menentukan state mana yang kritis dan memang harus dilindungi.
Flag Bisa Dipakai untuk Eksperimen tetapi Tujuannya Harus Jelas
Mekanisme targeting memungkinkan dua kelompok mendapatkan variasi berbeda sehingga feature flag juga dapat menjadi bagian dari eksperimen.
Namun eksperimen membutuhkan desain metrik dan analisis tersendiri. Sekadar membagi pengguna menjadi dua kelompok belum otomatis menghasilkan kesimpulan yang berguna.
Release control dan experimentation bisa memakai alat serupa tetapi pertanyaan yang ingin dijawab berbeda.
Perubahan Flag Tetap Perlu Audit Trail
Karena mengubah satu flag bisa langsung mengubah perilaku aplikasi perubahan konfigurasi sebaiknya nggak menjadi tindakan tanpa jejak.
Riwayat siapa yang mengubah flag kapan perubahan terjadi serta nilai sebelumnya dapat membantu ketika tim melakukan investigasi.
Kalau masalah muncul beberapa menit setelah sebuah toggle berubah audit trail memberi titik awal yang jelas untuk diperiksa.
Akses ke Kill Switch Jangan Diberikan Sembarangan
Kemampuan mengubah perilaku production tanpa deployment sangat berguna sekaligus berisiko. Orang yang salah menekan toggle bisa memengaruhi banyak pengguna dalam waktu singkat.
Role dan permission perlu menentukan siapa yang boleh melihat mengedit atau menyetujui perubahan pada flag tertentu.
Flag dengan dampak besar dapat membutuhkan kontrol lebih ketat dibanding toggle untuk kebutuhan internal.
Monitoring Memberi Jawaban Setelah Flag Dinyalakan
Mengubah flag ke posisi on bukan akhir pekerjaan. Tim perlu melihat apa yang terjadi setelah exposure berubah.
Error rate latency penggunaan resource atau metrik aplikasi yang relevan dapat dibandingkan untuk mencari perubahan yang nggak diharapkan.
Kalau sinyal memburuk rollout bisa dihentikan atau flag dimatikan sesuai strategi yang sudah disiapkan.
BRO4D Nggak Mau Sakelar Lama Tinggal Selamanya
Begitu fitur sudah stabil dan seluruh pengguna berada pada jalur baru tim dapat menghapus flag sementara beserta kode lama yang nggak lagi dibutuhkan.
Tahap ini penting karena feature flags seharusnya membantu mengendalikan perubahan bukan menambah conditional tanpa akhir.
Dokumentasi dan konfigurasi yang berkaitan dengan flag tersebut juga dapat dibersihkan supaya daftar toggle tetap relevan.
Satu Sakelar Kecil Bisa Mengubah Cara BRO4D Melepas Fitur
Tema BRO4D kali ini menunjukkan bahwa feature flags sebenarnya bukan soal tombol on dan off saja. Di balik sakelar tersebut ada targeting rollout fallback permission audit testing monitoring sampai lifecycle yang harus dipikirkan.
Ketika digunakan dengan disiplin fitur dapat dideploy tanpa harus langsung terlihat luas. Tim bisa membukanya untuk kelompok kecil menaikkan exposure bertahap atau menggunakan kill switch kalau kondisi berubah. Tetapi ketika flag dibiarkan menumpuk keuntungan tadi bisa berbalik menjadi kompleksitas baru.
Jadi kekuatan feature flags BRO4D bukan berasal dari banyaknya toggle yang dimiliki sebuah aplikasi. Nilainya justru muncul ketika setiap flag punya tujuan pemilik dan akhir yang jelas. Fitur bisa dibuka atau ditutup tanpa membongkar seluruh aplikasi sementara kode tetap dijaga supaya nggak berubah menjadi kumpulan sakelar yang nggak pernah selesai dibereskan.
