Git ब्रांचिंग रणनीति को परीक्षण / QA प्रक्रिया के साथ जोड़ा गया

Question

हमारी विकास टीम GitFlow शाखाओं की रणनीति का उपयोग कर रही है और यह बहुत अच्छा रहा है!

हाल ही में हमने अपने सॉफ़्टवेयर की गुणवत्ता में सुधार करने के लिए एक दंपति परीक्षकों की भर्ती की। विचार यह है कि प्रत्येक फीचर को एक परीक्षक द्वारा परीक्षण / क्यूए किया जाना चाहिए।

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

परीक्षक को किस शाखा पर नई सुविधाओं का परीक्षण करना चाहिए?

जाहिर है, दो विकल्प हैं:

• व्यक्तिगत सुविधा शाखा पर
• पर developशाखा

विकसित शाखा पर परीक्षण

प्रारंभ में, हमने माना कि यह सुनिश्चित करने का तरीका है क्योंकि:

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

इसके साथ सबसे बड़ी समस्या है:

• developशाखा कीड़े के साथ प्रदूषित कर रहा है।

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

फ़ीचर शाखा पर परीक्षण

इसलिए हमने फिर से सोचा और फैसला किया कि हमें फीचर शाखाओं पर सुविधाओं का परीक्षण करना चाहिए। परीक्षण करने से पहले, हम developशाखा से फीचर शाखा में परिवर्तन (शाखा के साथ पकड़ develop) को मर्ज करते हैं । यह अच्छा है:

• आप अभी भी मुख्यधारा में अन्य सुविधाओं के साथ इस सुविधा का परीक्षण करते हैं
• आगे विकास (जैसे बग फिक्स, संघर्ष को हल करना) developशाखा को प्रदूषित नहीं करेगा ;
• जब तक यह पूरी तरह से परीक्षण और अनुमोदित नहीं हो जाता, तब तक आप आसानी से फ़ीचर जारी न करने का निर्णय ले सकते हैं;

हालांकि, कुछ कमियां हैं

• परीक्षक को कोड का विलय करना पड़ता है, और यदि कोई संघर्ष (बहुत संभावना) है, तो उसे डेवलपर से मदद मांगनी होगी। हमारे परीक्षक परीक्षण में विशेषज्ञ हैं और कोडिंग करने में सक्षम नहीं हैं।
• एक और नई सुविधा के अस्तित्व के बिना एक विशेषता का परीक्षण किया जा सकता है। उदाहरण फ़ीचर ए और बी दोनों एक ही समय में परीक्षण के अधीन हैं, दो विशेषताएं एक दूसरे से अनजान हैं क्योंकि दोनों में से किसी को भी developशाखा में विलय नहीं किया गया है । इसका मतलब है कि आपको developशाखा के खिलाफ फिर से परीक्षण करना होगा जब दोनों विशेषताओं को वैसे भी विकसित शाखा में विलय कर दिया जाएगा। और आपको भविष्य में इसका परीक्षण करना याद रखना होगा।
• यदि फ़ीचर ए और बी दोनों का परीक्षण और अनुमोदन किया जाता है, लेकिन जब एक विलय की पहचान की जाती है, तो दोनों विशेषताओं के लिए डेवलपर्स के दोनों का मानना ​​है कि यह उनकी खुद की गलती / नौकरी नहीं है क्योंकि उनकी सुविधा शाखा परीक्षण से पहले है। संचार में एक अतिरिक्त ओवरहेड है, और कभी-कभी जो कोई भी संघर्ष को हल करता है वह निराश होता है।

---

ऊपर हमारी कहानी है। सीमित संसाधन के साथ, मैं हर जगह हर चीज के परीक्षण से बचना चाहूंगा। हम अभी भी इससे निपटने के लिए बेहतर तरीके की तलाश कर रहे हैं। मैं यह सुनना पसंद करूंगा कि अन्य टीमें इस तरह की परिस्थितियों को कैसे संभालती हैं।

Comments

यह प्रश्न ऐसा लगता है कि यह प्रोग्रामर के लिए एक बेहतर विकल्प है , क्योंकि यह प्रोग्रामिंग समस्या से निपटता नहीं है, बल्कि एक विकास प्रक्रिया है। क्या कोई इसे माइग्रेट कर सकता है?

विचाराधीन प्रश्न: जीएटी फ्लो को क्यूए परीक्षण और एक नई सुविधा दोनों के साथ कैसे काम करना चाहिए?

— जोशुआ गोल्डबर्ग 16

हमारा मॉडल बिल्कुल वैसा ही है। मुझे यह सुनने में दिलचस्पी है कि आपकी क्यूए टीम फ़ीचर शाखाओं के मुद्दों को UAT प्रक्रिया (यदि आपके पास एक है) के दौरान फ़ील्ड के मुद्दों या मुद्दों से अलग तरीके से रिपोर्ट करती है। हम एटलसियन JIRA का उपयोग करते हैं और हम दोनों के लिए एक अलग वर्कफ़्लो है।

— void.pointer

अभी वही तय करना। इसके अलावा, जैसा कि हमारा पर्यावरण एक जावा वसंत अनुप्रयोग है, परीक्षण पर्यावरण को बनाने और तैनात करने में लगभग 20 मिनट लगते हैं। खुश किसी ने मुझसे वही संदेह पूछा जो मेरे पास था।

— डिगाओ_मब

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

— डेरेक ग्रीर

Answer 1

जिस तरह से हम करते हैं वह निम्नलिखित है:

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

1. डेवलपर हर नई सुविधा के लिए एक सुविधा शाखा बनाता है।
2. डेवलपर के परीक्षण के लिए प्रत्येक कमिट के साथ हमारे TEST परिवेश पर सुविधा शाखा (स्वचालित रूप से) तैनात है।
3. जब डेवलपर को परिनियोजन के साथ किया जाता है और फीचर का परीक्षण करने के लिए तैयार हो जाता है, तो वह फीचर शाखा पर विकसित शाखा को मर्ज कर देता है और उस सुविधा शाखा को हटा देता है जिसमें TEST पर सभी नवीनतम विकास परिवर्तन होते हैं।
4. परीक्षक परीक्षण पर। जब वह किया जाता है तो वह कहानी को "स्वीकार" करता है और विकसित होने पर फीचर शाखा को विलय कर देता है। चूंकि डेवलपर ने पहले से विकसित शाखा को सुविधा में विलय कर दिया था, इसलिए हम आम तौर पर बहुत अधिक संघर्षों की उम्मीद नहीं करते हैं। हालांकि, अगर ऐसा है तो डेवलपर मदद कर सकता है। यह एक मुश्किल कदम है, मुझे लगता है कि इससे बचने का सबसे अच्छा तरीका यह है कि सुविधाओं को जितना संभव हो उतना छोटा / विशिष्ट रखा जाए। अलग-अलग विशेषताओं को अंत में विलय करना होगा, एक ही रास्ता या कोई अन्य। बेशक टीम का आकार इस कदम की जटिलता पर एक भूमिका निभाता है।
5. विकसित शाखा भी (स्वतः) TEST पर तैनात है। हमारी एक नीति है कि भले ही फीचर शाखा का निर्माण विफल हो सकता है लेकिन विकसित शाखा को कभी असफल नहीं होना चाहिए।
6. एक बार जब हम एक सुविधा फ्रीज में पहुंच जाते हैं तो हम विकास से एक रिलीज बनाते हैं। यह स्वचालित रूप से STAGING पर तैनात है। उत्पादन परिनियोजन से पहले व्यापक अंत तक परीक्षण वहां पर होते हैं। (ठीक है शायद मैं थोड़ा अतिशयोक्ति करता हूं वे बहुत व्यापक नहीं हैं लेकिन मुझे लगता है कि उन्हें होना चाहिए)। आदर्श रूप से बीटा टेस्टर / सहकर्मियों अर्थात वास्तविक उपयोगकर्ताओं को वहाँ परीक्षण करना चाहिए।

आप इस दृष्टिकोण से क्या समझते हैं?

Comments

हम यह कैसे सुनिश्चित करते हैं कि फीचर 1 और फीचर 2 जो कि स्वतंत्र रूप से परीक्षण किए गए थे, एक साथ जाने के लिए भी अच्छे हैं (जैसा कि प्रश्न में उल्लेख किया गया है)?

— कुमार दीपक

हम अप्रत्यक्ष रूप से, एक को विलय करके और फिर दूसरे को विकसित करने के लिए करते हैं। यह ऊपर की प्रक्रिया का चरण 4 है और इसे कालानुक्रमिक क्रम से करना है। इसलिए यदि फीचर 2 विलय के लिए तैयार है, लेकिन सुविधा 1 को पहले ही विलय कर दिया गया है, तो सुविधा 2 डेवलपर और परीक्षक को यह सुनिश्चित करना होगा कि उनका विलय कार्य करेगा।

— Aspasia

मुझे लगता है कि इस गिट ब्रांचिंग मॉडल के अनुसार आप वैसे भी दो फीचर शाखाओं को एक दूसरे के साथ मिलाने वाले नहीं हैं।

— Aspasia

हमने चरण 6 में समस्याओं में भाग लिया है, विशेष रूप से कई विशेषताओं के साथ क्रंच समय में विकसित होने के लिए स्थानांतरित होने के कारण, क्यूए के बाद गैर-तुच्छ विलय जो कि क्यूए ने सुविधा शाखा पर हस्ताक्षर किए हैं, के बावजूद devlop को यथासंभव देर से विलय करने के बावजूद। मैंने यहां कुछ और विस्तार से टिप्पणी की: stackoverflow.com/a/25247382/411282

— जोशुआ गोल्डबर्ग

क्या आपके पास प्रत्येक सुविधा शाखा के लिए पूरा TEST एनवायरनमेंट (DB, सर्वर, क्लाइंट आदि) है? या वे पर्यावरण साझा करते हैं और बस अलग-अलग नाम हैं (उदाहरण के लिए app-name_feature1- app-name_feature2, आदि)

— hinneLinks

Answer 2

परीक्षण से पहले, हम विकसित शाखा से फीचर शाखा में परिवर्तन को मर्ज करते हैं

नहीं, खासकर अगर 'हम' क्यूए परीक्षक है। विलय से संभावित संघर्षों को हल करना शामिल होगा, जो डेवलपर्स द्वारा सबसे अच्छा किया जाता है (वे अपने कोड को जानते हैं), और क्यूए परीक्षक द्वारा नहीं (जो जितनी जल्दी हो सके परीक्षण करने के लिए आगे बढ़ना चाहिए)।

डेवलपर को उसकी featureशाखा के शीर्ष परdevel एक पुनर्खरीद करें और उस featureशाखा को धक्का दें (जिसे डेवलपर द्वारा हाल ही के develशाखा राज्य के शीर्ष पर संकलन और काम करने के रूप में मान्य किया गया है )।
इसके लिए अनुमति देता है:

• सुविधा शाखा (तुच्छ तेजी से आगे विलय) पर एक बहुत ही सरल एकीकरण।
• या, जैसा कि नीचे टिप्पणी में Aspasia द्वारा सिफारिश की गई है , एक पुल अनुरोध (GitHub) या मर्ज अनुरोध (GitLab) : अनुचर सुविधा PR / MR शाखा और के बीच एक मर्ज करता है , लेकिन केवल तभी नहीं जब संघर्ष का पता GitHub / GitLab द्वारा लगाया जाता है।develop

हर बार परीक्षक बग का पता लगाता है, वह उसे डेवलपर को रिपोर्ट करेगा और वर्तमान सुविधा शाखा को हटा देगा ।
डेवलपर कर सकता है:

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

सामान्य विचार: सुनिश्चित करें कि डेवलपर द्वारा मर्ज / इंटीग्रेशन भाग, क्यूए के लिए परीक्षण छोड़ दिया गया है।

Comments

क्या आप कह रहे हैं "मर्ज का उपयोग न करें, इसके बजाय रिबास का उपयोग करें"? यदि हां, तो मुझे भ्रम है, दोनों के बीच अंतर पर Git FAQ दिया गया है: git.wiki.kernel.org/index.php/…

— विकी

@VickiLaidler हाँ, यदि सुविधा शाखा QA द्वारा अस्वीकार कर दी जाती है, तो डेवलपर को रिबेस करना होगा, मर्ज नहीं करना होगा ( stackoverflow.com/a/804178/6309 )

— VONC

@VonC मैं पूरी तरह से सहमत हूं लेकिन कुछ मुद्दे हैं: 1) शाखा को हटाने से अन्य टूलिंग पर प्रभाव पड़ता है, जैसे कि Stash Pull Request (शाखा को हटाना PR को बंद करता है)। बल को धक्का देना पसंद करें। 2) यदि यह एक बड़ी सुविधा शाखा है जहाँ अपने जीवनकाल के दौरान दो लोगों ने सहयोग किया था, तो मर्ज करना रिबासिंग पर पसंद किया जाता था। अंत में इसे रीबस करने से संघर्ष दुःस्वप्न पैदा होता है क्योंकि मर्ज के कमिट्स को हटा दिया जाएगा, और यदि कोड मर्ज किए गए परिवर्तनों पर निर्भर करता है, तो इसे ठीक करना गैर-तुच्छ है

— void.pointer

अपने उत्तर को देखते हुए मैं एक रीबेस भी करूंगा और क्लीनर इतिहास के लिए मर्ज नहीं।

— एस्पासिया

@ ऐस्पेशिया अच्छे अंक। मैंने अधिक दृश्यता के लिए उत्तर में पुल-अनुरोध शामिल किए हैं।

— VonC

Answer 3

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

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

परीक्षक / क्यूए कोड समीक्षा में भाग ले सकते हैं, यूनिट परीक्षणों की जांच कर सकते हैं और सुविधाओं के पूरा होते ही प्रतिगमन सूट में जोड़े जाने के लिए स्वचालित एकीकरण परीक्षण लिख सकते हैं।

अधिक जानकारी के लिए इस लिंक को देखें ।

Comments

आप अभी भी Git में शाखाओं + रिबासिंग के साथ CI कर सकते हैं।

— void.pointer

Answer 4

हम उस चीज़ का उपयोग करते हैं जिसे हम "सोना", "रजत" और "कांस्य" कहते हैं। इसे ठेस, मंचन और क्यूए कहा जा सकता है।

मैं इसे पिघलने वाले पॉट मॉडल को कॉल करने के लिए आया हूं। यह हमारे लिए अच्छी तरह से काम करता है क्योंकि हमें चीजों के व्यावसायिक पक्ष में क्यूए की बहुत बड़ी आवश्यकता है क्योंकि आवश्यकताओं को तकनीकी बनाम समझना मुश्किल हो सकता है।

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

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

एक बार एक सुविधा QA पास होने के बाद हम इसे "सिल्वर" या स्टेजिंग में स्थानांतरित करते हैं। एक बिल्ड चलाया जाता है और परीक्षण फिर से चलाया जाता है। साप्ताहिक रूप से हम इन परिवर्तनों को अपने "सोने" या पेड़ के पेड़ पर धकेलते हैं और फिर उन्हें हमारी उत्पादन प्रणाली में तैनात करते हैं।

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

आपातकालीन सुधार सीधे सोने के पेड़ में बंद हो जाते हैं। यदि कोई परिवर्तन सरल है और QA के लिए कठिन है तो यह सीधे चांदी में जा सकता है जो परीक्षण पेड़ के लिए अपना रास्ता खोज लेगा।

हमारी रिहाई के बाद हम सब कुछ सिंक में रखने के लिए सोने (ठेस) में कांसे (परीक्षण) में बदलाव करते हैं।

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

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

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

यह भी ध्यान रखें कि हम पिछले रिलीज को बनाए नहीं रखते हैं। वर्तमान संस्करण हमेशा एकमात्र संस्करण है। यहां तक ​​कि आपके पास संभवतः एक मास्टर बेकिंग ट्री हो सकता है जहां आपके परीक्षक या समुदाय यह देख सकते हैं कि विभिन्न योगदानकर्ता सामान कैसे इंटरैक्ट करते हैं।

Answer 5

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

Answer 6

हमारी कंपनी में हम फुर्तीले विकास का उपयोग नहीं कर सकते हैं और व्यापार द्वारा हर परिवर्तन के लिए अनुमोदन की आवश्यकता है, यह बहुत सारे मुद्दों का कारण बनता है।

जीआईटी के साथ काम करने के लिए हमारा दृष्टिकोण यह है;

हमने अपनी कंपनी में "गिट फ्लो" लागू किया है। हम JIRA का उपयोग कर रहे हैं और केवल स्वीकृत JIRA टिकट को उत्पादन में जाना चाहिए। टेस्ट अनुमोदन के लिए हमने इसे एक अलग टेस्ट-ब्रांच बनाया।

JIRA टिकट संसाधित करने के चरण हैं:

1. विकास-शाखा से एक नई शाखा बनाएँ
2. सुविधा-शाखा पर कोड परिवर्तन करें
3. टेस्ट / क्यूए ब्रांच में फीचर चेंजेस से खींचो
4. व्यावसायिक अनुमोदन के बाद हम फीचर शाखा से बदलाव को विकसित करते हैं
5. विकास एक रिलीज में अक्सर जाता है और फिर अंत में मास्टर शाखा

प्रत्येक अनुरोध को स्वयं की सुविधा में विभाजित करना सुनिश्चित करता है, केवल स्वीकृत परिवर्तन ही उत्पादन में गए।

पूरी प्रक्रिया इस तरह दिखती है: