टॉगल करने की सुविधा क्या है या कैसे वाष्पशील और लंबे समय से चली आ रही शाखाओं से छुटकारा पाने के लिए?

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

समस्या

कल्पना करें कि आपकी टीम के विकास चक्र दो सप्ताह तक चलते हैं, और एक नई सुविधा के कार्यान्वयन के लिए टीम को 3 महीने के विकास की आवश्यकता होगी। पहली नज़र में, कार्रवाई की दो संभावित योजनाएँ हैं:

• एक अलग शाखा बनाएं और तीन महीने के लिए इसमें सभी काम करें, समय-समय पर मूल शाखा से खींच कर करें
  
• निरंतर एकीकरण की अवधारणा का उपयोग करें ( संक्षेप के लिए सतत एकीकरण): कार्य को विघटित करें और छोटे भागों में कोड को फ्रीज करें
  

इन दोनों दृष्टिकोणों के अपने स्पष्ट फायदे और नुकसान हैं:

समस्याओं को हल करने के लिए सुविधा स्विचर का उपयोग करना

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

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

निम्नलिखित जावा में फ़ीचर टॉगल का उपयोग करने का एक उदाहरण है:

if (configurationManager.getParameter("is.some.functionality.enabled")) { // do some stuff } else { // do default logic } 

ऊपर दिए गए उदाहरण में, configurationManager एक ऐसा वर्ग है जो आपको डेटाबेस से एक विशिष्ट सुविधा स्विचर के मान को इसकी कुंजी द्वारा पुनः प्राप्त करने की अनुमति देता है।

इसके अलावा, फीचर स्विचर्स की मदद से, आप फ्रंटेंड पर कुछ तत्वों को प्रदर्शित / छिपा सकते हैं। ऐसा करने के लिए, आपको ध्वज को मॉडल में रखने की आवश्यकता है और इसे नीचे दिखाए गए अनुसार देखें:

 @ModelAttribute("isSomeFunctionalityEnabled") public void isSomeFunctionalityEnabled() { return configurationManager.getParameter("is.some.functionality.enabled"); } 

फिर इस या उस HTML कोड को प्रस्तुत करने के लिए पारित मूल्य का उपयोग करें:

 <c:choose> <c:when test="${isSomeFunctionalityEnabled}"> <!-- Render some stuff --> </c:when> <c:otherwise> <!-- Render some other stuff --> </c:otherwise> </c:choose> 

फ़ीचर स्विचर्स के प्रकार

फीचर स्विचर का उपयोग करने की वर्णित अवधारणा सिर्फ एक संभव उपयोग का मामला है और ऐसे फीचर स्विचर्स को रिलीज टॉगल कहा जाता है। कुल मिलाकर, 3 अलग-अलग प्रकार के फ़ीचर स्विचर प्रतिष्ठित हैं:

• रिलीज टॉगल - आप उनके विकास के दौरान अपूर्ण रूप से कार्यान्वित सुविधाओं को छिपाने की अनुमति देते हैं
• प्रयोग टॉगल - ए / बी परीक्षण के लिए स्विच
• अनुमति देने वाले टॉगल - विभिन्न उपयोगकर्ता समूहों के लिए स्विच ऑन / फ़ीचर

इस प्रकार, फीचर स्विचर का उपयोग करके, आप अलग-अलग डेटाबेस और फीचर स्विचर्स के अलग-अलग सेट का उपयोग करके एक ही कोड बेस पर साइट के दो अलग-अलग संस्करण बना सकते हैं। उदाहरण के लिए, एक यूरोपीय साइट पर यह GDPR से संबंधित सभी विशेषताओं को शामिल करने के लिए समझ में आता है, लेकिन एक रूसी पर आप ऐसा नहीं कर सकते।

फ़ीचर टॉगल का उपयोग कर समस्याएं

चूंकि मैं एक ऐसी परियोजना पर काम करता हूं जहां फ़ीचर टॉगल सक्रिय रूप से उपयोग किए जाते हैं, उनके उपयोग के स्पष्ट लाभों के अलावा, मैंने उनसे जुड़ी समस्याओं को नोटिस करना शुरू किया:

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

वर्णित कुछ समस्याओं का समाधान

निम्नलिखित क्रियाएं उपरोक्त समस्याओं को हल करने में मदद कर सकती हैं:

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

परिणाम

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

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

उपयोगी लिंक

• मार्टिन फाउलर का ब्लॉग
• पीट हॉजसन का लेख
• जहां बिना विकिपीडिया के