Feature flag: nefesinizi tutmadan bırakın

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

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

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~