Deployment ialah apabila kod tiba dalam pengeluaran. Pelepasan adalah apabila seseorang benar-benar boleh menggunakannya. Mengelirukan kedua-duanya adalah salah satu cara terpantas untuk menjadikan setiap penempatan menjadi sedikit tegang.
feature flag berfungsi untuk meletakkan ruang di antara dua detik ini. Anda boleh menggunakan hari ini, mulakan esok untuk pasukan dalaman, kemudian untuk pelanggan perintis, kemudian untuk 10% pengguna. Jika berlaku masalah, matikan bendera. Anda tidak semestinya perlu menarik balik keseluruhan keluaran.
Bendera bukan sekadar jika
Secara teknikal ia selalunya if. Secara budaya ia lebih banyak lagi.
if (await flags.isEnabled('checkout.v2.enabled', context)) { return newCheckout(input); } return oldCheckout(input);
if kecil itu boleh mewakili pelancaran beransur-ansur, percubaan, penghijrahan, permit perusahaan atau kill switch operasi. Masalahnya ialah jika anda tidak menguruskannya dengan baik, ia juga boleh menjadi hutang teknikal yang kekal dalam kod selama dua tahun.
Di mana OpenFeature masuk
OpenFeature ialah spesifikasi terbuka untuk menilai feature flag dengan API biasa. Ideanya mudah: kod aplikasi anda tidak boleh bergantung secara langsung pada vendor atau sistem dalaman yang anda gunakan untuk bendera.
Aplikasi itu bertanya:
const enabled = await client.getBooleanValue('checkout.v2.enabled', false, { targetingKey: user.id, plan: user.plan, country: user.country, });
Pembekal memutuskan dari mana datangnya peraturan: SaaS, fail, perkhidmatan dalaman, dibenderakan, konfigurasi GitOps. Jika suatu hari anda menukar bahagian belakang pembenderaan ciri, aplikasi itu tidak perlu ditulis semula di mana-mana sahaja.
Pemisahan ini kelihatan seperti perincian seni bina, tetapi ia dirasai apabila projek itu berkembang.
Konteks adalah separuh daripada pertempuran
Bendera hidup atau mati untuk semua orang berguna, tetapi terhad. Penyampaian progresif hidup dalam konteks:
- pengguna dalaman atau luaran;
- pelan percuma atau perusahaan;
- kampung;
- organisasi;
- versi apl;
- peratusan trafik yang stabil.
Kunci penting ialah targetingKey: ia mestilah stabil. Jika ia berubah dengan setiap permintaan, pengguna boleh berakhir sekali dalam varian A dan sekali dalam varian B. Untuk percubaan, ia adalah mengerikan, untuk pembayaran ia boleh membawa bencana.
Pelancaran yang wajar
Aliran yang saya suka ialah ini:
- gunakan dengan bendera dimatikan;
- pencucuhan untuk pemaju dan QA;
- hidupkan untuk pelanggan perintis atau penyewa;
- 5% pelancaran;
- pelancaran pada 25%;
- 100% pelancaran;
- penyingkiran kod dan bendera lama.
Perkara yang sering dilupakan adalah yang terakhir. Bendera sementara mesti mempunyai tarikh kematian. Jika ia kekal selama-lamanya, setiap refactor akan datang perlu bertanya: "tetapi adakah cawangan ini masih berguna?".
Kill switch: sediakan dahulu
kill switch ialah bendera yang menyelamatkan anda apabila pergantungan luar mula mengacaukan anda, kerja menggunakan terlalu banyak sumber atau logik baharu menghasilkan ralat pelik.
kill switch yang baik mestilah:
- mudah dicari;
- didokumenkan dalam buku panduan;
- diuji sekali-sekala;
- boleh diperhatikan apabila diaktifkan;
- bebas, sejauh mungkin, dari bahagian yang boleh pecah.
Perkara yang paling teruk ialah mengetahui semasa kemalangan bahawa bendera itu wujud, tetapi tiada siapa yang tahu sama ada ia masih berfungsi.
Penyampaian boleh diperhatikan atau tidak progresif
Menghidupkan ciri pada 10% tanpa melihat metrik hanyalah keyakinan dengan berbilang langkah.
Setiap pelancaran hendaklah menjawab soalan mudah:
- adakah kesilapan meningkat?
- adakah kependaman telah berubah?
- adakah pengguna melengkapkan aliran?
- adakah terdapat lebih tiket atau percubaan semula?
- adakah varian memberi kesan kepada satu segmen sahaja?
OpenFeature menyokong cangkuk sekitar penilaian bendera. Ia berguna untuk ralat pengelogan, menambah metrik atau memautkan rating kepada trace.
Penamaan dan pemilikan
Nama penting. new_ui tidak berkata apa-apa. checkout.v2.enabled mengatakan banyak lagi.
Untuk setiap bendera saya akan menandakan sekurang-kurangnya:
- nama;
- penerangan;
- pemilik;
- lalai selamat;
- sebab mengapa ia wujud;
- tarikh atau syarat penyingkiran.
Bendera tanpa pemilik hampir selalu merupakan bendera yang tidak akan dibersihkan oleh sesiapa pun.
Di mana untuk menilai mereka
Bahagian hadapan, bahagian belakang atau tepi? Terpulang.
Jika bendera adalah untuk reka letak, salin atau onboarding, bahagian hadapan adalah baik. Jika ia melibatkan kebenaran, pengebilan, had atau data sensitif, ia mesti berada di bahagian belakang. Jika ia melibatkan penghalaan atau eksperimen trafik tinggi, kelebihan mungkin masuk akal.
Peraturan mudah: bahagian hadapan boleh meningkatkan pengalaman, tetapi ia bukan satu-satunya halangan keselamatan.
Kesimpulan
feature flag dilakukan dengan baik mengubah hubungan dengan pengeluaran. Mereka tidak menghapuskan risiko, tetapi mereka menjadikannya lebih kecil dan lebih mudah diurus. Anda boleh melepaskan dalam kepingan, memerhati, berhenti, kembali, belajar.
OpenFeature menambah asas yang bersih: API biasa, pembekal yang boleh ditukar ganti dan cara yang lebih kemas untuk mengembangkan sistem. Tetapi disiplin tetap milik anda: lalai yang selamat, nama yang jelas, metrik, pemilik dan kebersihan.
Bendera terbaik ialah bendera yang membantu anda melepaskan dengan tenang dan kemudian hilang apabila ia tidak lagi diperlukan.