Feature flag: nefesinizi tutmadan bırakın

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

1 
2Dağıtım, kodun üretime ulaştığı zamandır. Serbest bırakma, birisinin onu gerçekten kullanabileceği zamandır. Bu ikisini karıştırmak, her konuşlandırmayı biraz gergin bir an haline getirmenin en hızlı yollarından biridir.
3 
4feature flag bu iki an arasına boşluk koymaya yarar. Bugün dağıtıma çıkabilir, yarın dahili ekip için, ardından pilot müşteri için, ardından kullanıcıların %10'u için devreye alabilirsiniz. Bir şeyler ters giderse bayrağı kapatın. Sürümün tamamını geri almanız gerekmez.
5 
6## Bayrak yalnızca bir if değildir
7 
8Teknik olarak genellikle `if`'dir. Kültürel olarak çok daha fazlası.
9 
10```typescript
11if (await flags.isEnabled('checkout.v2.enabled', context)) {
12  return newCheckout(input);
13}
14 
15return oldCheckout(input);
16```
17 
18Bu küçük `if` kademeli bir kullanıma sunma, bir deney, bir geçiş, bir işletme izni veya operasyonel bir kill switch anlamına gelebilir. Sorun şu ki, eğer bunu iyi yönetemezseniz, iki yıl boyunca kodda kalan teknik borca da dönüşebilir.
19 
20## OpenFeature nerede devreye giriyor?
21 
22OpenFeature, feature flag'yi ortak bir API ile değerlendirmek için açık bir spesifikasyondur. Fikir basit: uygulama kodunuz doğrudan satıcıya veya bayraklar için kullandığınız dahili sisteme bağlı olmamalıdır.
23 
24Uygulama şunu sorar:
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 
34Sağlayıcı, kuralların nereden geleceğine karar verir: SaaS, dosya, dahili hizmet, flagd, GitOps yapılandırması. Bir gün özellik işaretleme arka ucunu değiştirirseniz uygulamanın her yere yeniden yazılması gerekmez.
35 
36Bu ayrım mimari bir detay gibi görünse de proje büyüdükçe hissediliyor.
37 
38## Bağlam savaşın yarısıdır
39 
40Herkes için açık veya kapalı işareti faydalıdır ancak sınırlıdır. Aşamalı teslimat şu bağlamda yaşar:
41 
42- dahili veya harici kullanıcı;
43- ücretsiz veya kurumsal plan;
44- köy;
45- organizasyon;
46- uygulama sürümü;
47- istikrarlı trafik yüzdesi.
48 
49Önemli anahtar `targetingKey`: stabil olmalı. Her istekte değişirse, kullanıcı bir kez A varyantına, bir kez de B varyantına düşebilir. Bir deneme için bu berbat, ödeme içinse felaket olabilir.
50 
51## Mantıklı bir dağıtım
52 
53Beğendiğim bir akış şu:
54 
551. bayrak kapalıyken konuşlandırın;
562. geliştiriciler ve QA için ateşleme;
573. Pilot müşteri veya kiracı için çalıştırma;
584. %5'lik dağıtım;
595. %25'lik dağıtım;
606. %100 kullanıma sunma;
617. Eski kodun ve bayrağın kaldırılması.
62 
63Çoğu zaman unutulan nokta ise sonuncusudur. Geçici bir bayrağın ölüm tarihi olmalıdır. Eğer sonsuza kadar kalırsa, gelecekteki her yeniden düzenlemeci şunu sormak zorunda kalacak: "Fakat bu dal hala faydalı mı?".
64 
65## Kill switch: önce onları hazırlayın
66 
67kill switch, harici bir bağımlılık sizi rahatsız etmeye başladığında, bir iş çok fazla kaynak tükettiğinde veya yeni mantık garip hatalar ürettiğinde sizi kurtaran bayraktır.
68 
69İyi bir kill switch şöyle olmalıdır:
70 
71- bulunması kolay;
72- runbook'ta belgelenmiştir;
73- ara sıra test edilmiştir;
74- etkinleştirildiğinde gözlemlenebilir;
75- Kırılabilecek kısımdan mümkün olduğu kadar bağımsız.
76 
77En kötüsü kaza sırasında bayrağın var olduğunu keşfetmek ama kimse hala çalışıp çalışmadığını bilmiyor.
78 
79## Gözlemlenebilirlik veya aşamalı olmayan dağıtım
80 
81Bir özelliği metriklere bakmadan %10 oranında açmak, birden fazla adım içeren bir iyimserliktir.
82 
83Her kullanıma sunma basit sorulara yanıt vermelidir:
84 
85- hatalar arttı mı?
86- gecikme değişti mi?
87- kullanıcılar akışı tamamlıyor mu?
88- daha fazla bilet veya yeniden deneme var mı?
89- Bir değişken yalnızca bir segmenti mi etkiliyor?
90 
91OpenFeature bayrak değerlendirmesi etrafındaki kancaları destekler. Hataları günlüğe kaydetmek, ölçümler eklemek veya derecelendirmeyi trace'ye bağlamak için kullanışlıdırlar.
92 
93## Adlandırma ve sahiplik
94 
95İsimler önemlidir. `new_ui` hiçbir şey söylemiyor. `checkout.v2.enabled` çok daha fazlasını söylüyor.
96 
97Her bayrak için en azından şunu işaretlerdim:
98 
99- isim;
100- Tanım;
101- mal sahibi;
102- güvenli varsayılan;
103- var olmasının nedeni;
104- kaldırılma tarihi veya koşulu.
105 
106Sahipsiz bir bayrak neredeyse her zaman kimsenin kaldıramayacağı bir bayraktır.
107 
108## Bunları nerede değerlendirmeli
109 
110Ön uç, arka uç veya kenar? Bağlı olmak.
111 
112Bayrak düzen, kopyalama veya katılım içinse ön uçta sorun yoktur. İzinler, faturalandırma, sınırlar veya hassas verilerle ilgiliyse arka uçta yer alması gerekir. Yönlendirme veya yüksek trafik denemeleri içeriyorsa, kenar mantıklı olabilir.
113 
114Basit kural: Ön uç deneyimi iyileştirebilir ancak tek güvenlik engeli olmamalıdır.
115 
116## Sonuç
117 
118feature flag iyi yapıldığında üretimle olan ilişki değişir. Riski ortadan kaldırmazlar ancak onu daha küçük ve daha yönetilebilir hale getirirler. Dilimler halinde serbest bırakabilir, gözlemleyebilir, durabilir, geri dönebilir, öğrenebilirsiniz.
119 
120OpenFeature temiz bir temel ekler: ortak bir API, değiştirilebilir sağlayıcılar ve sistemi büyütmenin daha düzenli bir yolu. Ancak disiplin sizin elinizde: Güvenli varsayılanlar, net isimler, ölçümler, sahipler ve temizlik.
121 
122En iyi bayrak, sakince salıvermenize yardımcı olan ve artık ihtiyaç duyulmadığında kaybolan bayraktır.
123 
124## Kaynaklar
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: nefesinizi tutmadan bırakınlines 1-131 (END) — press q to close

2Dağıtım, kodun üretime ulaştığı zamandır. Serbest bırakma, birisinin onu gerçekten kullanabileceği zamandır. Bu ikisini karıştırmak, her konuşlandırmayı biraz gergin bir an haline getirmenin en hızlı yollarından biridir.

4feature flag bu iki an arasına boşluk koymaya yarar. Bugün dağıtıma çıkabilir, yarın dahili ekip için, ardından pilot müşteri için, ardından kullanıcıların %10'u için devreye alabilirsiniz. Bir şeyler ters giderse bayrağı kapatın. Sürümün tamamını geri almanız gerekmez.

6## Bayrak yalnızca bir if değildir

8Teknik olarak genellikle `if`'dir. Kültürel olarak çok daha fazlası.

10```typescript

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

12 return newCheckout(input);

13}

15return oldCheckout(input);

16```

18Bu küçük `if` kademeli bir kullanıma sunma, bir deney, bir geçiş, bir işletme izni veya operasyonel bir kill switch anlamına gelebilir. Sorun şu ki, eğer bunu iyi yönetemezseniz, iki yıl boyunca kodda kalan teknik borca da dönüşebilir.

20## OpenFeature nerede devreye giriyor?

22OpenFeature, feature flag'yi ortak bir API ile değerlendirmek için açık bir spesifikasyondur. Fikir basit: uygulama kodunuz doğrudan satıcıya veya bayraklar için kullandığınız dahili sisteme bağlı olmamalıdır.

24Uygulama şunu sorar:

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

34Sağlayıcı, kuralların nereden geleceğine karar verir: SaaS, dosya, dahili hizmet, flagd, GitOps yapılandırması. Bir gün özellik işaretleme arka ucunu değiştirirseniz uygulamanın her yere yeniden yazılması gerekmez.

36Bu ayrım mimari bir detay gibi görünse de proje büyüdükçe hissediliyor.

38## Bağlam savaşın yarısıdır

40Herkes için açık veya kapalı işareti faydalıdır ancak sınırlıdır. Aşamalı teslimat şu bağlamda yaşar:

42- dahili veya harici kullanıcı;

43- ücretsiz veya kurumsal plan;

44- köy;

45- organizasyon;

46- uygulama sürümü;

47- istikrarlı trafik yüzdesi.

49Önemli anahtar `targetingKey`: stabil olmalı. Her istekte değişirse, kullanıcı bir kez A varyantına, bir kez de B varyantına düşebilir. Bir deneme için bu berbat, ödeme içinse felaket olabilir.

51## Mantıklı bir dağıtım

53Beğendiğim bir akış şu:

551. bayrak kapalıyken konuşlandırın;

562. geliştiriciler ve QA için ateşleme;

573. Pilot müşteri veya kiracı için çalıştırma;

584. %5'lik dağıtım;

595. %25'lik dağıtım;

606. %100 kullanıma sunma;

617. Eski kodun ve bayrağın kaldırılması.

63Çoğu zaman unutulan nokta ise sonuncusudur. Geçici bir bayrağın ölüm tarihi olmalıdır. Eğer sonsuza kadar kalırsa, gelecekteki her yeniden düzenlemeci şunu sormak zorunda kalacak: "Fakat bu dal hala faydalı mı?".

65## Kill switch: önce onları hazırlayın

67kill switch, harici bir bağımlılık sizi rahatsız etmeye başladığında, bir iş çok fazla kaynak tükettiğinde veya yeni mantık garip hatalar ürettiğinde sizi kurtaran bayraktır.

69İyi bir kill switch şöyle olmalıdır:

71- bulunması kolay;

72- runbook'ta belgelenmiştir;

73- ara sıra test edilmiştir;

74- etkinleştirildiğinde gözlemlenebilir;

75- Kırılabilecek kısımdan mümkün olduğu kadar bağımsız.

77En kötüsü kaza sırasında bayrağın var olduğunu keşfetmek ama kimse hala çalışıp çalışmadığını bilmiyor.

79## Gözlemlenebilirlik veya aşamalı olmayan dağıtım

81Bir özelliği metriklere bakmadan %10 oranında açmak, birden fazla adım içeren bir iyimserliktir.

83Her kullanıma sunma basit sorulara yanıt vermelidir:

85- hatalar arttı mı?

86- gecikme değişti mi?

87- kullanıcılar akışı tamamlıyor mu?

88- daha fazla bilet veya yeniden deneme var mı?

89- Bir değişken yalnızca bir segmenti mi etkiliyor?

91OpenFeature bayrak değerlendirmesi etrafındaki kancaları destekler. Hataları günlüğe kaydetmek, ölçümler eklemek veya derecelendirmeyi trace'ye bağlamak için kullanışlıdırlar.

93## Adlandırma ve sahiplik

95İsimler önemlidir. `new_ui` hiçbir şey söylemiyor. `checkout.v2.enabled` çok daha fazlasını söylüyor.

97Her bayrak için en azından şunu işaretlerdim:

99- isim;

100- Tanım;

101- mal sahibi;

102- güvenli varsayılan;

103- var olmasının nedeni;

104- kaldırılma tarihi veya koşulu.

105

106Sahipsiz bir bayrak neredeyse her zaman kimsenin kaldıramayacağı bir bayraktır.

107

108## Bunları nerede değerlendirmeli

109

110Ön uç, arka uç veya kenar? Bağlı olmak.

111

112Bayrak düzen, kopyalama veya katılım içinse ön uçta sorun yoktur. İzinler, faturalandırma, sınırlar veya hassas verilerle ilgiliyse arka uçta yer alması gerekir. Yönlendirme veya yüksek trafik denemeleri içeriyorsa, kenar mantıklı olabilir.

113

114Basit kural: Ön uç deneyimi iyileştirebilir ancak tek güvenlik engeli olmamalıdır.

115

116## Sonuç

117

118feature flag iyi yapıldığında üretimle olan ilişki değişir. Riski ortadan kaldırmazlar ancak onu daha küçük ve daha yönetilebilir hale getirirler. Dilimler halinde serbest bırakabilir, gözlemleyebilir, durabilir, geri dönebilir, öğrenebilirsiniz.

119

120OpenFeature temiz bir temel ekler: ortak bir API, değiştirilebilir sağlayıcılar ve sistemi büyütmenin daha düzenli bir yolu. Ancak disiplin sizin elinizde: Güvenli varsayılanlar, net isimler, ölçümler, sahipler ve temizlik.

121

122En iyi bayrak, sakince salıvermenize yardımcı olan ve artık ihtiyaç duyulmadığında kaybolan bayraktır.

123

124## Kaynaklar

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