Deployment adalah saat kode tiba dalam produksi. Rilis adalah saat seseorang benar-benar dapat menggunakannya. Membingungkan keduanya adalah salah satu cara tercepat untuk membuat setiap penerapan menjadi momen yang menegangkan.
Tanda feature flag berfungsi untuk memberi jarak di antara dua momen ini. Anda dapat menerapkan hari ini, menjalankannya besok untuk tim internal, lalu untuk pelanggan percontohan, lalu untuk 10% pengguna. Jika terjadi kesalahan, matikan benderanya. Anda tidak perlu melakukan rollback seluruh rilis.
Bendera bukan sekedar if
Secara teknis seringkali berupa if. Secara budaya, hal ini lebih dari itu.
if (await flags.isEnabled('checkout.v2.enabled', context)) { return newCheckout(input); } return oldCheckout(input);
if kecil tersebut dapat mewakili peluncuran bertahap, percobaan, migrasi, izin usaha, atau kill switch operasional. Masalahnya, jika tidak dikelola dengan baik, bisa juga menjadi utang teknis yang bertahan dalam kode selama dua tahun.
Di mana OpenFeature masuk
OpenFeature adalah spesifikasi terbuka untuk mengevaluasi feature flag dengan API yang umum. Idenya sederhana: kode aplikasi Anda tidak boleh bergantung langsung pada vendor atau sistem internal yang Anda gunakan untuk flag.
Aplikasi ini bertanya:
const enabled = await client.getBooleanValue('checkout.v2.enabled', false, { targetingKey: user.id, plan: user.plan, country: user.country, });
Penyedia memutuskan dari mana aturan itu berasal: SaaS, file, layanan internal, flagd, konfigurasi GitOps. Jika suatu saat Anda mengubah fitur penandaan backend, aplikasi tidak perlu ditulis ulang di mana pun.
Pemisahan ini tampak seperti detail arsitektural, namun terasa seiring berkembangnya proyek.
Konteks adalah setengah dari perjuangan
Bendera aktif atau nonaktif untuk semua orang berguna, namun terbatas. Pengiriman progresif hidup dalam konteks:
- pengguna internal atau eksternal;
- paket gratis atau perusahaan;
- desa;
- organisasi;
- versi aplikasi;
- persentase lalu lintas yang stabil.
Kunci pentingnya adalah targetingKey: harus stabil. Jika berubah pada setiap permintaan, pengguna dapat berakhir satu kali di varian A dan satu kali di varian B. Untuk eksperimen, ini buruk, untuk pembayaran, ini bisa menjadi bencana.
Peluncuran yang masuk akal
Aliran yang saya suka adalah ini:
- menyebarkan dengan menandai;
- pengapian untuk pengembang dan QA;
- aktifkan untuk pelanggan atau penyewa percontohan;
- 5% peluncuran;
- peluncuran sebesar 25%;
- peluncuran 100%;
- penghapusan kode dan flag lama.
Poin yang sering terlupakan adalah poin terakhir. Bendera sementara harus memiliki tanggal kematian. Jika tetap selamanya, setiap refactor di masa depan harus bertanya: "tetapi apakah cabang ini masih berguna?".
Kill switch: persiapkan terlebih dahulu
kill switch adalah tanda yang menyelamatkan Anda ketika ketergantungan eksternal mulai mengganggu Anda, pekerjaan menghabiskan terlalu banyak sumber daya, atau logika baru menghasilkan kesalahan aneh.
kill switch yang baik haruslah:
- mudah ditemukan;
- didokumentasikan dalam runbook;
- diuji sesekali;
- dapat diamati saat diaktifkan;
- independen, sejauh mungkin, dari bagian yang dapat pecah.
Hal terburuknya adalah ketika kecelakaan itu diketahui bahwa bendera itu ada, tetapi tidak ada yang tahu apakah bendera itu masih berfungsi.
Observabilitas atau tidak pengiriman progresif
Mengaktifkan fitur pada 10% tanpa melihat metrik hanyalah optimisme dengan beberapa langkah.
Setiap peluncuran harus menjawab pertanyaan sederhana:
- apakah kesalahan meningkat?
- apakah latensinya berubah?
- apakah pengguna menyelesaikan alurnya?
- apakah ada tiket lagi atau percobaan ulang?
- apakah suatu varian hanya berdampak pada satu segmen?
OpenFeature mendukung kaitan seputar evaluasi bendera. Mereka berguna untuk mencatat kesalahan, menambahkan metrik, atau menghubungkan peringkat ke trace.
Penamaan dan kepemilikan
Nama penting. new_ui tidak mengatakan apa-apa. checkout.v2.enabled mengatakan lebih banyak lagi.
Untuk setiap bendera saya akan menandai setidaknya:
- nama;
- keterangan;
- pemilik;
- bawaan yang aman;
- alasan mengapa hal itu ada;
- tanggal atau kondisi penghapusan.
Bendera tanpa pemilik hampir selalu merupakan bendera yang tidak akan dihapuskan oleh siapa pun.
Tempat untuk mengevaluasinya
Frontend, backend, atau tepi? Bergantung.
Jika tandanya untuk tata letak, penyalinan, atau orientasi, frontendnya baik-baik saja. Jika menyangkut perizinan, penagihan, batasan atau data sensitif, itu harus ada di backend. Jika ini melibatkan perutean atau eksperimen dengan lalu lintas tinggi, keunggulan ini mungkin masuk akal.
Aturan sederhananya: frontend dapat meningkatkan pengalaman, namun tidak boleh menjadi satu-satunya penghalang keamanan.
Kesimpulan
feature flag yang dilakukan dengan baik mengubah hubungan dengan produksi. Tindakan ini tidak menghilangkan risiko, namun membuatnya lebih kecil dan lebih mudah dikelola. Anda dapat melepaskannya sedikit demi sedikit, mengamati, berhenti, kembali, belajar.
OpenFeature menambahkan fondasi yang bersih: API yang umum, penyedia yang dapat dipertukarkan, dan cara yang lebih rapi untuk mengembangkan sistem. Namun disiplin tetap menjadi milik Anda: default yang aman, nama yang jelas, metrik, pemilik, dan kebersihan.
Bendera terbaik adalah yang membantu Anda melepaskannya dengan tenang dan kemudian menghilang saat tidak diperlukan lagi.