Feature flag: lepaskan tanpa menahan nafas anda

spinny:~/writing $ less openfeature-feature-flags-progressive-delivery.md

1 
2Deployment 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.
3 
4feature 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.
5 
6## Bendera bukan sekadar jika
7 
8Secara teknikal ia selalunya `if`. Secara budaya ia lebih banyak lagi.
9 
10```typescript
11if (await flags.isEnabled('checkout.v2.enabled', context)) {
12  return newCheckout(input);
13}
14 
15return oldCheckout(input);
16```
17 
18`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.
19 
20## Di mana OpenFeature masuk
21 
22OpenFeature 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.
23 
24Aplikasi itu bertanya:
25 
26```typescript
27const enabled = await client.getBooleanValue('checkout.v2.enabled', false, {
28  targetingKey: user.id,
29  plan: user.plan,
30  country: user.country,
31});
32```
33 
34Pembekal 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.
35 
36Pemisahan ini kelihatan seperti perincian seni bina, tetapi ia dirasai apabila projek itu berkembang.
37 
38## Konteks adalah separuh daripada pertempuran
39 
40Bendera hidup atau mati untuk semua orang berguna, tetapi terhad. Penyampaian progresif hidup dalam konteks:
41 
42- pengguna dalaman atau luaran;
43- pelan percuma atau perusahaan;
44- kampung;
45- organisasi;
46- versi apl;
47- peratusan trafik yang stabil.
48 
49Kunci 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.
50 
51## Pelancaran yang wajar
52 
53Aliran yang saya suka ialah ini:
54 
551. gunakan dengan bendera dimatikan;
562. pencucuhan untuk pemaju dan QA;
573. hidupkan untuk pelanggan perintis atau penyewa;
584. 5% pelancaran;
595. pelancaran pada 25%;
606. 100% pelancaran;
617. penyingkiran kod dan bendera lama.
62 
63Perkara 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?".
64 
65## Kill switch: sediakan dahulu
66 
67kill switch ialah bendera yang menyelamatkan anda apabila pergantungan luar mula mengacaukan anda, kerja menggunakan terlalu banyak sumber atau logik baharu menghasilkan ralat pelik.
68 
69kill switch yang baik mestilah:
70 
71- mudah dicari;
72- didokumenkan dalam buku panduan;
73- diuji sekali-sekala;
74- boleh diperhatikan apabila diaktifkan;
75- bebas, sejauh mungkin, dari bahagian yang boleh pecah.
76 
77Perkara yang paling teruk ialah mengetahui semasa kemalangan bahawa bendera itu wujud, tetapi tiada siapa yang tahu sama ada ia masih berfungsi.
78 
79## Penyampaian boleh diperhatikan atau tidak progresif
80 
81Menghidupkan ciri pada 10% tanpa melihat metrik hanyalah keyakinan dengan berbilang langkah.
82 
83Setiap pelancaran hendaklah menjawab soalan mudah:
84 
85- adakah kesilapan meningkat?
86- adakah kependaman telah berubah?
87- adakah pengguna melengkapkan aliran?
88- adakah terdapat lebih tiket atau percubaan semula?
89- adakah varian memberi kesan kepada satu segmen sahaja?
90 
91OpenFeature menyokong cangkuk sekitar penilaian bendera. Ia berguna untuk ralat pengelogan, menambah metrik atau memautkan rating kepada trace.
92 
93## Penamaan dan pemilikan
94 
95Nama penting. `new_ui` tidak berkata apa-apa. `checkout.v2.enabled` mengatakan banyak lagi.
96 
97Untuk setiap bendera saya akan menandakan sekurang-kurangnya:
98 
99- nama;
100- penerangan;
101- pemilik;
102- lalai selamat;
103- sebab mengapa ia wujud;
104- tarikh atau syarat penyingkiran.
105 
106Bendera tanpa pemilik hampir selalu merupakan bendera yang tidak akan dibersihkan oleh sesiapa pun.
107 
108## Di mana untuk menilai mereka
109 
110Bahagian hadapan, bahagian belakang atau tepi? Terpulang.
111 
112Jika 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.
113 
114Peraturan mudah: bahagian hadapan boleh meningkatkan pengalaman, tetapi ia bukan satu-satunya halangan keselamatan.
115 
116## Kesimpulan
117 
118feature 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.
119 
120OpenFeature 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.
121 
122Bendera terbaik ialah bendera yang membantu anda melepaskan dengan tenang dan kemudian hilang apabila ia tidak lagi diperlukan.
123 
124## Sumber
125 
126- [OpenFeature: Introduction](https://openfeature.dev/docs/reference/intro/)
127- [OpenFeature: Node.js SDK](https://openfeature.dev/docs/reference/sdks/server/javascript/)
128- [OpenFeature Specification: Flag Evaluation API](https://openfeature.dev/specification/sections/flag-evaluation)
129- [OpenFeature: Hooks](https://openfeature.dev/docs/reference/concepts/hooks/)
130- [CNCF: OpenFeature](https://www.cncf.io/projects/openfeature/)
131

:Feature flag: lepaskan tanpa menahan nafas andalines 1-131 (END) — press q to close

2Deployment 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.

4feature 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.

6## Bendera bukan sekadar jika

8Secara teknikal ia selalunya `if`. Secara budaya ia lebih banyak lagi.

10```typescript

11if (await flags.isEnabled('checkout.v2.enabled', context)) {

12 return newCheckout(input);

13}

15return oldCheckout(input);

16```

18`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.

20## Di mana OpenFeature masuk

22OpenFeature 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.

24Aplikasi itu bertanya:

26```typescript

27const enabled = await client.getBooleanValue('checkout.v2.enabled', false, {

28 targetingKey: user.id,

29 plan: user.plan,

30 country: user.country,

31});

32```

34Pembekal 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.

36Pemisahan ini kelihatan seperti perincian seni bina, tetapi ia dirasai apabila projek itu berkembang.

38## Konteks adalah separuh daripada pertempuran

40Bendera hidup atau mati untuk semua orang berguna, tetapi terhad. Penyampaian progresif hidup dalam konteks:

42- pengguna dalaman atau luaran;

43- pelan percuma atau perusahaan;

44- kampung;

45- organisasi;

46- versi apl;

47- peratusan trafik yang stabil.

49Kunci 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.

51## Pelancaran yang wajar

53Aliran yang saya suka ialah ini:

551. gunakan dengan bendera dimatikan;

562. pencucuhan untuk pemaju dan QA;

573. hidupkan untuk pelanggan perintis atau penyewa;

584. 5% pelancaran;

595. pelancaran pada 25%;

606. 100% pelancaran;

617. penyingkiran kod dan bendera lama.

63Perkara 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?".

65## Kill switch: sediakan dahulu

67kill switch ialah bendera yang menyelamatkan anda apabila pergantungan luar mula mengacaukan anda, kerja menggunakan terlalu banyak sumber atau logik baharu menghasilkan ralat pelik.

69kill switch yang baik mestilah:

71- mudah dicari;

72- didokumenkan dalam buku panduan;

73- diuji sekali-sekala;

74- boleh diperhatikan apabila diaktifkan;

75- bebas, sejauh mungkin, dari bahagian yang boleh pecah.

77Perkara yang paling teruk ialah mengetahui semasa kemalangan bahawa bendera itu wujud, tetapi tiada siapa yang tahu sama ada ia masih berfungsi.

79## Penyampaian boleh diperhatikan atau tidak progresif

81Menghidupkan ciri pada 10% tanpa melihat metrik hanyalah keyakinan dengan berbilang langkah.

83Setiap pelancaran hendaklah menjawab soalan mudah:

85- adakah kesilapan meningkat?

86- adakah kependaman telah berubah?

87- adakah pengguna melengkapkan aliran?

88- adakah terdapat lebih tiket atau percubaan semula?

89- adakah varian memberi kesan kepada satu segmen sahaja?

91OpenFeature menyokong cangkuk sekitar penilaian bendera. Ia berguna untuk ralat pengelogan, menambah metrik atau memautkan rating kepada trace.

93## Penamaan dan pemilikan

95Nama penting. `new_ui` tidak berkata apa-apa. `checkout.v2.enabled` mengatakan banyak lagi.

97Untuk setiap bendera saya akan menandakan sekurang-kurangnya:

99- nama;

100- penerangan;

101- pemilik;

102- lalai selamat;

103- sebab mengapa ia wujud;

104- tarikh atau syarat penyingkiran.

105

106Bendera tanpa pemilik hampir selalu merupakan bendera yang tidak akan dibersihkan oleh sesiapa pun.

107

108## Di mana untuk menilai mereka

109

110Bahagian hadapan, bahagian belakang atau tepi? Terpulang.

111

112Jika 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.

113

114Peraturan mudah: bahagian hadapan boleh meningkatkan pengalaman, tetapi ia bukan satu-satunya halangan keselamatan.

115

116## Kesimpulan

117

118feature 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.

119

120OpenFeature 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.

121

122Bendera terbaik ialah bendera yang membantu anda melepaskan dengan tenang dan kemudian hilang apabila ia tidak lagi diperlukan.

123

124## Sumber

125

126- [OpenFeature: Introduction](https://openfeature.dev/docs/reference/intro/)

127- [OpenFeature: Node.js SDK](https://openfeature.dev/docs/reference/sdks/server/javascript/)

128- [OpenFeature Specification: Flag Evaluation API](https://openfeature.dev/specification/sections/flag-evaluation)

129- [OpenFeature: Hooks](https://openfeature.dev/docs/reference/concepts/hooks/)

130- [CNCF: OpenFeature](https://www.cncf.io/projects/openfeature/)

131