1~
2परिनियोजन तब होता है जब कोड उत्पादन में आता है। रिलीज़ तब होती है जब कोई वास्तव में इसका उपयोग कर सकता है। दोनों को भ्रमित करना प्रत्येक परिनियोजन को थोड़ा तनावपूर्ण बनाने का सबसे तेज़ तरीकों में से एक है।
3~
4feature flag इन दो क्षणों के बीच जगह रखने का काम करता है। आप आज तैनात कर सकते हैं, कल आंतरिक टीम के लिए सक्रिय कर सकते हैं, फिर पायलट ग्राहक के लिए, फिर 10% उपयोगकर्ताओं के लिए। अगर कुछ गलत हो तो झंडा बंद कर दें. जरूरी नहीं कि आपको पूरी रिलीज को रोलबैक करना पड़े।
5~
6## झंडा सिर्फ एक अगर नहीं है
7~
8तकनीकी रूप से यह अक्सर `if` होता है। सांस्कृतिक रूप से यह बहुत अधिक है.
9~
10```typescript
11if (await flags.isEnabled('checkout.v2.enabled', context)) {
12  return newCheckout(input);
13}
14~
15return oldCheckout(input);
16```
17~
18वह छोटा `if` एक क्रमिक रोलआउट, एक प्रयोग, एक माइग्रेशन, एक एंटरप्राइज परमिट या एक परिचालन kill switch का प्रतिनिधित्व कर सकता है। समस्या यह है कि यदि आप इसे अच्छी तरह से प्रबंधित नहीं करते हैं, तो यह तकनीकी ऋण भी बन सकता है जो दो साल तक कोड में रहता है।
19~
20## OpenFeature कहां आता है
21~
22OpenFeature एक सामान्य API के साथ feature flag का मूल्यांकन करने के लिए एक खुला विनिर्देश है। विचार सरल है: आपका एप्लिकेशन कोड सीधे विक्रेता या झंडे के लिए आपके द्वारा उपयोग की जाने वाली आंतरिक प्रणाली पर निर्भर नहीं होना चाहिए।
23~
24ऐप पूछता है:
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~
34प्रदाता तय करता है कि नियम कहाँ से आते हैं: SaaS, फ़ाइल, आंतरिक सेवा, फ़्लैग, GitOps कॉन्फ़िगरेशन। यदि एक दिन आप फीचर फ़्लैगिंग बैकएंड बदलते हैं, तो एप्लिकेशन को हर जगह दोबारा लिखने की ज़रूरत नहीं है।
35~
36यह पृथक्करण एक वास्तुशिल्प विवरण की तरह लगता है, लेकिन जैसे-जैसे परियोजना बढ़ती है, इसे महसूस किया जाता है।
37~
38## संदर्भ आधी लड़ाई है
39~
40हर किसी के लिए ऑन या ऑफ फ़्लैग उपयोगी है, लेकिन सीमित है। प्रगतिशील वितरण संदर्भ में रहता है:
41~
42- आंतरिक या बाहरी उपयोगकर्ता;
43- मुफ़्त या उद्यम योजना;
44- गाँव;
45- संगठन;
46- एप्लिकेशन वेरीज़न;
47- यातायात का स्थिर प्रतिशत.
48~
49महत्वपूर्ण कुंजी `targetingKey` है: यह स्थिर होना चाहिए। यदि यह हर अनुरोध के साथ बदलता है, तो उपयोगकर्ता एक बार वैरिएंट ए में और एक बार वैरिएंट बी में जा सकता है। एक प्रयोग के लिए यह भयानक है, चेकआउट के लिए यह विनाशकारी हो सकता है।
50~
51## एक समझदार रोलआउट
52~
53एक प्रवाह जो मुझे पसंद है वह यह है:
54~
551. झंडी दिखाकर तैनात करना;
562. डेवलपर्स और क्यूए के लिए इग्निशन;
573. पायलट ग्राहक या किरायेदार के लिए स्विच-ऑन;
584. 5% रोलआउट;
595. 25% पर रोलआउट;
606. 100% रोलआउट;
617. पुराने कोड और झंडे को हटाना.
62~
63अक्सर भूला जाने वाला बिंदु आखिरी है। एक अस्थायी ध्वज में मृत्यु तिथि अवश्य अंकित होनी चाहिए। यदि यह हमेशा के लिए रहता है, तो प्रत्येक भविष्य के रिफैक्टर को पूछना होगा: "लेकिन क्या यह शाखा अभी भी उपयोगी है?"।
64~
65## Kill switch: पहले उन्हें तैयार करें
66~
67kill switch वह ध्वज है जो आपको तब बचाता है जब कोई बाहरी निर्भरता आपके साथ खिलवाड़ करने लगती है, कोई कार्य बहुत अधिक संसाधनों का उपभोग करता है, या नया तर्क अजीब त्रुटियाँ उत्पन्न करता है।
68~
69एक अच्छा kill switch होना चाहिए:
70~
71- खोजने में आसान;
72- रनबुक में प्रलेखित;
73- कभी-कभी परीक्षण किया जाता है;
74- सक्रिय होने पर देखने योग्य;
75- स्वतंत्र, जहाँ तक संभव हो, उस हिस्से से जो टूट सकता है।
76~
77सबसे बुरी बात यह है कि दुर्घटना के दौरान पता चला कि झंडा मौजूद है, लेकिन कोई नहीं जानता कि यह अभी भी काम करता है या नहीं।
78~
79## अवलोकनशीलता या प्रगतिशील वितरण नहीं
80~
81मेट्रिक्स को देखे बिना किसी सुविधा को 10% पर चालू करना कई चरणों वाला आशावाद है।
82~
83प्रत्येक रोलआउट को सरल प्रश्नों का उत्तर देना चाहिए:
84~
85- क्या त्रुटियां बढ़ गई हैं?
86- क्या विलंबता बदल गई है?
87- क्या उपयोगकर्ता प्रवाह पूरा करते हैं?
88- क्या और भी टिकट या पुनः प्रयास हैं?
89- क्या एक प्रकार केवल एक खंड को प्रभावित करता है?
90~
91OpenFeature ध्वज मूल्यांकन के चारों ओर हुक का समर्थन करता है। वे त्रुटियों को लॉग करने, मेट्रिक्स जोड़ने या रेटिंग को trace से जोड़ने के लिए उपयोगी हैं।
92~
93## नामकरण और स्वामित्व
94~
95नाम मायने रखते हैं. `new_ui` कुछ नहीं कहता. `checkout.v2.enabled` और भी बहुत कुछ कहता है.
96~
97प्रत्येक झंडे के लिए मैं कम से कम चिन्हित करूंगा:
98~
99- नाम;
100- विवरण;
101- मालिक;
102- सुरक्षित डिफ़ॉल्ट;
103- इसके अस्तित्व का कारण;
104- हटाने की तारीख या शर्त.
105~
106स्वामित्व रहित झंडा लगभग हमेशा एक ऐसा झंडा होता है जिसे कोई भी साफ़ नहीं करेगा।
107~
108## उनका मूल्यांकन कहां करें
109~
110फ्रंटएंड, बैकएंड या किनारा? निर्भर करता है.
111~
112यदि ध्वज लेआउट, कॉपी या ऑनबोर्डिंग के लिए है, तो फ्रंटेंड ठीक है। यदि यह अनुमतियों, बिलिंग, सीमाओं या संवेदनशील डेटा से संबंधित है, तो यह बैकएंड पर होना चाहिए। यदि इसमें रूटिंग या उच्च-ट्रैफ़िक प्रयोग शामिल हैं, तो बढ़त समझ में आ सकती है।
113~
114सरल नियम: फ्रंटएंड अनुभव को बेहतर बना सकता है, लेकिन यह एकमात्र सुरक्षा बाधा नहीं होनी चाहिए।
115~
116## निष्कर्ष
117~
118feature flag ने अच्छी तरह से उत्पादन के साथ संबंध बदल दिया। वे जोखिम को खत्म नहीं करते हैं, लेकिन वे इसे छोटा और अधिक प्रबंधनीय बनाते हैं। आप टुकड़ों में जारी कर सकते हैं, निरीक्षण कर सकते हैं, रुक सकते हैं, वापस जा सकते हैं, सीख सकते हैं।
119~
120OpenFeature एक स्वच्छ आधार जोड़ता है: एक सामान्य API, विनिमेय प्रदाता, और सिस्टम को विकसित करने का एक साफ-सुथरा तरीका। लेकिन अनुशासन आपका ही रहता है: सुरक्षित डिफ़ॉल्ट, स्पष्ट नाम, मेट्रिक्स, मालिक और साफ़-सफ़ाई।
121~
122सबसे अच्छा झंडा वह है जो आपको शांतिपूर्वक छोड़ने में मदद करता है और फिर गायब हो जाता है जब इसकी आवश्यकता नहीं रह जाती है।
123~
124## स्रोत
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~