एक नई दुबला टीम

Question

के लिए गिट ब्रांचिंग रणनीति हमारे पास एक वेब ऐप है जिसके लिए हमारे पास कुछ कॉर्पोरेट ग्राहक हैं। हमने हाल ही में इसे सास ऐप के रूप में पेश करने और दुबला दृष्टिकोण (हमारी कॉर्पोरेट पेशकश के साथ समानांतर) का पालन करने का निर्णय लिया है। जिसका अर्थ है कि हमें उस यात्रा पर प्रयोग मिल गए हैं जो इसे उत्पादन में नहीं ला सकता है।

इससे पहले कि हम दुबला हम निम्नलिखित शाखाओं में रणनीति के साथ खुश थे चला गया (मेरा मानना ​​है कि यह बहुत मानक है):

• मास्टर - हमेशा स्थिर
• देव - अक्सर अस्थिर (फीचर शाखाओं काट पर नई सुविधाओं के लिए देव की अगली बड़ी रिलीज में जाएं)
• major_release_x - लाइव (देव के बाद मास्टर का काट दिया गया हैमास्टर में, यह वह जगह है जहां बग फिक्स जगह ले और गुरु और देव)

अब हम इसके बाद के संस्करण के अलावा निम्नलिखित है में वापस विलय कर दिया है और यह है कि सभी अच्छी तरह से काम नहीं कर रहा:

• lean_release_branch - रहते हैं (major_release_x काट और प्रयोगों में शामिल है)
• experiment_x - major_release_x काट (यह वह जगह है जहाँ हम सुविधा एक साथ और फिर मीटर हैक lean_release_branch में erge)

हमारे परिदृश्य अब है कि हम जल्दी रिलीज और अक्सर के रूप में दुबला दृष्टिकोण तय है, और जब हम कुछ मनमाना पर ठोस प्रतिक्रिया प्राप्त है, तो हम यह productionize करने की जरूरत है और जैसे ही इसे जारी करने की जरूरत है जितना संभव हो (lean_release_branch से बाहर)।

समस्या जा रहा है हम देव के बंद एक सुविधा शाखा नहीं बना सकते हैं (के रूप में यह सबसे अधिक संभावना अस्थिर है) और हम दो कारणों के लिए lean_release_branch के बंद एक सुविधा शाखा नहीं बना सकते:

1. वह प्रयोग कोड से दूषित कर दिया गया है तो इस परिवर्तन/सुविधा की राह मास्टर
2. lean_release_branch हमेशा जारी करने के लिए तैयार होने की जरूरत है के लिए वापस करने के लिए सक्षम नहीं होगा, तो हम व्यस्त नहीं किया जा सकता कर परीक्षण और फिक्स्ड (इसमें परिवर्तन/फीचर विलय करने के बाद) यदि कोई महत्वपूर्ण समस्या है जिसे

किसी को भी हमारे सेटअप के लिए बेहतर रणनीति के बारे में पता है?

Answer 1

मैंने अभी टीएफएस से जीआईटी में बदल दिया है और मैं जिस मॉडल का पालन करता हूं वह इस post पर आधारित है।

आपके प्रयोगों के बारे में यह केवल "विशेषीकृत शाखाएं" है जो इसे विकसित करने (विकसित करने में विलय) नहीं कर पाएगी।

Answer 2

क्योंकि सब कुछ में major_release_x देव में पहले से ही है (के बाद से देव अंतिम प्रमुख रिलीज होने से पहले मास्टर में विलय कर दिया गया था) एक उत्पादित सुविधा (एक सफल प्रयोग के बाद) एक सुविधा शाखा पर बंद किया जा सकता है major_release_x, इसे कहते production_feature_y, और फिर दोनों देव में विलय कर दिया है, अगले प्रमुख रिलीज में हो सकता है, और lean_release_branch।

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

सुविधा पर आगे ग्राहकों की प्रतिक्रिया production_feature_y पर लागू किया जा सकता है और फिर से देव और lean_release_branch में विलय कर दिया।

बग सुधार उसी तरह से नियंत्रित किया जा सकता है, बंद major_release_x एक शाखा पर किया जाता है और दोनों major_release_x और lean_release_branch में विलय कर दिया।

Answer 3

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

जब तक मैं आपकी समस्या को गलत तरीके से पढ़ नहीं पा रहा हूं, तो आप उन सभी शाखाओं में कम जटिलता के साथ इस रणनीति के साथ इसे प्राप्त कर सकते हैं।