फ़ीचर टॉगल: दृश्य, लाभ और उनके साथ .NET में काम करें

फ़ंक्शनलिटी स्विच एक ऐसा उपकरण है जो आपको पुराने फ़ंक्शंस से नए को स्विच करने की अनुमति देता है, बिना एप्लिकेशन को फिर से बनाए और इसे फिर से जारी किए। यह एक सशर्त ऑपरेटर ( if ) को कोड में जोड़कर कार्यान्वित किया जाता है, जो कॉन्फ़िगरेशन फ़ाइल या डेटाबेस में वांछित मूल्य को बदलकर कार्यक्रम के व्यवहार को नियंत्रित करना संभव बनाता है। यदि आपने कभी एक आईएनआई-फ़ाइल में सेटिंग्स को संपादित किया है, तो आप इस तकनीक से परिचित हैं।

गहरी खुदाई, आप स्विच और नई सुविधाओं के लिए विभिन्न विकल्पों की एक बड़ी संख्या पा सकते हैं जो वे प्रदान करते हैं। इससे कई सवाल खड़े होते हैं। कॉन्फ़िगरेशन कहाँ रखें? लेकिन अगर यह अनुपलब्ध हो जाए तो क्या होगा? शायद आप स्वयं स्विच के साथ काम करने के लिए एक सरल रूपरेखा लिख ​​सकते हैं? शायद एक तैयार समाधान लेना बेहतर है? क्या यह मोनोलिथ और माइक्रोसर्विसेज दोनों को सूट करता है?

इस सामग्री में .NET प्लेटफ़ॉर्म पर विकास के संदर्भ में कार्यक्षमता स्विच के बारे में बुनियादी जानकारी है। पहले भाग में स्विच के बारे में सामान्य जानकारी है; वे विशिष्ट कार्यान्वयन से काफी स्वतंत्र हैं और विभिन्न प्लेटफार्मों के साथ काम करने वाले पेशेवरों के लिए उपयोगी हो सकते हैं। दूसरा भाग विशिष्ट आधुनिक उपकरणों की चर्चा करता है जो .NET के लिए विकसित होने पर स्विच के उपयोग की सुविधा प्रदान करते हैं।

मैंने एक लेख लिखने की कोशिश की जो आपको यह तय करने में मदद करेगा कि क्या आपके विशिष्ट मामले में कार्यक्षमता स्विच लागू करना है, और यदि आवश्यक हो, तो कैसे। हमारे विभाग में, स्विच अभी तक केवल विशेष समस्याओं को हल करने के लिए उपयोग किए जाते हैं। उदाहरण के लिए, हमारे आवेदन को अक्सर एक कैटलॉग से कानूनी और लेखा जानकारी का अनुरोध करने की आवश्यकता होती है, जिसे दो रूपों में प्रस्तुत किया जा सकता है: एक दूरस्थ पूर्ण कैटलॉग और इसकी स्थानीय आंशिक प्रतिलिपि। एप्लिकेशन सेटिंग में, उपयोगकर्ता यह चुन सकते हैं कि एप्लिकेशन को किस प्रकार की निर्देशिका में इस समय काम करना चाहिए। योजनाओं में पूरी परियोजना के लिए एक सामान्य बुनियादी ढांचे के रूप में स्विच की शुरूआत शामिल है। इसके आधार पर, ऊपर वर्णित लोगों के समान प्रक्रियाएं बनाई जाएंगी।

फ़ंक्शनलिटी स्विच अवलोकन

यह क्या है

सरल शब्दों में, स्विच का अर्थ इस प्रकार है। ठेकेदार हमारे कोड के माध्यम से आगे बढ़ता है, विषय क्षेत्र के तर्क का प्रतिनिधित्व करता है, और एक सशर्त विवरण पर ठोकर खाता है। इस कथन में, ठेकेदार पूछता है कि क्या कुछ सशर्त कोड को कुछ रजिस्ट्री से निष्पादित करने की आवश्यकता है जो यह जानता है कि ब्याज की कार्यक्षमता कब और किन परिस्थितियों में काम करनी चाहिए।


नतीजतन, निष्पादक या तो एक शाखा के साथ या दूसरे के साथ जाता है, और एक पतित मामले में दूसरी शाखा बस खाली होती है। सबसे सरल स्थिति में, रजिस्ट्री को बनाए रखने वाले जिम्मेदार व्यक्ति के नियंत्रण में स्विच दो मूल्यों ("चालू" और "बंद") में से एक लेता है। और आप कुछ अधिक जटिल के साथ आ सकते हैं, उदाहरण के लिए, केवल विशिष्ट उपयोगकर्ताओं के लिए या कुछ देशों के उपयोगकर्ताओं के लिए या एक निश्चित समय पर कार्यक्षमता शामिल करें।

कार्यक्षमता रजिस्ट्री कई प्रकार के रूप ले सकती है। मुद्दा यह है कि जब आप इस रजिस्ट्री को एप्लिकेशन को रोक कर या इसे फिर से पढ़े बिना प्रबंधित कर सकते हैं। उदाहरण के लिए, स्विच को फ़ाइल में, डेटाबेस में संग्रहीत किया जा सकता है, या स्विच के साथ एक अलग नेटवर्क सेवा हो सकती है। स्विच के संचालन के नीचे अधिक विस्तार से माना जाता है।

क्या यह भी प्रासंगिक है?

अपने लेख में, फीचरफ्लैग.टेक के निर्माता का दावा है कि स्विच सॉफ्टवेयर विकास में मानक अभ्यास बन जाते हैं। स्विच के बारे में अधिक से अधिक सामग्री हैं: सैद्धांतिक लेख, स्विच को लागू करने के अभ्यास के बारे में कहानियां, सम्मेलनों में रिपोर्ट। मैंने इस लेख के पाठ में सबसे दिलचस्प सामग्रियों के लिंक शामिल किए हैं; सभी लिंक "निष्कर्ष" अनुभाग में एकत्र किए गए हैं।

मैं कहूंगा कि सूचना प्रौद्योगिकी के कुछ क्षेत्रों में स्थिरीकरण और मानकीकरण द्वारा स्विचेस की लोकप्रियता में वृद्धि हुई है। "खूनी उद्यम" में स्थिरता के अधिक से अधिक द्वीप दिखाई देते हैं। विकास में मैट्रिक्स की संख्या में वृद्धि, असेंबली के स्वचालन, निरीक्षण और एप्लिकेशन के वितरण से इस तथ्य की ओर बढ़ जाता है कि विकास प्रक्रियाएं अधिक पारदर्शी और प्रबंधनीय हो जाती हैं। परिणामस्वरूप, सॉफ्टवेयर के निर्माण के लिए एक नए स्तर की आवश्यकताएं प्रस्तुत की जाने लगी हैं। इन आवश्यकताओं में से एक आवेदन के प्रकाशन के क्षणों और नई कार्यक्षमता को शामिल करने के क्षणों में फैलने की इच्छा है, जो स्विच द्वारा कार्यान्वित की जाती है। इस औद्योगिक माँग को पूरा करने के लिए उद्योग की क्षमताएं पहले ही परिपक्व हो चुकी हैं।

उन उपकरणों के लिए जो स्विच के साथ काम करने में मदद करते हैं, उनमें से बहुत, बहुत सारे हैं, और विभिन्न प्लेटफार्मों के लिए। संभवतः, बड़ी संख्या में उपकरणों की उपस्थिति को सरलता द्वारा समझाया गया है जिसके साथ आप स्विच की बुनियादी क्षमताओं को लागू कर सकते हैं। लेकिन अधिक जटिल और "स्वादिष्ट" बन्स के अतिरिक्त के लिए महत्वपूर्ण श्रम लागत की आवश्यकता हो सकती है, इसलिए कार्यक्षमता स्विच को लागू करने वाले कई खुले स्रोत परियोजनाएं विकसित होने और समर्थित होने से रोकती हैं। फिर भी, एक महत्वपूर्ण संख्या में परियोजनाएं, दोनों का भुगतान और मुफ्त, बचा हुआ है। उनमें से सबसे दिलचस्प (.NET के दृष्टिकोण से) लेख के दूसरे भाग में वर्णित हैं।

थोड़ा और

इस लेख में स्विच के संचालन को दर्शाने वाला एक अच्छा आरेख है; मैं आपको इससे परिचित होने के लिए आमंत्रित करता हूं।


हम कोड के साथ सर्किट पर अपना विचार शुरू करते हैं। हमारे उदाहरण में एक नई कार्यक्षमता दें - दस्तावेज़ को भरने की शुद्धता की जांच करना। हम यह सुनिश्चित करते हैं कि यह कार्यक्षमता सक्षम होने पर ही दस्तावेज़ की जाँच की जाए। चलो एक स्विचिंग पॉइंट बनाते हैं:

 var document = GetDocument(); if (feature.IsEnabled("Feature #123. Document validation")) { Validate(document); } 

इस मामले में, feature बुनियादी ढांचे का एक संदर्भ है जो हमारे एप्लिकेशन को राउटर और कार्यक्षमता रजिस्ट्री के साथ संवाद करने में मदद करता है। इस बुनियादी ढांचे का उपयोग करते हुए, हमें पता चलता है कि क्या दस्तावेज की जांच करना आवश्यक है, और यदि ऐसा है, तो इसकी जांच करें।

राउटर इसके लिए उपलब्ध जानकारी का उपयोग करता है: कार्यक्षमता का नाम जिसे हम एक तर्क के रूप में पारित करते हैं, और हम उन स्थिर वर्गों से क्या निकाल सकते हैं जो यह निर्धारित करने के लिए जानते हैं कि क्या अनुरोधित कार्यक्षमता को इस मामले में काम करना चाहिए। राउटर को पता चलता है कि रजिस्ट्री में स्विच कैसे कॉन्फ़िगर किए गए हैं। यदि रजिस्ट्री अनुपलब्ध है, तो आपको पहले से कैश्ड डेटा का उपयोग करना चाहिए, या इस मामले के लिए कुछ अन्य रणनीति का सहारा लेना चाहिए। आप एक राउटर की भी कल्पना कर सकते हैं जो स्पष्ट रूप से अतिरिक्त जानकारी (संदर्भ) प्राप्त करता है, इस पद्धति के तर्कों के माध्यम से जो यह तय करने में मदद करता है कि फिलहाल कार्यक्षमता को सक्षम करना है या नहीं।

जिम्मेदार कर्मचारी चयनित तरीके से स्विच को कॉन्फ़िगर करते हैं। सबसे सुखद विकल्प में, वे उस साइट पर जाते हैं जो स्विच की रजिस्ट्री का प्रतिनिधित्व करता है, और माउस के साथ चयनित स्विच पर क्लिक करें।

तो, कलाकृतियों के अर्थ में, स्विच सिस्टम में दो भाग होते हैं। एक तरफ, यह प्रोग्रामर के लिए यह पता लगाने के लिए एक बुनियादी ढांचा है कि कार्यक्षमता इस मामले में काम करना चाहिए और उचित कोड शाखा के साथ प्रत्यक्ष निष्पादन। दूसरी ओर, यह एक ऐसा तंत्र है जो एक जिम्मेदार कर्मचारी को सक्षम करने के लिए कि कौन सी कार्यक्षमता को चुनना है और कौन सा बंद करना है। पतित मामलों में (जब रजिस्ट्री को कोड में सीवन किया जाता है, तो नीचे देखें), दोनों कलाकृतियों को मेल कर सकते हैं, और प्रोग्रामर चालू और बंद कार्यक्षमता को नियंत्रित कर सकता है।

संभव स्विच सिस्टम आवश्यकताओं

जैसा कि आप देख सकते हैं, स्विच सिस्टम काफी जटिल चीज हो सकती है। हम उन मूलभूत आवश्यकताओं को सूचीबद्ध करते हैं जो इस तरह की प्रणाली पर लगाए जा सकते हैं।

1. विभिन्न मापदंडों की कार्यशीलता पर निर्भरता। मापदंडों के उदाहरण: उपयोगकर्ता (भूमिका, पहचानकर्ता, भौगोलिक स्थिति), समय (दिन के उजाले या अंधेरे, काम या सप्ताह के दिनों, विशिष्ट समय अवधि), पर्यावरण (विकास, परीक्षण, औद्योगिक संचालन के लिए)।
2. डोमेन प्रक्रियाओं का विश्लेषण करते समय उपयोग के आंकड़ों का संग्रह: किस उपयोगकर्ता ने किन परिस्थितियों में कार्यक्षमता देखी या नहीं देखी, कितनी बार उन्होंने नई कार्यक्षमता का उपयोग किया।
3. स्विचेस के साथ क्या हो रहा है, इसका एक ऑडिट: कौन उन्हें दबाता है, कब, क्या बदलता है।
4. स्थानीय और दूरस्थ रजिस्ट्री कार्यक्षमता या दूरस्थ रजिस्ट्री अनुपलब्ध होने की स्थिति में कुछ रणनीतियों के बीच एक लचीला विकल्प प्रदान करना।
5. ग्राहक और ठेकेदार दोनों में विभिन्न श्रेणियों के कर्मचारियों के लिए स्विच सिस्टम तक पहुंच को कॉन्फ़िगर करना: तकनीकी विशेषज्ञ, विषय क्षेत्र के विशेषज्ञ, साथ ही साथ अनुप्रयोग उपयोगकर्ता स्वयं।

बेशक, इन सभी आवश्यकताओं को पूरा करने के लिए प्रयास करना आवश्यक नहीं है। कई मामलों में, कुछ आवश्यकताएं, इसके विपरीत, अवांछनीय हो सकती हैं। जितनी अधिक आवश्यकताओं का आपको पालन करना होगा, जाहिर है अधिक बोझ आपके अपने स्विच सिस्टम का विकास है। इसका मतलब यह है कि स्विच की शुरुआत के बाद कुछ बिंदु पर, आपके स्वयं के सिस्टम का समर्थन लाभहीन हो जाता है और यह तैयार-किए गए समाधान लेने का समय है।

तकनीकी पेड़

हम वीडियो गेम से तकनीकी पेड़ के रूपक का सहारा लेते हुए कार्यक्षमता स्विच के बारे में विचार करते हैं। चलो एक प्रौद्योगिकी के रूप में स्विच की कल्पना करते हैं जो कंपनी को विधानसभा के क्षणों और एप्लिकेशन की तैनाती से बंधे बिना नई कार्यक्षमता को रोल आउट करने की अनुमति देता है। इस तकनीक की एक ज्ञात लागत (स्विचेस और रजिस्ट्री के जीवन चक्र को बनाए रखने की लागत) और कार्यान्वयन के लिए आवश्यक शर्तें हैं: एक लचीला विकास पद्धति और निरंतर एकीकरण। बेशक, निरंतर एकीकरण एक पूर्वापेक्षा नहीं है, लेकिन यह स्विच को बहुत अधिक कुशल बनाता है और एप्लिकेशन के निरंतर वितरण की अनुमति देता है। इसके अलावा, स्विच के "अनुसंधान" अन्य तकनीकों को खोलता है - ए / बी परीक्षण और कैनरी रिलीज। नीचे उनकी चर्चा की जाएगी।

जहाँ कार्यक्षमता रजिस्ट्री स्थित हो सकती है

कार्यक्षमता की रजिस्ट्री को बढ़ाने, कार्यान्वयन की बढ़ती जटिलता में रखने के लिए कई विकल्पों पर विचार करें।

1. कोड में सीधे कॉन्फ़िगरेशन सीवे करें, उदाहरण के लिए, अनावश्यक कोड पर टिप्पणी करें और आवश्यक कोड को अनसुना करें या सशर्त संकलन निर्देशों का उपयोग करें। जाहिर है, यह विकल्प स्विच की शुरूआत के सार को मारता है, क्योंकि इसके साथ आपको नई कार्यक्षमता को देखने के लिए एप्लिकेशन को फिर से संकलित करने और तैनात करने की आवश्यकता होगी। दो कठिनाइयों पर भी ध्यान दिया जाना चाहिए। सबसे पहले, इस दृष्टिकोण के साथ, एक कर्मचारी जिसमें कार्यक्षमता शामिल है, को अतिरिक्त तकनीकी कौशल की आवश्यकता होगी: स्रोत कोड को संपादित करना और संस्करण नियंत्रण प्रणाली (एसएलई) के साथ काम करने की क्षमता। भगवान जानते हैं कि क्या कौशल है, लेकिन सबसे अधिक संभावना है, प्रोग्रामर को स्वयं कार्यक्षमता को शामिल करना होगा। दूसरे, कार्यक्षमता सभी नोड्स पर समान होगी जहां एप्लिकेशन के इस संस्करण को प्रकाशित किया गया था - पुरानी और नई कार्यक्षमता के बीच चयन करने के लिए, आपको एप्लिकेशन के साथ एक बैलेंसर और कई नोड्स की आवश्यकता होगी।
2. कॉन्फ़िगरेशन को एप्लिकेशन वातावरण में रखें, उदाहरण के लिए, पर्यावरण चर में। यह विकल्प थोड़ा असाधारण लगता है, क्योंकि यह रनटाइम या ऑपरेटिंग सिस्टम पर अत्यधिक निर्भरता की उपस्थिति से भरा हुआ है।
3. कॉन्फ़िगरेशन फ़ाइलों का उपयोग करें, जो अनुप्रयोग सेटिंग्स को संग्रहीत करने के लिए एक काफी मानक स्थान हैं। इस विकल्प का नुकसान आवेदन के प्रत्येक उदाहरण के बगल में कॉन्फ़िगरेशन फ़ाइलों को अलग से बनाए रखने की आवश्यकता होगी। यह कमी पिछले संस्करण में अंतर्निहित है।
4. डेटाबेस में एक तालिका बनाए रखें जो कार्यक्षमता के लिए स्विच का वर्णन करती है। एप्लिकेशन इंस्टेंसेस इस डेटाबेस पर यह देखने के लिए दस्तक देंगे कि क्या कार्यक्षमता है कि उनकी रुचि काम करती है। इस विकल्प में, रजिस्ट्री को केंद्रीकृत किया गया है (पिछले संस्करण के विपरीत), लेकिन प्रत्येक नोड के लिए अलग से कार्यक्षमता शामिल करना संभव बनाता है, यदि यह चयनित स्विच इंफ्रास्ट्रक्चर द्वारा समर्थित है।
5. उस नेटवर्क सेवा को उठाएं जिसके लिए एप्लिकेशन इंस्टेंस चयनित नेटवर्क प्रोटोकॉल के माध्यम से पहुंचेगा। यदि पिछले संस्करण में यह मतलब था कि स्विच सबसे अधिक संभावना के साथ विषय क्षेत्र की संस्थाओं के साथ संग्रहीत किया जाएगा, और इसलिए स्विच को मतदान करने की लागत पूर्वानुमान योग्य होगी, तो यहां हमारे पास नेटवर्क पर अतिरिक्त पहुंच होगी। अतिरिक्त हैंडलिंग की लागत और सेवा से इनकार करने की संभावना इस विकल्प की गंभीर कमियां हैं, लेकिन निश्चित रूप से, कैशिंग निषिद्ध नहीं है। और विफलताओं के लिए, आपको डिफ़ॉल्ट व्यवहार प्रदान करना होगा।

सिफारिशें

स्विच के उपयोग के संबंध में, निम्नलिखित सामान्य सिफारिशें की जा सकती हैं।

स्विचिंग पॉइंट और लॉजिक को एक साथ होना जरूरी नहीं है । सबसे सरल उदाहरण में, सशर्त विवरण के बाद, जिसमें हम एक विशिष्ट स्विच की स्थिति पर पूछताछ करते हैं, कोड तुरंत शामिल कार्यक्षमता को लागू करता है। यह बहुत सुविधाजनक नहीं है, क्योंकि यह तर्क के लिए अनावश्यक निर्भरता को जोड़ता है: स्विच के बुनियादी ढांचे और रजिस्ट्री से किसी विशेष कार्यक्षमता के नाम के बारे में ज्ञान। व्यवहार में, यह स्विच के परीक्षण और हटाने की प्रक्रिया को जटिल बनाता है जब यह अनावश्यक हो जाता है।

स्विचिंग पॉइंट अधिक सेट करें । पिछले पैराग्राफ का विकास। जिन बिंदुओं पर स्विच के बुनियादी ढांचे तक पहुंच है, उन्हें विषय क्षेत्र के तर्क से अंतिम संभावित अवसर तक बाहर रखा जाना चाहिए, अर्थात्, उन्हें उस स्थान के करीब "धक्का" दिया जाना चाहिए जहां अनुरोध प्राप्त हुआ था। इस प्रकार, हम स्विच पर व्यक्तिगत मॉड्यूल की निर्भरता को कम करते हैं, उनके समर्थन और परीक्षण की प्रक्रियाओं को सरल करते हैं।

सशर्त बयानों के बजाय रणनीतियों का उपयोग करें । यदि स्विच लंबे समय तक रहने वाला है, तो सशर्त ऑपरेटर को एक रणनीति में सुधार किया जा सकता है और स्विचेबल लॉजिक को स्पष्ट रूप से अलग-अलग अनुसरण और परीक्षण में अलग किया जा सकता है।

समूह स्विच न करें । आपको स्विच के बीच निर्भरता नहीं बनानी चाहिए, उन्हें समूहित करना चाहिए और उन्हें पदानुक्रम में इकट्ठा करना चाहिए। इससे नई कार्यक्षमता और स्वयं स्विच के जीवन चक्र के साथ कोड बनाए रखना आसान हो जाएगा।

एक कार्यक्षमता के लिए स्विच अंक समेकित करें । यह पता चल सकता है कि एक ही बार में कई प्रोग्राम ब्लॉक का व्यवहार एक ही स्विच पर निर्भर करता है। यदि विकास खराब रूप से समन्वित है, तो स्विचिंग पॉइंट्स को अलग-अलग जगहों पर डुप्लिकेट किया जा सकता है, और यह अधिक महंगी परीक्षण और समर्थन की ओर जाता है। यदि आपको एप्लिकेशन में प्रवेश करने के लिए स्विचिंग पॉइंट्स को "पुश" करने की कोशिश करने के लिए अनुशासित किया जाता है, तो यह सिफारिश - पूरे सिस्टम में पॉइंट्स को बिखेरना नहीं है - आमतौर पर स्वचालित रूप से प्रदर्शन किया जाता है।

स्विच की मुख्य श्रेणियां

इस आलेख में दिए गए स्विच वर्गीकरण पर विचार करें । यह इस बात पर आधारित है कि स्विच कब तक "रहता है" और कितनी बार इसकी स्थिति बदलती है। एक विशिष्ट वर्ग के लिए स्विच का असाइनमेंट यह निर्धारित करने में मदद करता है कि कोड में स्विच का उपयोग कैसे करें और स्विच की स्थिति को कैसे संग्रहीत करें।

रिलीज़ स्विच

यह स्विच का मुख्य दृश्य है। वे आपको एक मुख्य शाखा में विकास को केंद्रित करने की अनुमति देते हैं, जो, इसके अलावा, नियमित रूप से वाणिज्यिक संचालन में रोल आउट करता है। एक अलग शाखा में विकसित होने और वांछित संस्करण को जारी करने के लिए इसे मुख्य शाखा में इंजेक्ट करने के बजाय, हम कोड में एक स्विचिंग पॉइंट पेश करते हैं, जो उन कार्यक्षमता को छुपाता है जो अभी तक उपयोगकर्ताओं से तैयार नहीं है। तैयार होने पर, स्विच नई कार्यक्षमता का शुभारंभ करते हैं।

इस तरह के स्विच कई दिनों या हफ्तों तक रहते हैं - जबकि नई कार्यक्षमता का विकास और कार्यान्वयन जारी है। जब कार्यक्षमता का परीक्षण किया गया है और उपयुक्त माना गया है, तो कोड में स्विच और स्विचिंग पॉइंट को हटाया जा सकता है। स्विच की स्थिति आमतौर पर तब बदलती है जब कोई नया संस्करण जारी होता है, या जब एप्लिकेशन कॉन्फ़िगरेशन बदलता है। कॉन्फ़िगरेशन फ़ाइल में इस तरह के स्विच को स्टोर करने की अनुमति है। एक उच्च संभावना है कि नई कार्यक्षमता के लिए स्विच बिंदु केवल एक ही होगा; यह समझ में नहीं आता है कि यह एक पारंपरिक सशर्त बयान के रूप में खुदाई और जगह नहीं है।

प्रयोग स्विच

नई कार्यक्षमता में चलाने के लिए, स्विच का उपयोग किया जाता है जो कई दिनों से कई महीनों तक रहते हैं। प्रयोग के दौरान, आप यह देख सकते हैं कि उपयोगकर्ता परिवर्तनों को कैसे देखते हैं और उनका व्यवहार कैसे बदलता है। यह वांछनीय है कि स्विच की स्थिति प्रत्येक अनुरोध के साथ बहुत गतिशील रूप से बदल सकती है। कुछ केंद्रीकृत भंडारण, जैसे कि डेटाबेस या नेटवर्क सेवा, यहां उपयुक्त होने की अधिक संभावना है। , .



, . , , . «», , , .

, , . , , , . , .



— . ( ), , .

, (, , ) . . - .

,

, ( , ), . .

A/B-. , .

. , .

- . , .

. , .

. , . .

. , .

. , .

A/B-

, A/B-. A/B- - . : 1) , 2) , , 3) , . , , . ? ? «»?

, A/B-, , — . , , - - . , . , , - , .

. , . , A/B-. .

, «», «Feature Toggles, » , A/B- .

-

? : , , . . , , , . ( ).

, , « ». , (. . ), , , , , , . , , , : « ». -, , , . , .

. : - , «» — , - , ( «»). . . , , . , — , . , .

, . . : , 1 %. , , , , , , . , . , .

- , . , . , . , , .

- , , , . , . .

, - . - , , . , , , .

- — «», . - — . - .



, , , : , , , , . . , , , , , , , .

, , . , , . , ( ), .

. , () . , , — . : , !

- , . , . , . ( ) , .




«Feature Toggles, » ( !) , . .

, . , - ( , ), , . — , . , , API «» . , , — .

, . , . , « ».

. , .

.NET

. -, (), , , , , . ( ). -, , , REST API. ( ) , API .NET. -, ( ) .NET. , .

, , . , . Apache ZooKeeper , Consul etcd , Spring Cloud Config Server, .NET . , , . - , , . .

LaunchDarkly

, «» . , , , . , , Jira Visual Studio Code. . , , , 30- .

Catamorphic Co., , - .

Microsoft.FeatureManagement

Microsoft .NET Core, : -, , , -, , Azure. , , Azure App Configuration, API .

ASP.NET Core, , .

, Microsoft.FeatureManagement.

Rollout

, . , , , . ( , 14- ) REST API. , , . .

Optimizely

Optimizely — - . Rollouts , . , , («» ), . , . , . — .

Bullet train

. - — . .

Split

, . «» (A/B-).

ConfigCat

, . . , REST API. .NET . , .

Moggles

, . SQL Server. .

Unleash

, . . . ; PostgreSQL.

.NET , . , API, , .

GitLab feature flags

GitLab Unleash, GitLab , Unleash. Unleash , ( GitLab), : GitLab Premium ( GitLab ) GitLab Silver ( GitLab ).

Feature flags API in Go

API ( ), . , . Go; , , , . . : 20 2019.

Bandiera

. API . Ruby; MySQL PostgreSQL, Docker. Ruby, Node, Scala, PHP, .NET. .

Flagr

Go. Docker. , Ruby, Go, JavaScript, Python. . .

.NET , . . , 2019 . . .

Esquio

, . — , EF Core. ASP.NET Core ( Microsoft.FeatureManagement); , Azure .

FeatureSwitch

, ( FeatureSwitch.Strategies ). , . , , «/».

Toggle.Net

, . , «/».

RimDev.FeatureFlags

ASP.NET Core. , , , . — SQL Server.

निष्कर्ष

, . . , , A/B-.

, , , .

( ) .

1. , — , , .
2. , . , .
3. , . , , , , .
4. , . . , «» .
5. , . , . , .

1. . , . : , . , , .
2. . , , . : , , , , . : ( ), .
3. . ? , ? . , , . ? ? : , .
4. — , . , . : (); ( ); .
5. — , . : (); «/».
6. , . : ; (, ).
7. . , ? : , , , ( ).