एक एकल शाखा मॉडल के लिए एक जटिल शाखा वास्तविकता से संक्रमण कैसे करें?

Question

बड़े संगठनों में, जलप्रपात कार्यप्रणाली का उपयोग आम तौर पर बहुत जटिल शाखाओं वाली संरचनाओं (उर्फ शाखा स्पेगेटी ) में होता है।

ट्रंक-आधारित विकास जैसे एकल-शाखा मॉडल के लिए एक जटिल शाखा वास्तविकता से संक्रमण के लिए क्या ब्रांचिंग रणनीतियों का उपयोग किया जा सकता है?

अपडेट करें:

स्पष्ट करने के लिए, सवाल प्रवास / संक्रमण के बारे में है , न कि पहले और बाद के तरीकों के बारे में, जो बहुत स्पष्ट हैं।

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

Comments

आप झरना हो सकते हैं और स्पष्ट रूप से परिभाषित और शाखाओं में बँधी प्रथाओं को लागू कर सकते हैं या फुर्तीले हो सकते हैं और एक गजिलियन शाखाएँ (फ्री-फॉर-ऑल!) हैं। एक दूसरे को इम्प्रेस नहीं करता।

— अलेक्जेंड्रे

@Alexandre प्रश्न निकाय संदर्भ को स्पष्ट करता है: कई शाखाओं से एक में संक्रमण।

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

आपने मूल से प्रश्न को पूरी तरह से बदल दिया ... उत्तर के आधे को अप्रासंगिक बना दिया।

— इवगेनी

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

— दान कॉर्निलेस्कु

हाय @DanCornilescu मैंने एवगेनी टिप्पणी के बाद अपना संपादन किया, इसलिए इसे मेरे बारे में बताने की कोशिश न करें;) आपके मूल प्रश्न में सॉफ्टवेयर विकास प्रक्रिया, शाखा मॉडल और देवओप्स प्रथाओं के बारे में तत्व थे। लोगों ने उन सवालों के जवाब दिए जो उन्होंने सोचा था कि सवाल के बारे में था। आपने तब अपना प्रश्न संशोधित किया (# 2 संपादित करें: devops.stackexchange.com/revisions/122/2 ) और उनमें से कुछ उत्तरों को अप्रासंगिक बना दिया।

— अलेक्जेंड्रे

Answer 1

क्योंकि आप झरने का उल्लेख करते हैं, मैं समझता हूं कि आप जिन शाखाओं को देख रहे हैं, वे रखरखाव-शाखाओं के बजाय सुविधा-शाखाएँ हैं।

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

इसलिए, पहले चरण में एक रिपॉजिटरी विभाजन करना चाहिए :

1. रिपॉजिटरी की व्यवस्था करें ताकि इसे कई छोटे रिपॉजिटरी में विभाजित करना आसान हो। उदाहरण के लिए, वर्तमान रिपॉजिटरी को फिर से व्यवस्थित करें ताकि प्रत्येक शीर्ष-स्तरीय निर्देशिका उस रिपॉजिटरी से मेल खाती हो जिसे आप भविष्य में बनाना चाहते हैं। ऐसा करने पर, आप शाखा-स्पेगेटी अनुशासन का उपयोग करना जारी रख सकते हैं, जिससे हर कोई परिचित है।

2. जब चरण 1 पूरा हो जाता है, तो शाखा-स्पेगेटी अनुशासन को परिष्कृत करके यह आवश्यक करें कि कोई भी एकल शाखा केवल एक शीर्ष-स्तरीय निर्देशिका में फ़ाइलों को स्पर्श कर सकती है।

3. जब प्रत्येक शाखा चरण 2 का अनुपालन करती है, तो विभाजन का प्रदर्शन करें। पथ के पहले-स्तर को हटाकर, एकल रिपॉजिटरी को पैच करने के लिए डेवलपर्स आसानी से अपने लंबित परिवर्तनों को परिवर्तित कर सकते हैं।

अब जब विभाजन किया जा चुका है, तो आप शाखा अनुशासन पर काम करना शुरू कर सकते हैं।

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

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

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

Comments

सही: वे शाखाएँ सुविधा और (विभिन्न स्तरों की) एकीकरण शाखाएँ हैं।

— बजे डैन कॉर्निलेस्कु

लगभग 1: विभाजन के बाद भी, यह उल्लेख के लायक हो सकता है कि आप अभी भी रेपो के उपयोग के साथ एक पूरी स्पेगेटी जैसा दृश्य

— पा सकते हैं

लेकिन Google और FB ट्रंक-आधारित के साथ मोनोरेप्स का उपयोग करते हैं ...

— AnoE

Answer 2

जब किसी चीज़ से किसी और चीज़ की ओर पलायन होता है, तो केवल दो चीजें हैं जिन्हें आपको परिभाषित करने की आवश्यकता है:

1. आपका निशाना क्या है
2. वहां कैसे जाएं (माइग्रेशन प्लान)

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

संभावना है, आपके पास जो भी शाखाएँ हैं या एक उद्देश्य पूरा हुआ है। स्पष्ट रूप से परिभाषित लक्ष्य प्रक्रिया के बिना, लोग उनके लिए वह काम करते रहेंगे, जिस तरह से यह उनके लिए सबसे उपयुक्त है (और ठीक ही ऐसा)।

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

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

एक बार जब आपका लक्ष्य होगा, तो आप प्रवास योजना को विस्तृत कर सकेंगे। वह योजना जितनी लंबी या जितनी छोटी हो उतनी कम हो सकती है। मैंने इस तरह के ब्रांचिंग मॉडल को रात भर लगाया है; अन्य स्थानों पर, यह 2 या 3 स्प्रिंट से अधिक किया गया था। यह मेरे लिए बहुत मायने नहीं रखता, जब तक हम सुधार कर रहे हैं।

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

DevOps संचार, खुलेपन और दक्षता के बारे में है। इन अवधारणाओं को ध्यान में रखा जाना चाहिए और पूरी प्रक्रिया में संचार किया जाना चाहिए।

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

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

Answer 3

बहु-ब्रांकेड हाइड्रा रिपॉजिटरी को एकल ब्रांच्ड मॉडल में बदलना वास्तव में बहुत सरल है।

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

इस प्रक्रिया को तब तक जारी रखें जब तक आप अपनी सभी शाखाओं को मिलाने में कामयाब नहीं हो जाते, सभी संघर्षों को सुलझा लेते हैं और आपके पास केवल एक ही शाखा शेष है।

आरंभ करने के लिए आप इस सरल रूपरेखा का अनुसरण कर सकते हैं:

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

Answer 4

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

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

Comments

क्या आप इस उत्तर को बेहतर बनाने के लिए इसे समझना आसान बना सकते हैं?

— एवगेनी

प्रश्न विशेष रूप से यह बताता है कि यह प्रवास / संक्रमण के बारे में है, न कि पहले और बाद के तरीकों के बारे में । आप यहाँ उत्तरार्द्ध को संबोधित करने लगते हैं।

— टोबे स्पाइट

@TobySpeight इस प्रश्न को इसके मूल से संपादन द्वारा बदल दिया गया था, यही कारण है कि यह उत्तर प्रासंगिक हुआ करता था लेकिन अब नहीं है।

— एवगेनी