एक उत्पादन शाखा है या मास्टर का उपयोग कर रहे हैं?

Question

मैं एक Railsआवेदन पर अन्य दूरस्थ डेवलपर्स के साथ छोटी टीम पर काम करता हूं । हम अपने gitवर्कफ़्लो को संशोधित करना शुरू कर रहे हैं । हमने नीचे की तरह एक शाखा संरचना के बारे में सोचा है:

(dev) -> (qa) -> (stag) -> (master)

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

(master) -> (qa) -> (stag) -> (prod)

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

एक शाखा संरचना का उपयोग करने के कुछ नुकसान क्या होंगे जहां मास्टर सक्रिय रूप से विकास के लिए उपयोग किया जाता है और एक अलग ठेस शाखा है जो आप तैनाती के लिए उपयोग करते हैं?

Comments

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

— BitTickler

हम इस साइट पर कुछ अंतरों के साथ वर्णित git वर्कफ़्लो का सफलतापूर्वक उपयोग करते हैं। nvie.com/posts/a-successful-git-branching-model फर्क सिर्फ इतना है कि हम एक स्वच्छ हिस्ट्री को मँटेन करने के लिए एक को विकसित करने में स्थानीय शाखा को तरजीह देना पसंद करते हैं और तर्क का पालन करते हैं "एक प्रतिबद्ध, एक मुद्दा

— जेपेसन

आम तौर पर आपकी "हरिण" शाखा पर क्या होता है?

— सिमगिनेर

स्पष्ट सीआई / सीडी के लिए सिफारिश। मास्टर शाखा का उपयोग नहीं किया जाता है क्योंकि यह गलत तरीके से हो सकता है। {विकास} - {इकाई} - {एकीकरण} - {मंचन} - {उत्पादन}। नीले / हरे रंग के उत्पादन में लगातार निर्माण> सक्रिय टुकड़ा, और मचान> निष्क्रिय टुकड़ा। हेड> ऐसी शाखा विकसित करें जहाँ सुविधाएँ बंद हैं। विकसित करने के लिए webhooks ट्रिगर करने के लिए एकीकरण और मचान (गुजर एकीकरण में उपयुक्त टैग के साथ) के लिए इकाई की ओर बनाता है। विकास + उत्पादन की ओर हॉटफ़िक्स (दुर्लभ लेकिन ऐसा होता है)। अधिक जटिल लेकिन एक सामान्य विचार।

— जिमी एमजी लिम

Answer 1

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

यहां वास्तविक परेशानी प्रक्रिया और प्रक्रिया में से एक है। अधिक वरिष्ठ देव जो चिंतित हैं कि इसे एक तरह से करना नए देवों को भ्रमित करेगा कि रिलीज मॉडल क्या है और यह इस तरह क्यों है, यह समझाने के लिए समय का निवेश करने के लिए तैयार रहने की जरूरत है।

जब तक हर कोई समझता है कि मास्टर विकास के लिए है, और कुछ अन्य मनमानी शाखा रिलीज के लिए है, और इसे बनाए रखने के लिए काम किया जाता है , तो इस दृष्टिकोण के साथ कोई समस्या नहीं होनी चाहिए।

Comments

मैं वास्तव में सोचता हूं कि आपने एक अच्छी बात की है। प्रतिक्रिया के लिए धन्यवाद।

टैगिंग के लिए +1 कमिट होता है। मैं ज्यादातर समय खुद से काम करता हूं, लेकिन मैं दो कारणों से रिलीज करता हूं। 1) यह दिखाने के लिए दृश्य गिट इतिहास उपकरण के साथ बहुत अच्छा काम करता है जो वास्तव में उत्पादन में होता है। 2) यह GitHub जैसे टूल के साथ बहुत अच्छा काम करता है, जो टैग किए गए कमिट की जाँच करके और खपत के लिए एक ज़िप फ़ाइल में पैक करके रिलीज़ संस्करण को पैकेज कर सकते हैं।

— 13

Answer 2

मैं आपकी दुविधा देख सकता हूं। मेरे पास यह भी था, जब तक कि मैंने उस चीज़ को अनजान नहीं किया जो मैंने हमेशा मास्टर के बारे में माना था।

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

Git के दस्तावेज / पुस्तक से - Git branching

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

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

(dev) -> (qa) -> (stag) -> (prod)

यहां बताया गया है कि आप मास्टर शाखा का नाम कैसे बदलते हैं ।

मैं यह नहीं कह रहा हूं कि आपको masterशाखा का नाम बदलना होगा । लेकिन अगर आपके पास एक पसंदीदा वर्कफ़्लो है और यह masterशाखा का नाम बदलने में मदद करता है , तो इसे हर तरह से करें :-)

Comments

यह एक बहुत अच्छी बात है। कि ऊपर चमक के लिए धन्यवाद। मुझे नहीं पता कि क्या हम उसका नाम बदलेंगे, लेकिन यह जानना अच्छा है कि git किसी विशेष तरीके से मास्टर का इलाज नहीं करता है। धन्यवाद!

Answer 3

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

यदि आपके पास बाद की कमी है, तो कोड समीक्षा में मदद मिलेगी (अक्सर, अधिक अनुशासित लोग वैसे भी कोड समीक्षा चाहेंगे)।

इसलिए हम अपने Git रेपो (हम Gitlab का उपयोग कर रहे हैं) को कॉन्फ़िगर करते हैं, केवल कुछ लोग ही पुल अनुरोध को मर्ज कर सकते हैं और प्रत्येक डेवलपर को मुख्य रेपो का अपना निजी कांटा मिलता है।

यह दो समस्याओं को हल करता है:

1. नए डेवलपर्स गलत शाखा को बदल नहीं सकते हैं (क्योंकि वे सीधे अपने काम को मुख्य रेपो में नहीं धकेल सकते हैं)। वे masterअपने स्वयं के रेपो पर धक्का दे सकते हैं लेकिन जब पुल अनुरोध आता है तो इसे ठीक किया जाएगा।

2. कोड सम्मेलनों को टीम के माध्यम से जल्दी से फैलता है क्योंकि प्रत्येक कम से कम किसी अन्य व्यक्ति द्वारा जांच की जाती है जो अपना दृष्टिकोण और ज्ञान लाता है।

Answer 4

यह सब समग्र सॉफ्टवेयर विकास प्रक्रिया पर निर्भर करता है। कॉन्फ़िगरेशन प्रबंधन और एक नया संस्करण कैसे आता है इसे समग्र प्रक्रिया के बारे में जाने बिना परिभाषित नहीं किया जा सकता है।

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

वे (मास्टर) -> (विमोचन) को शायद 1,2 मध्यवर्ती चरणों के संगठन के साथ लाभकारी के रूप में देखेंगे।

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

उस क्लासिक दृष्टिकोण का मतलब जरूरी नहीं है कि लंबे समय तक जहां कोई पूर्ण उत्पाद नहीं है उपलब्ध है।

तो "क्लासिक" वर्कफ़्लो होगा: (देव) -> (यूनिट) -> (एकीकरण) -> (परीक्षण / क्यूए) -> (उत्पादन)।

इंटीग्रेटर की भूमिका रिलीज़ की गई इकाइयों को "स्वीकार / खरीदना" है या यदि वे आगामी आगामी रिलीज़ की आवश्यकताओं के अनुरूप नहीं हैं तो उन्हें अस्वीकार कर दें।

यह एक तरफ ध्यान दें, उन 2 बुनियादी तरीकों को भी उपयुक्त तरीके से मिलाना संभव है।

मेरे अनुभव से (जो "क्लासिक" दृष्टिकोण का उपयोग करने के क्षेत्र में था), "क्लासिक" दृष्टिकोण ने एक टीम में लगभग 4-50 लोगों से परियोजनाओं में शालीनता से काम किया।