आधी सुविधा लागू करने के लिए मैं सही तरीका कैसे सीखूं? [बन्द है]


12

मैं एक विकास टीम का नेतृत्व करता हूं और मैं अपने उत्पाद को जितनी बार संभव हो (निरंतर वितरण) जारी करना चाहता हूं।

कई मामलों में, हमें एक ऐसी सुविधा को लागू करना होगा जो रिलीज के बीच के समय से लागू होने में अधिक समय लेती है। मैं अब भी चाहता हूं कि लोग अपने कोड को दैनिक आधार पर जारी रखें (कंटीन्यूअस इंटीग्रेशन)।

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

यदि डेवलपर सही दृष्टिकोण का उपयोग करता है , तो वे मौजूदा सुविधाओं को ध्यान से समायोजित कर सकते हैं और उपरोक्त सभी एक समस्या नहीं है।

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

तो यह सवाल है। मैं यह कैसे सुनिश्चित करूँ कि टीम के सदस्य आधी सुविधा लागू करने के लिए सही तरीका सीखें?

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


"मौजूदा विशेषताएं, निश्चित रूप से, अभी भी काम करने की आवश्यकता है" - संदर्भ के आधार पर, इस तरह की आवश्यकता के लिए शब्द पिछड़े संगतता या प्रतिगमन कीड़े की अनुपस्थिति
gnat


1
विभिन्न प्रकार के स्वचालित परीक्षण कोड परिवर्तनों में त्रुटियों के जोखिम को कम कर सकते हैं। चेक। मैं एक डेवलपर के रूप में उपयोग करने के लिए दृष्टिकोण की तलाश कर रहा हूं जिसमें एक बड़ी विशेषता को लागू करना है जिसमें मौजूदा कोड में 75% परिवर्तन और 26% नए कोड (अतिरिक्त प्रतिशत अतिरिक्त रहस्य के लिए) हो सकते हैं।
नील्स ब्रिंच

1
@ नील्स: आपके पास कुछ अद्भुत डेवलपर्स होने चाहिए, जो हर दिन के अंत में मुख्य शाखा में जाँच की जा सकती है और सभी परीक्षणों को पास करने में सक्षम हों। या तो वे या वे केवल नंगे-हड्डियों को न्यूनतम करते हैं, इसलिए वे दिन के अंत तक अपने कोड में जांच करने की स्थिति में होते हैं।
डंक

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

जवाबों:


14

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

हालाँकि, मैं इस बात से सहमत नहीं हूँ कि आज सुबह शिप कोड के अपने अधिकार का विकास हुआ, सिर्फ इसलिए कि हम आज दोपहर को रिलीज कर रहे हैं। जो निराश ग्राहकों के लिए एक नुस्खा है।

इसका उपाय यह है कि आपके संस्करण नियंत्रण वृक्ष में शाखाएँ हों, और आपके पास एक अलग प्रक्रिया है, जिसमें विकसित शाखा से रिलीज़ शाखा तक सत्यापित डेल्टास को बढ़ावा देना है।

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

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

बड़ी विकास टीमों के लिए, या जहाँ आपके उत्पाद के कई 'स्पिन' का समर्थन करने के लिए एक अधिक जटिल शाखाओं में बँधी रणनीति की आवश्यकता होती है, वहीं एक्रेप्रव सबसे अच्छा है। बदलावों के प्रबंधन में शामिल डेवलपर्स शिकायत नहीं करेंगे कि उप-संस्करण आदि की तुलना में यह कठिन है ... लेकिन यह जटिल विकास वातावरण का समर्थन करता है।


आप जिस ब्रांचिंग रणनीति का जिक्र कर रहे हैं, उसके बारे में अधिक जानने के लिए मुझे बहुत दिलचस्पी होगी। क्या आपके पास एक लेख या कुछ और के लिए एक कड़ी है जो उस अवधारणा को अधिक गहराई से समझाती है जिसे आप संदर्भित कर रहे हैं?
नील्स ब्रिंच सिप

2
यहाँ gv प्रवाह के लिए nvie.com/posts/a-successful-git-branching-model है
माइकल शॉ

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

6

यहां दो समस्याएं हैं: एक आधी सुविधा लागू कर रहा है; अन्य शिपिंग उत्पाद को निरंतर विकास के दौरान काम कर रहा है।

आधी सुविधा लागू करना

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

परीक्षण में सुविधा के अन्य भागों के लिए कोड के नकली संस्करण शामिल किए जा सकते हैं; जब आप दूसरी छमाही को लागू करने के लिए जाते हैं तो यह संक्रमण को सुचारू बनाने में मदद करता है।

शिपिंग उत्पाद को काम पर रखना

यहां कुछ विकल्प दिए गए हैं:

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

अंत में, यदि आप इनमें से किसी भी समाधान से परेशान हैं, तो विचार करें कि क्या आपने सही सीमाओं के साथ सुविधा को विभाजित किया है। यदि आप चीजों को अलग तरीके से काटते हैं, तो क्या अलग करना आसान होगा?


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

2
यहीं से अच्छा परीक्षण आता है। यदि आपके पास अपने कोड आधार के लिए सभ्य कवरेज नहीं है, तो शायद यह उस प्रयास के लिए एक ट्रिगर हो सकता है?
एलेक्स फ़ेमैन

लेकिन क्या मेरे सवाल का जवाब बस "अच्छा कोड अभ्यास करना और यूनिट टेस्ट करना" हो सकता है ... आदि?
नील्स ब्रिंच सेप

1

मैं यह कैसे सुनिश्चित करूँ कि टीम के सदस्य आधी सुविधा लागू करने के लिए सही तरीका सीखें?

उन्हें पढ़ाकर। (डुह)

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

एक टीम के रूप में समीक्षाओं को करने से हर किसी को यह जानने में मदद मिलेगी कि आप पहले से ही क्या जानते हैं।


मैं इस पर पूरी तरह से सवार हूं। लेकिन जैसे मैं किसी को यूनिट टेस्ट करना सिखा सकता हूं या उन्हें "यूनिट टेस्टिंग की कला" पुस्तक का संदर्भ दे सकता हूं - क्या ऐसा ही एक संसाधन है जिसे मैं इस विषय के लिए संदर्भित कर सकता हूं?
नील्स ब्रिंच

1

सबसे बड़ी बात जो आपको यहां मदद करेगी, वह चिंताओं का एक अच्छा पृथक्करण है, ताकि जहां तक ​​संभव हो कोड का एक क्षेत्र दूसरे के साथ हस्तक्षेप न करे।

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

वास्तव में इस विन्यास दृष्टिकोण को मार्टिन फॉलर ने फीचर टॉगल के रूप में वर्णित किया है

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


मैं इस धारणा के अधीन हूं कि सभी कोड एक ही शाखा में रखना और हर समय अपने सभी कोड को तैनात करना निरंतर एकीकरण की एक अच्छी रणनीति का हिस्सा है?
नील्स ब्रंच

कंटीन्यूअस डिलीवरी में अधिक पढ़ना, यह निश्चित रूप से उसी का एक हिस्सा है। मुझे लगता है कि के बारे में सोचा पर कुछ हद तक wince, यद्यपि - कि तुम आधा लिखे कोड की तैनाती होने के लिए भले ही यह चाहते हैं चाहिए de-सक्रिय हो? शायद यह ऐसे परिदृश्य में अच्छा काम करता है जहाँ सुरक्षा महत्वपूर्ण नहीं है, लेकिन यह बहुत सारे अनुप्रयोग रिक्त स्थान के लिए उच्च जोखिम वाले दृष्टिकोण की तरह लगता है। यह शायद मुझे एक पुराने जमाने के सुरक्षा-हगिंग फुड्डी के रूप में चिह्नित करता है, हालांकि।
ग्लेनट्रॉन

ऐसा लगता है कि दो प्रतिस्पर्धी रणनीतियाँ हैं, जहाँ एक की मुख्य शाखा होती है और दूसरे की प्रत्येक कार्य के लिए एक शाखा होती है और बहुत सारे विलय होते हैं ... मुझे यकीन नहीं है कि क्या सबसे अच्छा या सही है - या क्या यह मेरे सवालों के मूल को हिट करता है।
Niels Brinch

मुझे लगता है कि आप जिस प्रकार की चीज बना रहे हैं, उस पर बहुत कुछ निर्भर करता है- अगर मैं सुरक्षा पर कोई प्राथमिकता रखता हूं तो मैं शाखाओं के प्रति अधिक इच्छुक होऊंगा और वास्तव में अनकैप्ड कोड को तैनात करने का जोखिम नहीं उठाना चाहता जहां कोई व्यक्ति इसे पा सकता है या यह गलती से हो सकता है। सक्षम होना चाहिए। इसलिए यदि मैं एक बैंक साइट चला रहा था, तो मुझे नहीं लगता कि सीडी की बात होगी, लेकिन शायद अगर मैं आकस्मिक / सामयिक आगंतुकों के लिए एक उच्च-कारोबार वेबसाइट चला रहा था, तो यह आदर्श हो सकता है।
ग्लेनट्रॉन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.