Feature flag: lepaskan tanpa menahan nafas anda

spinny:~/writing $ vim 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~

NORMAL · openfeature-feature-flags-progressive-delivery.md [readonly]131 lines · :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}

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~