गिट-फ्लो

Question

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

यहाँ दो दृष्टिकोण हैं:

1. शाखा का विकास

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

2. मास्टर शाखा:

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

पाइपलाइनों में उपयोग करने के लिए कठोर शाखा कौन सा है?

Answer 1

सत्य दोनों के बीच है। आप एक सख्त सीडी पाइप लाइन में Git प्रवाह को अपनाना चाहते हैं, तो आप अपने सीआई के लिए विज्ञप्ति जारी की शाखा का उपयोग करना चाहिए:

1. हर (के बैच) के लिए विकसित शाखा प्रतिबद्ध (s), अपने सीआई सर्वर स्वचालित रूप से करते हैं रिलीज-शाखा बनाएं और अपने सभी परीक्षणों को चलाएं।
2. यदि यह विफल हो जाता है, तो इसे शाखा की रिपोर्ट करें और/या हटा दें, अन्यथा इसे मास्टर में विलय करें।

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

Answer 2

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

मैं इस दृष्टिकोण का सुझाव चाहते हैं:

1. शाखा का विकास करना

• शाखा का विकास करना बिल्ड प्रतिबद्ध ट्रिगर किया जाएगा: मर्ज पर जैसे ही एक सुविधा का विकास शाखा में जोड़ा जाता है (या खींच अनुरोध), सीआई निर्माण करेगा, परीक्षण (यूनिट परीक्षण & कोड संशोधन) और समाधान पैकेज ("-develop-vX" प्रत्यय के साथ)। तो विफलता के मामले में टीम तेजी से प्रतिक्रिया करने में सक्षम है।
• एक बार Commit Build सफलतापूर्वक समाप्त हो गया है, तो कार्य पूरा हो गया है (अन्यथा, परिवर्तन वापस कर दिया गया है और डेवलपर जिन्होंने परिवर्तन किया है उसे तुरंत ठीक करना होगा)। समानांतर में, स्वीकृति परीक्षण चरण डेवलपर के काम को अवरुद्ध किए बिना स्वीकृति परीक्षण सूट (उदा। कार्यात्मक & रिग्रेशन परीक्षण) निष्पादित करने के लिए विकास पर्यावरण को पिछले निर्माण को तैनात करना शुरू कर देता है। एक बार यह खत्म होने के बाद, टीम को विकसित शाखा की स्थिति को सूचित किया जाता है। इसलिए, टीम वर्तमान स्प्रिंट के दौरान समाधान की स्थिरता से अवगत है: यदि स्वीकृति परीक्षण चरण सफलतापूर्वक खत्म हो जाता है, तो उत्पाद मास्टर शाखा के साथ विलय के लिए तैयार है (अन्यथा, यह तय किया जाएगा)।

2. मास्टर शाखा

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

Answer 3

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