Apa Itu Feature Flag? Panduan Singkat untuk Solo Dev

Apa itu feature flag? Sebuah if yang jawabannya disimpan di luar kode kamu. Kamu mengirim jalur kode baru dalam keadaan mati, lalu menyalakannya nanti dengan mengubah nilai di file konfigurasi, baris database, atau layanan flag, tanpa deploy ulang. Trik ini yang memisahkan deploy kode dari rilis fitur, dan itu sebabnya flag adalah cara rollback paling murah yang bakal kamu punya.

Bagian kedua dari kalimat itu saya pelajari dengan cara yang sulit. Flag pertama saya adalah boolean di environment variable, dinyalakan pada Jumat malam, dan saya lupa keberadaannya selama sebelas bulan. Tidak ada yang rusak. Justru di situlah masalahnya, dan kita akan membahasnya nanti.

Seperti apa feature flag di dalam kode?

Jauh lebih kecil dari yang ditampilkan halaman depan vendor. Tanpa dashboard, flag hanyalah sebuah lookup dan percabangan:

const flags = { newCheckout: false };

if (flags.newCheckout) {
  return renderNewCheckout(user);
}
return renderOldCheckout(user);

Sisanya adalah pertanyaan tentang dari mana flags berasal dan siapa yang bisa mengubahnya. Konstanta di dalam file adalah flag yang harus kamu ubah lewat deploy, dan itu menggagalkan tujuannya. Environment variable berubah setelah restart. Baris di database berubah dalam hitungan detik. Layanan hosted juga berubah dalam hitungan detik, dan memberimu targeting per pengguna, UI, serta audit log.

Yang sering jadi masalah di praktik: kodenya sepele, siklus hidupnya yang rumit. Dua cabang di produksi berarti dua perilaku yang harus diuji, dua jalur yang harus di-debug jam 2 pagi, dan salah satunya pasti akan membusuk.

Ada empat jenis feature flag, dan mana yang kamu butuhkan dulu?

Taksonomi feature toggles dari Martin Fowler masih jadi cara paling rapi untuk memilahnya, dan sumbu yang berguna adalah berapa lama tiap jenis seharusnya hidup.

Release flag menyembunyikan pekerjaan yang belum selesai atau berisiko. Sifatnya sementara: seminggu atau dua minggu, lalu hapus. Ini yang paling dulu kamu butuhkan.

Ops flag adalah kill switch. Kamu membungkus fitur yang berat atau rapuh (widget rekomendasi, panggilan ke pihak ketiga) supaya bisa dimatikan saat beban tinggi tanpa deploy. Kebanyakan berumur pendek, beberapa tetap ada selamanya dan itu tidak masalah.

Experiment flag membagi pengguna ke dalam kohort untuk A/B test. Mereka hidup selama dibutuhkan untuk mencapai hasil yang bermakna secara statistik, jadi dari beberapa jam sampai beberapa minggu, dan butuh trafik nyata agar berarti.

Permission flag membatasi fitur berdasarkan paket atau akun: tier Pro, grup beta. Flag jenis ini bisa hidup bertahun-tahun, dan saat itu terjadi mereka sebenarnya bukan flag lagi. Mereka adalah entitlement, dan pantas punya model data yang layak.

Kalau kamu solo dev dengan 40 pengguna, kamu butuh release flag dan mungkin satu kill switch. Experiment flag di 40 pengguna hanya menghasilkan noise, bukan data. Tunda sampai kamu bisa menyebutkan metriknya dan ukuran sampelnya.

Masalah apa yang diselesaikan flag, yang tidak bisa diselesaikan branch dan deploy?

Ada tiga hal, dan hanya tiga itu yang layak diperhatikan.

Mengirim pekerjaan yang belum selesai dengan aman. Long-lived branch menyakitkan karena menggabungkannya itu seperti perang kecil. Flag memungkinkanmu merge ke main setiap hari dengan kode baru dalam keadaan gelap. Ini mesin di balik trunk-based development, di mana semua orang commit ke satu branch dan flag membawa bagian yang belum selesai.

Rilis bertahap. Nyalakan untuk dirimu sendiri, lalu untuk 1% pengguna, lalu 10%, lalu semua. Fowler menjelaskan memilih kohort canary sekitar 1% dengan mengambil user ID modulo 100. Kalau ada yang salah, dampaknya hanya segelintir orang, bukan seluruh basis pengguna.

Undo yang cepat. Rollback deploy artinya build, pipeline, dan sedikit nyali. Membalik flag cukup satu edit. Di hari yang buruk, bedanya antara menit yang menyakitkan dan satu jam penuh.

Tak satu pun dari ini butuh vendor di hari pertama. Semuanya butuh disiplin.

Perlukah LaunchDarkly, atau file JSON sudah cukup?

File JSON atau tabel database sudah cukup sampai salah satu ini terjadi: ada non-developer yang perlu membalik flag, kamu butuh rollout persentase atau targeting per pengguna, kamu butuh jejak audit siapa mengubah apa, atau kamu menjalankan lebih dari satu service yang membaca flag yang sama.

Ini kira-kira tangga yang akan saya naiki, berurutan:

1. Konstanta dan environment variable. Tanpa biaya. Cukup untuk release flag pertama di side project.

2. Tabel flags atau file JSON yang dibaca saat runtime. Sepuluh baris kode, toggle instan, tanpa vendor. Ini bisa membawa solo project cukup jauh.

3. Layanan flag open-source atau hosted. Saat kamu butuh aturan targeting, rollout bertahap, dan UI yang bisa dipakai orang lain.

4. Platform enterprise. Saat compliance, approval, dan puluhan engineer mulai ikut terlibat.

Tools hosted mencakup langkah 3 dan 4. LaunchDarkly adalah pemain lama, dengan fitur targeting dan governance paling dalam, dan harga yang mencerminkannya.

Statsig menggabungkan flag dengan eksperimen dan product analytics, yang masuk akal kalau kamu berniat mengukur apa yang dilakukan flag, bukan sekadar membaliknya.

Lewati keduanya kalau seluruh timmu adalah kamu sendiri. Tabel dengan tiga kolom lebih baik daripada dashboard yang kamu buka dua kali per kuartal. Pilih layanan hanya saat versi manual sudah membuatmu rugi secara spesifik, misalnya edit konfigurasi produksi di tengah malam yang kamu sesali.

Satu asuransi yang layak kamu tahu: OpenFeature adalah proyek CNCF berstatus incubating yang mendefinisikan API netral vendor untuk mengevaluasi flag, dengan SDK untuk Node.js, Python, Go, Java, .NET, dan web client, antara lain. Kamu menulis kode terhadap antarmuka standar dan mengganti provider di bawahnya. Kalau kamu curiga akan melampaui setup pertamamu, membungkusnya lewat OpenFeature membuat perpindahan itu cukup berupa perubahan konfigurasi.

Bagaimana cara menambahkan flag pertama tanpa bikin kekacauan?

Mulailah dengan satu release flag dan beberapa aturan dasar. Ini versi yang saya harap dulu saya ikuti.

Beri nama sesuai fiturnya, bukan mekanismenya. new-checkout-flow memberitahumu apa yang rusak kalau salah. flag_47 tidak memberitahu apa-apa enam bulan kemudian.

Default-nya mati, dan mati berarti perilaku lama. Konvensi "off berarti legacy, on berarti baru" yang membuatmu bisa bernalar tentang sistem saat sedang tertekan. Kalau dilanggar, setiap flag jadi teka-teki.

Evaluasi di satu tempat. Fowler menyebut perbaikannya toggle inversion: alih-alih menaburkan if (flags.x) di dua puluh file, putuskan sekali, dekat tepi sistem, lalu teruskan hasilnya. Satu titik keputusan berarti satu tempat untuk diubah dan satu tempat untuk diuji.

Tulis tiket penghapusan saat kamu membuat flag. Masukkan ke backlog dengan tanggal. Fowler juga menyarankan tanggal kedaluwarsa untuk toggle berumur pendek, bahkan tes yang gagal begitu flag melewati tanggalnya. Flag tanpa tiket penghapusan itu seperti pinjaman tanpa jadwal pelunasan.

Catat setiap evaluasi yang penting. Saat pengguna melaporkan bug, kamu ingin tahu sisi flag mana yang mereka dapat. Kalau kamu tidak bisa menjawabnya, flag itu adalah beban.

Di sinilah orang sering berlebihan saat menguji. Kamu tidak perlu menguji setiap kombinasi flag, karena kebanyakan flag tidak saling berinteraksi. Uji konfigurasi yang kamu harapkan di produksi, uji fallback dengan flag baru dimatikan, dan opsional jalankan satu pass dengan semua flag menyala untuk menangkap drift.

Berapa biaya feature flag yang jarang dibicarakan orang?

Setiap flag menggandakan jalur kode. Sepuluh flag independen secara teori menghasilkan 1.024 kombinasi, dan meski kamu tidak akan pernah mengujinya semua, kamu tetap bisa menabrak satu kombinasi di produksi yang tidak pernah kamu antisipasi.

Biaya yang lebih menyakitkan adalah flag mati. Rilis selesai, semua orang sudah di perilaku baru, flag tetap di 100%, dan cabang lama mengendap di repo sebagai kode yang tidak ada yang berani hapus. Enam bulan kemudian tidak ada yang ingat apakah mematikannya aman.

Versi paling terkenal dari ini adalah Knight Capital, Agustus 2012. Sebuah flag lama yang pernah mengaktifkan fungsi trading yang sudah pensiun dipakai ulang untuk kode baru. Satu dari delapan server melewatkan deployment dan masih menjalankan kode lama. Dalam 45 menit, perusahaan kehilangan sekitar $440 juta menurut laporan kuartalan mereka sendiri, angka yang di laporan berikutnya mendekati $460 juta. Ini perusahaan trading dengan uang sungguhan dan engineer sungguhan, jadi saya tidak akan mengklaim side project kamu lebih aman. Pelajarannya tetap berlaku dalam skala kecil: jangan pernah memakai ulang nama flag, dan hapus flag mati sebelum jadi barang arkeologi.

Kerangka Fowler yang selalu saya pegang: perlakukan flag sebagai inventaris dengan biaya simpan. Beberapa tim membatasi jumlah flag yang hidup dan mewajibkan menghapus satu sebelum menambah yang lain. Untuk solo dev, batas keras lima sudah lebih dari cukup.

Kapan sebaiknya melewatkan feature flag sepenuhnya?

Lebih sering dari yang diakui para vendor tooling.

Lewati saat fiturnya kecil, perubahannya mudah di-revert di git, dan deploy kamu memakan dua menit. Flag menambah cabang, sumber konfigurasi, dan satu hal lagi untuk dilupakan. Kalau revert lebih cepat daripada membalik flag, flag itu cuma teater.

Lewati saat kamu belum punya pengguna. Rollout bertahap ke nol orang hanyalah penundaan. Kirim, lihat log, perbaiki.

Lewati untuk migrasi database yang tidak bisa dibatalkan oleh sebuah toggle. Flag bisa menyembunyikan kolom baru di UI, tapi tidak bisa mengembalikan tabel yang sudah di-drop. Perubahan skema butuh rencana expand-and-contract sendiri, dengan atau tanpa flag.

Layak dipakai saat perubahannya menyentuh pembayaran atau autentikasi, saat kamu ingin merge harian dengan pekerjaan yang belum selesai, atau saat dependensi pihak ketiga mungkin gagal dan kamu ingin kill switch.

Apa yang perlu kamu pantau setelah flag aktif?

Flag mengontrol paparan, dan paparan hanya membantu kalau kamu bisa melihat apa yang terjadi berikutnya. Menyalakan fitur untuk 10% pengguna tanpa memantau error rate dan latency sama saja dengan melempar koin dengan langkah tambahan.

Sebelum rollout pertama, pastikan kamu bisa menjawab tiga pertanyaan dalam kurang dari satu menit: apakah error naik di kohort yang terkena flag, apakah latency memburuk, dan apakah ada sesuatu di sisi downstream yang berubah? Uptime monitoring dan pencarian log menutup sebagian besar kebutuhan ini untuk produk kecil, dan tool seperti Better Stack menyatukan monitor, status page, dan log di satu tempat dengan paket gratis.

Aturan yang saya ikuti sekarang: flag hanya sebagus alarm yang terpasang padanya. Tanpa alarm, kamu sedang menyalakan sesuatu dalam gelap.

Apa yang bisa kamu lakukan minggu ini?

Pilih satu pekerjaan yang belum selesai dan kamu takut untuk di-merge. Pasang di balik boolean yang dibaca dari tabel atau file JSON, default mati, lalu merge ke main hari ini. Tulis tiket penghapusan sebelum kamu menutup editor, dengan tanggal dua minggu dari sekarang.

Lalu nyalakan hanya untuk dirimu sendiri, dan pakai selama sehari. Kalau hasilnya bagus, perluas. Kalau tidak, matikan lagi dan kamu tidak kehilangan apa-apa selain satu menit.

Flag mana di codebase kamu sekarang yang sudah 100% lebih dari sebulan? Itulah penghapusan pertama kamu.