शाखाओं को जमा करने से रखें

Question

जैसे-जैसे हम बड़े होते जाते हैं, हम एक समस्या में दौड़ने लगते हैं, जहाँ सुविधाएँ इसे परीक्षण के लिए मंचन के लिए बनाती हैं, लेकिन जब तक सब कुछ परीक्षण नहीं हो जाता और स्वीकृत नई सुविधाएँ परीक्षण के लिए मंचन पर होती हैं।

यह एक ऐसा वातावरण बना रहा है जहां हम उत्पादन के लिए लगभग कभी धक्का नहीं दे सकते क्योंकि हमारे पास परीक्षण और अप्रयुक्त सुविधाओं का एक संयोजन है। मुझे यकीन है कि यह एक सामान्य समस्या है, लेकिन मुझे अभी तक कोई अच्छा संसाधन नहीं मिला है।

कुछ विशेष बातें:

• BitBucket पर GIT
• Azure में स्क्रिप्टेड तैनाती के लिए जेनकिंस

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

Comments

क्या आप प्रत्येक सुविधा के लिए शाखा कर रहे हैं, या आप परीक्षण सर्वर शाखा में सीधे फ़ीचर परिवर्तन पर जोर दे रहे हैं?

— रॉबर्ट हार्वे

आप सुविधाओं और शाखाओं का प्रबंधन कैसे करते हैं, इस बारे में जानकारी के बिना हम आपके मुद्दों (नों) का एक विशिष्ट उत्तर नहीं दे सकते।

— माइकल ड्यूरेंट

क्या आप किसी तरह से पुनरावृत्तियों के साथ काम करते हैं (जैसे दो सप्ताह स्प्रिंट, या संस्करण रिलीज़)?

— रेमकोगर्लिच

@RobertHarvey: हम प्रत्येक सुविधा के लिए ब्रांच कर रहे हैं, लेकिन हमारे पास एक देव, स्टेज और प्रोडक्शन ब्रांच है, जिसे हम मर्ज करते हैं और मर्ज होने पर उस ब्रांच को अपने आप बनाते हैं और डिपो करते हैं।

— वेस्ले

@RemcoGerlich: हम इस समय तीन सप्ताह के स्प्रिंट में काम करते हैं, लेकिन आठ डेवलपर्स के साथ इस बात की कोई गारंटी नहीं है कि हम जो प्रत्येक चक्र बनाते हैं, वह प्रगति बोर्ड भर में परिपूर्ण है।

— वेस्ले

Answer 1

ऐसा लगता है कि आपके यहाँ कुछ समस्याएं हैं:

1. एक विशिष्ट रिलीज के लिए सुविधाओं की पहचान करना

यह एक परियोजना प्रबंधन मुद्दा है, और एक समन्वय मुद्दा है। क्या यह सुविधा पहले, उसी समय या इस अन्य सुविधा के बाद जारी की जाएगी ? यदि रिलीज़ एक समय में एक सुविधा होना चाहते हैं, तो पहचानें। यदि सुविधाओं को रिलीज़ में समूहीकृत किया जा रहा है, तो पता लगाएँ कि समूह क्या हैं, और इसे देवों और निर्णय निर्माताओं के साथ लागू करते हैं । टैग जारी करने के लिए अपनी समस्या ट्रैकिंग या टिकटिंग प्रणाली का उपयोग करें। यह स्पष्ट करें कि यदि किसी विशिष्ट रिलीज़ की एक विशेषता नो-गो है, तो वे सभी हैं।

2. शाखापर रणनीति

Git-flow इन जैसे मुद्दों के लिए आसान उत्तर है, और अक्सर लोग git-flow के एक संस्करण का उपयोग करते हैं, भले ही वे यह न जानते हों कि वह क्या है। मैं यह नहीं कहने जा रहा कि यह सभी समस्याओं के लिए एक पकड़ है, लेकिन यह बहुत मदद करता है।

ऐसा लगता है कि आप गैर-नियतात्मक रिलीज रणनीतियों के साथ एक मुद्दे में भाग रहे हैं, जहां सुविधाओं को मंजूरी दी गई है और कुछ समय पहले जो विकास शुरू हुआ था, वह कुछ और के बाद जारी किया जा सकता है जो कि हाल ही में शुरू हुआ था - लीप-मेंढक सुविधाएँ।

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

"हॉटफ़िक्स" या "बगफ़िक्स" शाखाएं इस प्रक्रिया का एक अनिवार्य हिस्सा हैं; छोटे एक-बंद फ़िक्सेस के लिए उनका उपयोग करें जिनके पास एक छोटा क्यूए चक्र है।

आपके विवरण से, यह भी बेहतर हो सकता है कि आप एक ऑफिशियल 'डेवलपमेंट' ब्रांच को न बनाए रखें। बल्कि, शाखा सभी विशेषताओं को बंद कर देती है, और एक रिलीज़ होने के बाद विलय की गई रिलीज़ शाखाएँ बनाती हैं।

3. वातावरण

उत्पादन == मास्टर को छोड़कर, अपने वातावरण से संबंधित शाखाओं से मेल न खाएं। The विकास ’शाखा को तोड़ा जाना चाहिए। रिलीज शाखाओं को पर्यावरण के परीक्षण के लिए धकेल दिया जाता है, चाहे वह एक क्यूए वातावरण हो या एक मचान एनवायरमेंट। यदि आपको जरूरत है, तो एक विशिष्ट सुविधा शाखा को एक वातावरण में धकेलें।

यदि आपके पास एक से अधिक सुविधा शाखा हैं, जिन्हें अलग से जारी करने की आवश्यकता है, लेकिन एक ही समय में परीक्षण किया जा रहा है ..... _ \ _ (¯) _ / ツ .... किसी अन्य सर्वर को स्पिन करें? शायद उन्हें फेंक-दूर शाखा में एक साथ मिला दें ... मूल शाखाओं में सुधार / परिवर्तन करें और फेंक-दूर शाखा में फिर से विलय करें; अंतिम स्वीकृति और व्यक्तिगत रिलीज शाखाओं पर यूएटी करें।

4. एक शाखा से गैर-अनुमोदित सुविधाओं को हटाना

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

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

शुभकामनाएँ।

Comments

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

— जेन

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

— डॉक्टर ब्राउन

... फिर भी मुझे लगता है कि यह एक बहुत अच्छा जवाब है।

— डॉक्टर ब्राउन

सहमत - मैंने पहले खंड से "ऑर्डर" बिट को हटा दिया। मुझे लगता है कि "आदेश" रिलीज को पहचानने से कम महत्वपूर्ण नहीं है। यदि सीआई लक्ष्य है, तो परीक्षण और रिलीज के लिए विशिष्ट विशेषताओं को रखना निश्चित रूप से अनुसूची रखने से अधिक महत्वपूर्ण है।

— जेन

मैं आमतौर पर यह सलाह नहीं देता कि या तो - लेकिन सवाल विशेष रूप से कोड को प्रबंधित करने की कोशिश करने के बारे में पूछा गया था, जहां कुछ विशेषताएं अनुपलब्ध और अप्रयुक्त थीं। मैं शायद ही कभी ऐसे प्रोजेक्ट्स पर काम करता हूं जिनमें इतनी अनिश्चितता है कि कौन सी सुविधाओं को कब जारी किया जाएगा - आमतौर पर रिलीज़ शेड्यूल बहुत सुनियोजित होता है, और एक रिलीज़ में देरी अगले को भी पीछे धकेल देती है। इसके बदले आप क्या करेंगे?

— जेन

Answer 2

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

Answer 3

यह परीक्षण और उत्पादन के बीच समन्वय का एक सरल मामला होना चाहिए। यदि आप Git में सुविधा शाखाओं का उपयोग कर रहे हैं, तो परीक्षण चक्र के दौरान परीक्षण के लिए पूरी की गई सुविधा शाखाओं को धकेलना बंद करें, और परीक्षण पूर्ण होने पर फिर से शुरू करें।

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

Answer 4

काम ढेर हो गया

मेरे अनुभव में यह एक सार्वभौमिक समस्या है। मैं इसके साथ संबोधित करता हूं:

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

Answer 5

शाखाओं

उस प्रक्रिया को नियंत्रित करने के लिए आपको कुछ शाखाओं की आवश्यकता है:

• विशेषता : यह शाखाएं गुरु से पैदा होती हैं। प्रत्येक कार्य शाखा को कुछ कार्य के साथ पहचानने के लिए कुछ प्रोजेक्ट प्रबंधन एप्लिकेशन का उपयोग करें। : उदाहरण के अनुसार, अगर आप TRAC उपयोग करते हैं, आप अगर तरह शाखाओं खत्म हो जाएगा 1234-user-crud, 1235-bug-delete-catalogआदि भी काम संख्या के साथ अपने प्रतिबद्ध पहचानें, यह आप एक बहुत आप का आपस में विलय करने में समस्या है जब (आप करेंगे) में मदद मिलेगी।
• परीक्षण : सभी सुविधा शाखाएँ जो की जाती हैं, उन्हें परीक्षण शाखा में मिला दिया जाएगा। आप परीक्षण शाखा को कभी किसी सुविधा शाखा में नहीं मिलाते हैं , क्योंकि आप उत्पादन (मास्टर) में अन्य सुविधाओं से कोड नहीं चाहते हैं। वही releaseशाखा के लिए मान्य है ।
• रिलीज़ : जब आप तय करते हैं कि उत्पादन में कौन सी परीक्षण सुविधाएँ हो सकती हैं, तो आप इस शाखा में (फिर से ...) इस शाखा का विलय करते हैं। आपको सभी विशेषताओं का फिर से परीक्षण करने की आवश्यकता है, क्योंकि यह मर्ज नई समस्याएं ला सकता है। जब रिलीज़ का परीक्षण किया जाता है और किया जाता है, तो आप इस शाखा को मास्टर में मर्ज करते हैं और संस्करण के लिए मास्टर पर एक टैग बनाते हैं।
• मास्टर : केवल उत्पादन कोड होते हैं।

गिट प्रवाह देखें:

                              |FEAT_2|
                                  |
                             .---C06<-------.---------.
                            /                \         \
                           /   |FEAT_1|        \         \
                          /       |            \         \
                         /    .--C07<--.--------\---------\---------.
                        /    /          \        \  |TEST| \         \
                       /    /            \        \    |    \         \
                      /    /        .-----`--C09<--`--C10    \         \ |RELEASE|
                     /    /        /                          \         \    |
    <v4.6.0>        /    /        /                       .----`--C11<---`--C12<--.
       |           /    /        /                       /                         \
C01<--C02<--C04<--´----´--------´-----------------------´---------------------------`--C13
 |           |                                                                          |
<v4.5.0>  <v4.6.1>                                                                   |MASTER|
                                                                                        |
                                                                                     <v4.7.0>

वातावरण

बहुत आसान:

• परीक्षण : यह वातावरण परीक्षण शाखा का उपयोग करता है।
• रिलीज़ : यह वातावरण वास्तविक रिलीज़ शाखा का उपयोग करता है।

डेवलपर्स अपनी मशीन में काम करते हैं, प्रत्येक अपने स्वयं के डेटाबेस का उपयोग कर रहा है। यदि प्रत्येक डेवलपर के पास एक व्यक्तिगत डेटाबेस (लाइसेंस के कारण, डेटाबेस का आकार आदि) संभव नहीं है, तो आपको डेवलपर्स के बीच एक डेटाबेस साझा करने में बहुत समस्याएँ होंगी: जब कोई व्यक्ति अपनी शाखा में किसी स्तंभ या तालिका को हटाता है, तो अन्य डेटाबेस में इस कॉलम / टेबल के साथ शाखाएं अभी भी मायने रखती हैं।

समस्या

इस प्रक्रिया में सबसे बड़ी समस्या मर्ज की है।

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

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

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

Comments

@DownVoter, क्यों?

— ढेरिक

Answer 6

ऐसा लगता है जैसे आप अपनी एकीकरण शाखा से परिवर्तन को अपनी उत्पादन शाखा में विलय कर रहे हैं , जो कि IMHO एक अच्छा अभ्यास नहीं है, बिल्कुल आपके द्वारा बताए गए कारणों के लिए। जैसे ही एक निश्चित रिलीज के लिए उत्पादन शाखा को मुख्य एकीकरण शाखा से खींच लिया जाता है, एकीकरण शाखा किसी भी समय, विचलन कर सकती है (आखिरकार इसे अगली रिलीज में विकसित होना चाहिए)। वर्तमान रिलीज शाखा में एकीकरण शाखा से विलय उस रिलीज के साथ असंगत परिवर्तन ला सकता है।

IMHO एक उचित प्रक्रिया होगी:

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

Answer 7

व्यक्तिगत रूप से, ऐसा लगता है कि यह एक टूलिंग समस्या से अधिक एक प्रक्रिया मुद्दा हो सकता है। कुछ बातें जो मैं यहाँ सुझाता हूँ:

• मुझे यकीन नहीं है कि आपके पास अलग-अलग देव और क्यूए समूह हैं। यदि आप करते हैं, तो सुनिश्चित करें कि देव और क्यूए दोनों स्प्रिंट प्लानिंग और अनुमान बैठकों में बैठते हैं। मेरी पिछली कंपनियों में से, हमने यह सुनिश्चित किया कि कहानी की जितनी संख्या में हमने एक कहानी सौंपी है, वह विकास और परीक्षण दोनों प्रयासों के लिए जिम्मेदार होगी। (आप सैद्धांतिक रूप से देव और क्यूए प्रयास के लिए दो अलग-अलग अनुमान लगा सकते हैं, लेकिन दोनों को शामिल करने के लिए आपको अपने अनुमान के लिए किसी भी तरह की आवश्यकता है, एक कहानी के लिए आवश्यक समय वास्तव में इसे वितरित करने के लिए आवश्यक समय है)। यहां तक ​​कि अगर आपके पास एक अलग क्यूए समूह नहीं है, तब भी सुनिश्चित करें कि आप अपने अनुमानों में परीक्षण प्रयास शामिल करें।
• ऊपर एक समान नस के साथ, एक विशेष स्प्रिंट में आप कितनी कहानियों को शामिल करने जा रहे हैं, इस पर पहले से सहमति दें। आपके द्वारा स्वीकार किए जाने वाले कहानी बिंदुओं की संख्या उस राशि पर आधारित होती है जिसे आपके डेवलपर्स अपने स्प्रिंट में समाप्त कर सकते हैं और क्यूए अपने स्प्रिंट में परीक्षण कर सकते हैं। (मैं मान रहा हूँ, निश्चित रूप से, कि क्यू स्प्रिंट देव स्प्रिंट के पीछे हैं, लेकिन आप इसे अपनी प्रक्रिया में अनुकूलित कर सकते हैं)। यदि आपके डेवलपर्स 200 कहानी बिंदुओं को समाप्त कर सकते हैं, लेकिन आपका क्यूए केवल 150 कहानी बिंदुओं को समाप्त कर सकता है, तो जाहिर है कि आप केवल "काम करने के लिए" शुरू होने से पहले केवल 150 कहानी बिंदुओं को कर सकते हैं और आप जैसे केस का वर्णन करते हैं, वैसा ही करते हैं। (इस तरह से एक मामले में, आप इसे कम करने के प्रयास के लिए अवरोध के कारण की जांच करना चाह सकते हैं)।
• कोई भी व्यक्ति QA को तब तक धकेलता नहीं है जब तक कि QA में मौजूद सभी चीज़ों का परीक्षण और वितरण नहीं किया जाता है ।
• एक पूर्ण विशेषता वह है जिसे परीक्षण और वितरित किया गया है। अगर यह नहीं दिया जाता है तो यह नहीं किया जाता है।
• जाहिर है, आप इसे किसी निश्चित शेड्यूल पर करने का प्रयास करना चाहते हैं। सतत एकीकरण और चंचलता के पीछे पूरे विचारों में से एक पुनरावृत्ति है। परिभाषा के अनुसार, पुनरावृत्ति बार-बार होने वाली डिलीवरी पर जोर देती है। लगातार एकीकरण और वितरण प्रत्येक के जोखिम को कम करता है।

ईमानदारी से, मुझे लगता है कि सबसे बड़ी बात यह होगी कि जब आप वितरित कर रहे हैं और कितने कार्य आप वास्तव में किसी निश्चित समय सीमा में पूरी तरह से समाप्त कर सकते हैं।

संक्षेप में: जब आप परीक्षण कर रहे हैं और पुरानी सुविधाओं को वितरित कर रहे हैं तो केवल QA को वितरित करें।

Answer 8

जब "सब कुछ परीक्षण और अनुमोदित किया जाता है", तो उसे तैनात करें जिसे उत्पादन के लिए परीक्षण और अनुमोदित किया गया था। यह एक विशेष प्रतिबद्धता हो सकती है, या यह जेनकींस द्वारा उत्पन्न एक विशेष निर्माण कलाकृतियां हो सकती हैं।

इससे कोई फर्क नहीं पड़ता कि बाद में उसी शाखा पर काम किया जाता है जो अभी तक परीक्षण नहीं किया गया है।

Comments

यह निश्चित रूप से मायने रखता है कि बाद में एक ही शाखा में परीक्षण नहीं किया गया है और अनुमोदित किया गया है - उत्पादन के लिए कोड को तैनात करना जो परीक्षण नहीं किया गया है, एक नाराज ग्राहक प्राप्त करने का एक निश्चित तरीका है।

— जेन

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

— bdsl

दूसरे शब्दों में, शाखाओं की उपेक्षा, व्यक्तिगत कमिट या व्यक्तिगत बिल्ड के संबंध में तैनाती का निर्णय करें।

— bdsl