Feature flag: अपनी सांस रोके बिना छोड़ें
· 5 min read · Filippo Spinella · DevOps, OpenFeature, CI/CD, Software Architecture
परिनियोजन तब होता है जब कोड उत्पादन में आता है। रिलीज़ तब होती है जब कोई वास्तव में इसका उपयोग कर सकता है। दोनों को भ्रमित करना प्रत्येक परिनियोजन को थोड़ा तनावपूर्ण बनाने का सबसे तेज़ तरीकों में से एक है।
feature flag इन दो क्षणों के बीच जगह रखने का काम करता है। आप आज तैनात कर सकते हैं, कल आंतरिक टीम के लिए सक्रिय कर सकते हैं, फिर पायलट ग्राहक के लिए, फिर 10% उपयोगकर्ताओं के लिए। अगर कुछ गलत हो तो झंडा बंद कर दें. जरूरी नहीं कि आपको पूरी रिलीज को रोलबैक करना पड़े।
झंडा सिर्फ एक अगर नहीं है
तकनीकी रूप से यह अक्सर if होता है। सांस्कृतिक रूप से यह बहुत अधिक है.
if (await flags.isEnabled('checkout.v2.enabled', context)) { return newCheckout(input); } return oldCheckout(input);
वह छोटा if एक क्रमिक रोलआउट, एक प्रयोग, एक माइग्रेशन, एक एंटरप्राइज परमिट या एक परिचालन kill switch का प्रतिनिधित्व कर सकता है। समस्या यह है कि यदि आप इसे अच्छी तरह से प्रबंधित नहीं करते हैं, तो यह तकनीकी ऋण भी बन सकता है जो दो साल तक कोड में रहता है।
OpenFeature कहां आता है
OpenFeature एक सामान्य API के साथ feature flag का मूल्यांकन करने के लिए एक खुला विनिर्देश है। विचार सरल है: आपका एप्लिकेशन कोड सीधे विक्रेता या झंडे के लिए आपके द्वारा उपयोग की जाने वाली आंतरिक प्रणाली पर निर्भर नहीं होना चाहिए।
ऐप पूछता है:
const enabled = await client.getBooleanValue('checkout.v2.enabled', false, { targetingKey: user.id, plan: user.plan, country: user.country, });
प्रदाता तय करता है कि नियम कहाँ से आते हैं: SaaS, फ़ाइल, आंतरिक सेवा, फ़्लैग, GitOps कॉन्फ़िगरेशन। यदि एक दिन आप फीचर फ़्लैगिंग बैकएंड बदलते हैं, तो एप्लिकेशन को हर जगह दोबारा लिखने की ज़रूरत नहीं है।
यह पृथक्करण एक वास्तुशिल्प विवरण की तरह लगता है, लेकिन जैसे-जैसे परियोजना बढ़ती है, इसे महसूस किया जाता है।
संदर्भ आधी लड़ाई है
हर किसी के लिए ऑन या ऑफ फ़्लैग उपयोगी है, लेकिन सीमित है। प्रगतिशील वितरण संदर्भ में रहता है:
- आंतरिक या बाहरी उपयोगकर्ता;
- मुफ़्त या उद्यम योजना;
- गाँव;
- संगठन;
- एप्लिकेशन वेरीज़न;
- यातायात का स्थिर प्रतिशत.
महत्वपूर्ण कुंजी targetingKey है: यह स्थिर होना चाहिए। यदि यह हर अनुरोध के साथ बदलता है, तो उपयोगकर्ता एक बार वैरिएंट ए में और एक बार वैरिएंट बी में जा सकता है। एक प्रयोग के लिए यह भयानक है, चेकआउट के लिए यह विनाशकारी हो सकता है।
एक समझदार रोलआउट
एक प्रवाह जो मुझे पसंद है वह यह है:
- झंडी दिखाकर तैनात करना;
- डेवलपर्स और क्यूए के लिए इग्निशन;
- पायलट ग्राहक या किरायेदार के लिए स्विच-ऑन;
- 5% रोलआउट;
- 25% पर रोलआउट;
- 100% रोलआउट;
- पुराने कोड और झंडे को हटाना.
अक्सर भूला जाने वाला बिंदु आखिरी है। एक अस्थायी ध्वज में मृत्यु तिथि अवश्य अंकित होनी चाहिए। यदि यह हमेशा के लिए रहता है, तो प्रत्येक भविष्य के रिफैक्टर को पूछना होगा: "लेकिन क्या यह शाखा अभी भी उपयोगी है?"।
Kill switch: पहले उन्हें तैयार करें
kill switch वह ध्वज है जो आपको तब बचाता है जब कोई बाहरी निर्भरता आपके साथ खिलवाड़ करने लगती है, कोई कार्य बहुत अधिक संसाधनों का उपभोग करता है, या नया तर्क अजीब त्रुटियाँ उत्पन्न करता है।
एक अच्छा kill switch होना चाहिए:
- खोजने में आसान;
- रनबुक में प्रलेखित;
- कभी-कभी परीक्षण किया जाता है;
- सक्रिय होने पर देखने योग्य;
- स्वतंत्र, जहाँ तक संभव हो, उस हिस्से से जो टूट सकता है।
सबसे बुरी बात यह है कि दुर्घटना के दौरान पता चला कि झंडा मौजूद है, लेकिन कोई नहीं जानता कि यह अभी भी काम करता है या नहीं।
अवलोकनशीलता या प्रगतिशील वितरण नहीं
मेट्रिक्स को देखे बिना किसी सुविधा को 10% पर चालू करना कई चरणों वाला आशावाद है।
प्रत्येक रोलआउट को सरल प्रश्नों का उत्तर देना चाहिए:
- क्या त्रुटियां बढ़ गई हैं?
- क्या विलंबता बदल गई है?
- क्या उपयोगकर्ता प्रवाह पूरा करते हैं?
- क्या और भी टिकट या पुनः प्रयास हैं?
- क्या एक प्रकार केवल एक खंड को प्रभावित करता है?
OpenFeature ध्वज मूल्यांकन के चारों ओर हुक का समर्थन करता है। वे त्रुटियों को लॉग करने, मेट्रिक्स जोड़ने या रेटिंग को trace से जोड़ने के लिए उपयोगी हैं।
नामकरण और स्वामित्व
नाम मायने रखते हैं. new_ui कुछ नहीं कहता. checkout.v2.enabled और भी बहुत कुछ कहता है.
प्रत्येक झंडे के लिए मैं कम से कम चिन्हित करूंगा:
- नाम;
- विवरण;
- मालिक;
- सुरक्षित डिफ़ॉल्ट;
- इसके अस्तित्व का कारण;
- हटाने की तारीख या शर्त.
स्वामित्व रहित झंडा लगभग हमेशा एक ऐसा झंडा होता है जिसे कोई भी साफ़ नहीं करेगा।
उनका मूल्यांकन कहां करें
फ्रंटएंड, बैकएंड या किनारा? निर्भर करता है.
यदि ध्वज लेआउट, कॉपी या ऑनबोर्डिंग के लिए है, तो फ्रंटेंड ठीक है। यदि यह अनुमतियों, बिलिंग, सीमाओं या संवेदनशील डेटा से संबंधित है, तो यह बैकएंड पर होना चाहिए। यदि इसमें रूटिंग या उच्च-ट्रैफ़िक प्रयोग शामिल हैं, तो बढ़त समझ में आ सकती है।
सरल नियम: फ्रंटएंड अनुभव को बेहतर बना सकता है, लेकिन यह एकमात्र सुरक्षा बाधा नहीं होनी चाहिए।
निष्कर्ष
feature flag ने अच्छी तरह से उत्पादन के साथ संबंध बदल दिया। वे जोखिम को खत्म नहीं करते हैं, लेकिन वे इसे छोटा और अधिक प्रबंधनीय बनाते हैं। आप टुकड़ों में जारी कर सकते हैं, निरीक्षण कर सकते हैं, रुक सकते हैं, वापस जा सकते हैं, सीख सकते हैं।
OpenFeature एक स्वच्छ आधार जोड़ता है: एक सामान्य API, विनिमेय प्रदाता, और सिस्टम को विकसित करने का एक साफ-सुथरा तरीका। लेकिन अनुशासन आपका ही रहता है: सुरक्षित डिफ़ॉल्ट, स्पष्ट नाम, मेट्रिक्स, मालिक और साफ़-सफ़ाई।
सबसे अच्छा झंडा वह है जो आपको शांतिपूर्वक छोड़ने में मदद करता है और फिर गायब हो जाता है जब इसकी आवश्यकता नहीं रह जाती है।