Tim pengembangan sudah selesai membuat fitur baru, tetapi operasi belum siap menerapkannya di seluruh cabang. Proses lama masih dipakai, pengguna membutuhkan pendampingan, dan manajemen ingin mengetahui dampaknya sebelum memberi persetujuan penuh. Jika satu-satunya pilihan adalah mengaktifkan fitur untuk semua orang sekaligus, risiko rilis ikut membesar.
Feature flag aplikasi enterprise membantu mengatur siapa yang menerima perilaku baru dan kapan perilaku tersebut diaktifkan. Namun, sakelar fitur perlu memiliki owner, aturan evaluasi, bukti pengujian, serta batas penggunaan. Tanpa kendali tersebut, perusahaan hanya menambah jalur perilaku yang sulit ditelusuri.
Panduan ini ditujukan kepada CTO, Head of IT, pemilik produk, QA, dan manajer operasional yang mengelola ERP atau aplikasi custom lintas unit. Fokusnya adalah tata kelola aktivasi fitur setelah kode tersedia, bukan penanganan kegagalan dependensi seperti circuit breaker.
Apa Itu Feature Flag Aplikasi Enterprise?
Microsoft Learn menjelaskan feature management sebagai pemisahan aktivasi fitur dari deployment kode. Feature flag dapat digunakan untuk mengaktifkan atau menonaktifkan fungsi, membatasi audiens, dan memperkenalkan fitur secara bertahap. Dalam praktiknya, aplikasi tetap perlu dirancang untuk mengevaluasi flag pada jalur yang tepat.
Contoh sederhana: kode formulir permintaan pembelian baru sudah dipasang, tetapi hanya satu cabang pilot yang menggunakannya. Cabang lain masih mendapat formulir lama. Ketika bukti penerimaan cukup, audiens dapat diperluas mengikuti rencana yang disetujui. Ilustrasi ini bukan laporan proyek atau klaim hasil implementasi Layana.ID.
Feature flag berbeda dari hak akses. Hak akses menentukan siapa yang berwenang melakukan tindakan. Flag menentukan apakah suatu perilaku tersedia dalam konteks tertentu. Pengguna yang mendapatkan fitur baru tetap harus memenuhi aturan otorisasi aplikasi.
Pilih Jenis Flag Berdasarkan Keputusan yang Ingin Dikendalikan
Flag Rilis untuk Memperkenalkan Perilaku Baru
Gunakan ketika tim membutuhkan transisi dari perilaku lama menuju perilaku baru. Tetapkan kriteria penerimaan dan rencana penghentian jalur lama sejak awal. Flag rilis tidak seharusnya dibiarkan menjadi konfigurasi permanen hanya karena semua orang sudah terbiasa melihatnya.
Flag Operasional untuk Membatasi Dampak Gangguan
Flag operasional dapat menjadi kill switch untuk menghentikan fitur tertentu ketika kondisi tidak memenuhi batas yang disepakati. Tentukan fungsi mana yang dihentikan dan bagaimana pengguna mendapat penjelasan. Mematikan fitur pembuatan transaksi tidak otomatis membatalkan transaksi yang sudah berjalan.
Flag Eksperimen untuk Membandingkan Pilihan
Eksperimen membutuhkan pertanyaan dan metrik yang jelas. Jangan menyebut rollout biasa sebagai eksperimen jika tidak ada kelompok pembanding atau metode penilaian yang sesuai. Pada proses keuangan dan persetujuan, variasi perilaku juga harus dinilai terhadap konsistensi kebijakan bisnis, bukan hanya jumlah klik.
Dalam artikel ini, fokus utamanya adalah flag rilis dan kendali operasional. Pengaturan paket berbayar atau entitlement permanen memerlukan tata kelola tersendiri, termasuk hubungan dengan kontrak dan hak akses pelanggan.
Targetkan Tenant dan Cabang Secara Konsisten
OpenFeature mendefinisikan evaluation context sebagai informasi yang digunakan untuk menilai flag. Konteks tersebut dapat memuat targeting key dan atribut tambahan. Spesifikasinya menjelaskan bahwa sejumlah provider membutuhkan targeting key untuk penargetan atau pembagian audiens tertentu.
Untuk sistem enterprise, pilih unit penargetan berdasarkan proses bisnis. Jika satu transaksi melibatkan sales, gudang, dan finance dalam tenant yang sama, memberikan pengalaman berbeda per pengguna dapat membuat alur sulit dipahami. Pilot per tenant, cabang, atau kelompok proses mungkin lebih mudah dikelola daripada persentase pengguna acak.
Tentukan identitas konteks dari sumber tepercaya di server. Jangan mempercayai tenant ID atau role yang dikirim browser sebagai dasar keputusan sensitif. Evaluasi flag dan pemeriksaan otorisasi harus tetap menghormati organisasi aktif serta batas akses pengguna.
Pilih atribut seperlunya: organisasi, cabang, kelompok pilot, dan versi aplikasi mungkin cukup. Hindari mengirim data pribadi atau isi transaksi jika keputusan flag tidak membutuhkannya. Dokumentasikan atribut yang digunakan dan pihak yang dapat mengaksesnya.
Contoh Rollout Formulir Pembelian per Cabang
Bayangkan perusahaan memiliki beberapa cabang dengan alur permintaan pembelian yang berbeda. Tim akan merilis formulir baru yang menampilkan alasan kebutuhan, kategori belanja, dan persetujuan tambahan. Sebelum aktivasi, pemilik proses perlu memutuskan bagaimana transaksi lama tetap diselesaikan.
Rencana berikut merupakan rekomendasi perencanaan yang harus disesuaikan dengan sistem perusahaan:
- Pilih cabang pilot: gunakan cabang yang mewakili variasi transaksi penting dan memiliki PIC pendamping.
- Kunci aturan: sepakati transaksi mana yang memakai formulir baru serta penanganan transaksi yang sudah terbuka.
- Uji konteks: pastikan pengguna dari cabang lain tidak menerima flag pilot karena kesalahan evaluasi.
- Amati hasil: periksa transaksi selesai, pengecualian persetujuan, koreksi data, serta keluhan pengguna.
- Putuskan perluasan: owner bisnis dan teknis menilai bukti sebelum menambah cabang.
Jangan menetapkan persentase rollout secara otomatis tanpa menilai audiens. Cabang dengan aktivitas sedikit tidak selalu mewakili cabang dengan volume besar, proses tutup buku, atau integrasi khusus. Variasi risiko lebih penting daripada sekadar banyaknya pengguna pilot.
Nilai Flag Perlu Stabil Sepanjang Transaksi
Satu transaksi dapat berlangsung lebih lama daripada satu request. Permintaan pembelian dibuat hari ini, disetujui besok, dan menjadi purchase order setelah pemeriksaan finance. Bila flag berubah di tengah proses, aplikasi perlu mengetahui perilaku mana yang berlaku pada transaksi tersebut.
Rencanakan apakah evaluasi dilakukan setiap request, pada awal alur, atau menggunakan versi proses yang melekat pada transaksi. Pilihan ini mengikuti kebutuhan bisnis. Untuk alur panjang, menyimpan versi proses dapat membantu memastikan keputusan berikutnya memakai aturan yang sesuai, sambil tetap mengizinkan penghentian operasional yang dirancang secara khusus.
Uji perubahan flag saat transaksi berjalan. Periksa pekerjaan yang sudah berada dalam antrean, notifikasi yang belum dikirim, dan integrasi yang sedang menunggu hasil. Jangan menganggap satu toggle akan mengembalikan seluruh state ke awal.
Rancang Default dan Perilaku Saat Provider Bermasalah
Setiap flag perlu memiliki nilai default yang dipilih berdasarkan dampak. Nilai false tidak selalu aman: pada flag yang mematikan fitur berisiko, false mungkin justru mempertahankan fitur tersebut. Nama, arti nilai, dan konsekuensinya harus dapat dipahami oleh tim yang menangani insiden.
Tentukan perilaku saat konfigurasi tidak tersedia, cache belum diperbarui, atau atribut konteks tidak lengkap. Apakah aplikasi memakai nilai terakhir yang diketahui, kembali ke jalur lama, atau menolak operasi tertentu dengan pesan yang jelas? Putuskan per flag, lalu uji kondisi tersebut sebelum rollout.
Catat durasi propagasi yang benar-benar teramati. Perubahan di panel pengelolaan tidak membuktikan seluruh instance aplikasi sudah menerima nilai baru. Hindari janji bahwa kill switch selalu berlaku seketika; cache, refresh, dan pekerjaan berjalan dapat membuat perilaku berbeda.
Kill Switch Menghentikan Jalur, Bukan Menghapus Dampak
Misalnya fitur baru sudah menulis data dengan format tambahan. Menonaktifkan flag pembacaan tidak menghapus data tersebut. Jika jalur lama tidak dapat memahami format baru, rollback perlu rencana kompatibilitas dan rekonsiliasi.
Untuk perubahan struktur, gunakan bersama panduan perubahan skema database enterprise. Pisahkan keputusan aktivasi perilaku, migrasi data, penghentian jalur lama, dan pemulihan. Tidak semua keputusan tersebut dapat dikendalikan melalui satu flag.
Runbook kill switch perlu menjelaskan kondisi pemicu, pemilik keputusan, langkah verifikasi, komunikasi kepada PIC, dan tindak lanjut transaksi yang sudah terdampak. Setelah switch digunakan, buktikan apakah perilaku pada web, mobile, worker, serta integrasi telah berubah sesuai rencana.
Batasi Siapa yang Boleh Mengubah Flag Produksi
Perubahan flag produksi dapat memiliki dampak setara dengan rilis kode. Bedakan kewenangan membuat flag, mengubah audiens, mengaktifkan fitur, menggunakan kill switch, dan menghapus flag. Hak melihat konfigurasi tidak otomatis berarti hak mengubahnya.
Untuk perubahan yang memengaruhi nilai transaksi atau approval, tentukan persetujuan bisnis dan teknis. Jalur darurat boleh lebih ringkas bila sudah dirancang, tetapi harus tetap menyimpan alasan, pelaku, waktu, kondisi sebelum-sesudah, serta hasil verifikasi.
Hubungkan dengan audit trail aplikasi enterprise. Catatan perubahan harus membantu menjawab siapa yang mengubah perilaku dan transaksi mana yang kemungkinan terdampak. Jangan memasukkan kredensial atau seluruh payload sensitif ke log hanya demi memperlengkap catatan.
QA Flag On, Off, dan Kombinasi yang Relevan
Uji kedua jalur yang masih didukung, bukan hanya kondisi flag aktif. Tambahkan target yang memenuhi aturan, target yang tidak memenuhi aturan, konteks yang hilang, serta kondisi konfigurasi tidak tersedia. Gunakan data sintetis atau data uji yang telah disanitasi.
Jika beberapa flag saling bergantung, dokumentasikan kombinasi yang sah. Jangan menguji semua kombinasi secara membabi buta; prioritaskan pasangan yang berbagi transaksi, data, atau dependensi. Kombinasi yang tidak didukung harus dicegah atau menghasilkan respons terkontrol.
- Apakah tenant di luar pilot tetap mendapatkan perilaku yang disepakati?
- Apakah request langsung ke API tetap memeriksa otorisasi saat UI menyembunyikan fitur?
- Apakah worker memakai konteks dan versi proses yang benar?
- Apakah perubahan flag ketika transaksi berjalan memiliki hasil yang dapat dijelaskan?
- Apakah tim dapat membuktikan kill switch telah diterapkan pada instance yang relevan?
Gunakan satu uji yang menantang asumsi utama, misalnya pengguna berpindah organisasi aktif setelah login. Flag untuk organisasi sebelumnya tidak boleh terbawa ke operasi organisasi berikutnya. Hasilnya perlu diperiksa pada tindakan dan data yang tersimpan, bukan tampilan menu saja.
Ukur Hasil dan Hapus Flag yang Sudah Selesai
Pilih indikator sesuai fitur: transaksi gagal, durasi penyelesaian, pengecualian approval, koreksi data, dan tiket dukungan. Kaitkan pengamatan dengan versi aplikasi, audiens, serta nilai flag melalui observability aplikasi enterprise. Jumlah evaluasi flag hanya menunjukkan pemakaian mekanisme, bukan keberhasilan bisnis.
Setiap flag sementara perlu owner dan jadwal review. Setelah jalur baru diterima, tentukan kapan kode lama, konfigurasi, serta pengujian yang tidak lagi relevan dapat dihapus. Lakukan pembersihan melalui perubahan yang ditinjau, lalu jalankan regresi pada perilaku akhir.
Jangan menghapus flag hanya karena sudah lama dibuat. Sebaliknya, jangan mempertahankannya tanpa alasan karena khawatir suatu hari akan diperlukan. Keputusan harus mengikuti kebutuhan operasional, bukti pemakaian, dan batas rollback yang masih didukung.
FAQ Feature Flag Aplikasi Enterprise
Apakah feature flag menggantikan permission pengguna?
Tidak. Flag mengendalikan ketersediaan perilaku, sedangkan permission menentukan kewenangan. Pemeriksaan otorisasi pada server tetap diperlukan, termasuk ketika fitur tidak terlihat pada UI.
Apakah mematikan flag otomatis membatalkan transaksi?
Tidak. Transaksi yang sudah berjalan atau data yang sudah berubah membutuhkan penanganan sesuai desain proses. Tentukan versi perilaku dan langkah rekonsiliasi sebelum menggunakan kill switch.
Haruskah rollout dimulai dari persentase pengguna?
Tidak selalu. Pilih unit penargetan yang sesuai alur bisnis. Tenant atau cabang dapat menjadi pilihan ketika banyak pengguna bekerja pada transaksi bersama dan perlu mendapat perilaku konsisten.
Mulai dari Satu Fitur yang Risikonya Jelas
Siapkan brief berisi perilaku lama dan baru, target pilot, proses yang terdampak, owner, kebutuhan audit, indikator penerimaan, serta kondisi penghentian. Gunakan brief tersebut untuk menilai apakah flag membantu mengurangi risiko atau justru menambah variasi yang belum terkelola.
Diskusikan rollout fitur enterprise bersama Layana.ID. Bawa daftar aplikasi dan cabang yang terlibat, contoh alur transaksi, serta batas operasional agar rencana aktivasi dimulai dari kebutuhan bisnis yang konkret.
Referensi Teknis
Microsoft Learn — Feature management overview, Azure App Configuration; OpenFeature Specification — Evaluation Context. Nama sumber dicantumkan tanpa tautan keluar. Checklist, ilustrasi pembelian, dan rekomendasi tata kelola merupakan analisis perencanaan yang perlu disesuaikan dengan sistem perusahaan.