Agile प्रोजेक्ट

Question

के लिए गिट ब्रांचिंग रणनीति मेरे पास एक परियोजना है जो गिट स्टैश रिपोजिटरी में स्थित है। कोड चार वातावरण (देव, टेस्ट, स्टेज और प्रोड) में तैनात किया जाएगा। हम Agile पद्धति का पालन करें। तो देव टीम रिलीज गतिविधियों और गैर रिलीज (भविष्य रिलीज) गतिविधियों दोनों के लिए काम करती है। मुझे इस आवश्यकता के आधार पर शाखाएं बनाना है। नीचे मेरी योजना है।

तीन स्थिर शाखाएं: मास्टर, रिलीज और विकास।

मास्टर डिफ़ॉल्ट शाखा है। विकास मास्टर से बनाया जाएगा। रिलीज

फीचर शाखाओं से विकसित किया जाएगा -> वे विकास से बनाए जाएंगे। प्रत्येक डेवलपर की एक फीचर शाखा होती है और वे कोड को एक बार विकसित शाखा में विलय करते हैं। इसलिए विकसित पर्यावरण शाखा से देव पर्यावरण तैनाती होगी।

यदि परिवर्तनों को टेस्ट पर्यावरण में जाने की आवश्यकता है, तो हमारे यहां दो तरीके हैं। एक रिलीज शाखा के साथ विकास शाखा विलय कर रहा है (रिलीज शाखा से टेस्ट पर्यावरण परिनियोजन होगा)। हम इसे कार्यान्वित नहीं कर सकते क्योंकि विकास शाखा में दोनों रिलीज और गैर रिलीज परिवर्तन हो सकते हैं।

एक और तरीका फीचर शाखाओं को सीधे रिलीज शाखा में विलय कर रहा है। ताकि प्रत्येक डेवलपर परिवर्तन को रिलीज शाखा में विलय किया जा सके। मुझे यकीन नहीं है कि मैं इस विधि को कार्यान्वित कर सकता हूं या नहीं। क्या कोई मुझे बता सकता है कि क्या यह तरीका काम करेगा? क्या इस स्थिति को संभालने का कोई वैकल्पिक तरीका है।

शाखाओं:

मास्टर शाखा ---> शाखा का विकास -> रिलीज शाखा

विकसित शाखाओं --- सुविधा Branch1 | फीचर शाखा 2 | सुविधा branch3

---

तैनाती:

के लिए शाखा का विकास -> देव की तैनाती

के लिए

रिलीज शाखा -> परीक्षण की तैनाती

के लिए

मास्टर शाखा -> चरण और उत्पादन की तैनाती

मैं विकास शाखा को रिलीज शाखा में विलय नहीं कर सकता। चूंकि विकास शाखा में कुछ गैर-रिलीज परिवर्तन भी हैं। मुझे रिलीज शाखा पर केवल रिलीज की जरूरत है। शाखाओं को सीधे रिलीज शाखा में विलय कर सकते हैं? यहां सबसे अच्छा तरीका क्या है?

Answer 1

यह मुझे लगता है, आप Git Flow चुनने के बहुत करीब हैं। दरअसल, अगर मुझे गलत नहीं लगता है, तो यह रणनीति का आपका आधार है, आप वर्णन करते हैं। जो माहान है।

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

Git प्रवाह के सुझाव, में एक कार्य/सुविधा विलय नहीं करने के लिए विकसित करने, जब तक यह शायद काफी तैयार हो सकता है कुछ सुधारों के साथ अगले मचान/prod रिलीज में जाने के लिए है।Git प्रवाह में, आप हमेशा गैर तेजी से आगे (git merge --no-ff FEATURE_BRANCH_NAME) के साथ विलय इतना है कि अगर आप एक मचान/prod रिलीज के पास हो रही है, और इस सुविधा के लिए तैयार नहीं प्राप्त कर सकते हैं, आप चाहते हैं रिवर्स विलय (एकल) विलय-लिखें हैं, इस प्रकार से हटाने या रिहाई का विकास -branch।

मैं इस बारे में एक लंबे समय तक चर्चा संदेह है, लेकिन सिर्फ पिच, मैं 2 संभव तरीके में अपने विचारों को पूरा करने के लिए देखें:

1) 2 का विकास-शाखाओं है: विकास के लिए एक, शाखा का विकास, जिसे शीघ्र ही स्टेजिंग के लिए अनुसूचित किया जाएगा- और कुछ क्यूए या जो भी हो, उसके बाद प्रोडक्शन रिलीज हो जाएगा। और प्रयोगात्मक सामान के लिए, यह एक dev/test-environment (उदा। निरंतर तैनाती के माध्यम से) पर जाएगा। यह लंबे समय तक विकसित कहते हैं (यह एक बुरा और बहुत लंबा नाम imo है, इसलिए एक बेहतर बनाने, या अपनी टीम तुमसे नफरत करता हूँ जाएगा :))।

विचार:

• शाखा का विकास अक्सर में विलय कर दिया जाना चाहिए लंबी अवधि के विकसित शाखा, हमेशा यह अपडेट रखने के लिए।
• आप शायद 2 का विकास-वातावरण की जरूरत शाखाओं में से प्रत्येक के लिए परीक्षण करने के लिए, 1 होगा।
• खतरे: से बनाए गए लंबी अवधि के विकसित हैं कि (शायद गलती से) शाखाओं में विलय कर दिया विकसित में और अधिक नहीं के लिए तैयार सामान खींचें शाखा विकसित कर सके। इसके लिए समाधान 1) हो सकता है फीचर-शाखा को लंबे समय तक विकसित करने के लिए और 2) चेरी-पिक विकसित करें। लेकिन यह त्रुटि-प्रवण और जटिल है, और 1 गलत विलय पूरे को शाखा विकसित कर सकता है, जो इसे स्टेजिंग/उत्पादन के लिए तैयार नहीं है।

2) सिर्फ 1 शाखा बढ़ने लगता है (आप का सुझाव के रूप में) और मास्टर

से जारी-शाखाओं बनाने यह शायद अब तक का सबसे आसान तरीका है लो। यह प्रत्येक डेवलपर से थोड़ा और प्रयास करता है, लेकिन कम त्रुटि प्रवण है।

प्रक्रिया होगा:

• एक स्प्रिंट/विकास-चक्र के प्रत्येक शुरुआत में, जारी-प्रबंधक अगली फिल्म शाखा बंद आधारित मास्टर पैदा करता है। जैसे रिलीज-स्प्रिंट -42 जो, जब बनाया गया, मास्टर शाखा के बराबर है।
• डेवलपर से आधार के साथ फीचर-शाखाएं बनाते हैं विकसित करें। वे सुविधा के लिए तैयार होने के बाद फीचर-शाखा को विकसित करने के लिए विलय करते हैं। जैसा कि आप वर्तमान में सुझाव देते हैं।
• यदि यह सुविधा 'सही' है और काम, मर्ज-लिखें कि में सुविधा शाखा विलय विकसित से बनाया गया था है चेरी उठाया रिहाई-स्प्रिंट-42, उदा में -m विकल्प के साथgit cherry-pick -m 1 COMMIT_HASH। यहां यह जानना वाकई महत्वपूर्ण है कि आप कौन से माता-पिता को चुन रहे हैं (मेरे उदाहरण में माता-पिता 1. विकसित करना चाहिए http://git-scm.com/docs/git-cherry-pick पढ़ना और समझना चाहिए)।

विचार:

• खतरा हो सकता है, यह एक ऐसी सुविधा में काम कर विकसित शाखा क्योंकि लापता निर्भरता रिहाई-स्प्रिंट-42 शाखा में काम नहीं कर सकती है,। यह, भगवान का शुक्र है, यही कारण है कि हमारे पास वातावरण और आंतरिक समय सीमाएं हैं :)
• चेरी-पिकिंग करना सबसे आसान काम नहीं है। लेकिन निश्चित रूप से गलत शाखा में विलय के माध्यम से अवांछित कोड खींचने से बचने का प्रयास करने का सबसे अच्छा तरीका है।

अप

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

आदर्श रूप में विकल्प के लिए जाना होगा हालांकि, मैं डिफ़ॉल्ट रूप से एक रणनीति की सिफारिश करता हूं, जहां सामग्री को छोटे टुकड़ों में तोड़ दिया जाता है और स्पिंट्स काफी बड़े होते हैं, कि एक स्प्रिंट के भीतर आमतौर पर एक कार्य/फीचर निष्कर्ष निकाला जा सकता है (यानी विलय और तैनात!)। लेकिन अनुभव से मैं जानता हूँ कि, कि इच्छाधारी सोच seldomly लागू किया जा सकता :)

1 आखिरी बात: मैं वास्तव में वास्तव में वास्तव में आपको प्रोत्साहित करते हैं 1 रिलीज शाखा (सदा) की जरूरत नहीं करने के लिए होगा, लेकिन एक नई रिलीज शाखा बनाने के लिए प्रत्येक स्प्रिंट/चक्र के लिए, रिलीज-स्प्रिंट -42, रिलीज-स्प्रिंट -43, et.c. (चाहे आप दूसरे परिदृश्य में आदर्श गिट प्रवाह या मास्टर-शाखा में विकास शाखा से इसे आधार दें, मैंने सुझाव दिया है)। मेरे अनुभव में अक्सर निरंतर रिलीज-शाखाएं होने से गुम सामान, विलय-समस्याएं और अन्य बुरेपन होते हैं। इसके अलावा, मास्टर और विकसित शाश्वत शाखाएं होनी चाहिए।

इस चर्चा :)