डेवलपर्स को फीचर फ्लैग टॉगल का उपयोग शुरू करने के लिए कैसे राजी करें?

20

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

डेवलपर्स को (और लागू करने) राजी करने का एक अच्छा तरीका है कि फीचर फ्लैग टॉगल का उपयोग करना शुरू करें?

फ़ीचर फ़्लैग टॉगल के बारे में अधिक जानकारी Q में बताई गई है : फ़ीचर फ़्लैग टॉगल का उपयोग कैसे करें , Q: फ़ीट फ़्लैग टॉगल क्या हैं और मार्टिन फॉवलर के ब्लॉग पर इस विषय पर पीट हॉजसन के लेख में बड़े पैमाने पर हैं ।

culture feature-flags

— एव्जेनी
स्रोत

Devops.stackexchange.com/questions/4/… सवाल के लिए एक संकीर्ण संस्करण ।

— एवगेनी

1

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

— Pierre.Vriens

18

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

जहाँ तक "कायल" डेवलपर्स का उपयोग करने के लिए, यह उस स्वतंत्रता को प्रदान करने के मामले में एक अभ्यास है जो इसे प्रदान करता है। मेरा अनुभव यह है कि यह डेवलपर्स के लिए एक कठिन बिक्री नहीं है। यह प्रबंधन है जो नई चीजों की कोशिश करने के लिए अनिच्छुक है। इसे इस्तेमाल करे:

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

— डेव स्वार्स्की
स्रोत

2

फ्रेमवर्क बिट के लिए +1। मैंने बहुत से लोगों को अपने स्वयं के फ़ीचर टॉगल रोल करते देखा है और यह हमेशा गंदा, गंदा कोड होता है।

— जदुव

फ्रेमवर्क बिट के बारे में, इंटुइट से एक दिलचस्प ओएसएस है जिसे वासाबी गीथुबिनटिनट

— एवगेनी

अन्य डेवलपर्स को राजी करने की पुस्तक की सिफारिश - टेरेंस रयान द्वारा ड्राइविंग तकनीकी परिवर्तन

— Liath

8

एक आदर्श दुनिया में मुझे लगता है कि आप एक नया निर्माण और आश्चर्यचकित करते हैं! कुछ नहीं बदलता है। ऐसा इसलिए है क्योंकि आपकी सभी नई सुविधाएँ स्विच के पीछे हैं जो स्विच ऑफ के साथ बाहर जाती हैं।

पोस्ट-परिनियोजन आप यह सत्यापित करते हैं कि आपकी रोल-आउट सेवा अभी भी काम कर रही है, फोन किसी भी अधिक बज नहीं रहे हैं (जब तक कि फोन बजाना आपका उद्देश्य नहीं है, तब), आदि। एक बार जब आप एक ज्ञात स्थिर ऑपरेशन में वापस आ जाते हैं तो आप सक्षम और सत्यापित करना शुरू करते हैं। अपने नए तैनात सुविधाओं।

अब आपके उत्तर के लिए: आप ऐसी टीम पर कैसे काम करना पसंद करेंगे जहां कॉल पर होना व्यावहारिक रूप से नो-ब्रेनर है और हमारे उपयोगकर्ता हमसे प्यार करते हैं क्योंकि हमारी साइटें और सेवाएं रॉक सॉलिड स्टेबल हैं?

मैं जिस टीम पर काम करना चाहता हूं।

आप चाहें तो यहां पढ़ना बंद कर सकते हैं।

एक फीचर स्विच के पीछे सब कुछ डालने से ऐसा लगता है कि यह हर जगह स्पेगेटी कोड को जन्म दे सकता है। यदि आप IoC का उपयोग करते हैं और vNow / vNext / vPrepret के बीच चयन करने में सक्षम हैं तो यह आपके कॉन्फ़िगरेशन को बनाए रखने के लिए नीचे आता है। हां अधिक चेक इन, हां अधिक कक्षाएं (घटक वी 1, कंपोनेंट वी 2, कंपोनेंट 3, आदि) लेकिन आपके पास वास्तव में अधिक स्थिर प्रणाली है? कैसे? vNext winky है? अपने नियंत्रण टॉवर के साथ vNow पर वापस जाएँ। एक सप्ताह हो गया और vNow में एक सूक्ष्म बग है? एक ही बात - आसानी से vPrepret पर वापस जाएं।

कोई परेशानी नहीं, कोई चिंता नहीं, कोई खोई हुई नींद नहीं, कोई तनाव नहीं।

यह एक पाइप सपना नहीं है। मैं यहाँ काम करता था। काश मैं इसे अपनी वर्तमान टीम को बेच पाता।

— नो रिफंड्स नो रिटर्न
स्रोत

4

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

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

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

— डैन कॉर्निल्स्कु
स्रोत

2

डेवलपर्स (और आमतौर पर विकास प्रबंधक) आमतौर पर ढांचे से जुड़े दो परिणामों की तलाश करते हैं: प्रबंधन में आसानी, और तैनाती की गति। आप कोड को तेज, और आसान बनाना चाहते हैं।

दृष्टिकोण प्रदान करें कि दृष्टिकोण काम करता है; पुराने झंडे बनाम फीचर झंडे का उपयोग करके एक छोटा POC बनाने की कोशिश करें। सामरिक लोगों (मध्य प्रबंधन \ उत्पाद डिजाइनरों) की तुलना में सामरिक लोगों (डेवलपर्स \ इंजीनियरों) के लिए केस अध्ययन कम मायने रखता है।

— स्टुअर्ट आइन्सवर्थ
स्रोत

0

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

— सुधरसन एस
स्रोत

मैं उन संगठनों में रहा हूँ जहाँ डेवलपर्स उत्पाद के मालिक हैं। मैंने कई बार उत्पाद मालिकों की तरह उत्पाद प्रबंधन अधिनियम देखा है। और मैं ऐसी जगहें हूँ जहाँ किसी को कुछ भी अपना नहीं लगता। तो आपका कथन मेरे अनुभव का लगभग एक तिहाई है। डेवलपर्स को चीजों को इस तरह से लिखने के लिए प्रोत्साहित करना जो उत्पादन में बेहतर काम करेगा, ऐसा लगता है कि आम तौर पर मेरे लिए अच्छी बात है। क्या आप अपने विचार का समर्थन करने के लिए किसी अधिकारियों का हवाला दे सकते हैं?

— लड़कियों