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