कहां क्यूए टीम को गिटफ्लो ब्रांचिंग मॉडल में परीक्षण करना चाहिए


23

हम एक बड़ी टीम (10-12 डेवलपर्स और 4 क्यूए) एक ही गिट रिपॉजिटरी के साथ कई परियोजनाओं पर काम कर रहे हैं। इसका स्प्रिंग बूट आधारित बैकएंड वेब सेवा है। हम एक अच्छी गिट शाखा और तैनाती की रणनीति की तलाश कर रहे हैं। हमारे पास एक क्यूए टीम भी है जो यह सुनिश्चित करती है कि हमारी विशेषताएं अपेक्षित रूप से काम कर रही हैं (कुछ हद तक बग मुक्त)।

कुछ लेखों को पढ़ने के बाद, मुझे लगा कि Gitflow मॉडल हमारे लिए अच्छा काम करेगा। यहाँ मेरा सवाल आता है।

हमारी क्यूए टीम को हमारी सुविधाओं का परीक्षण कहां करना चाहिए?

  1. क्या उन्हें फीचर शाखा पर परीक्षण करना चाहिए, जहां वे बग को बढ़ाएंगे और डेवलपर इसे ठीक कर देंगे और एक बार जब यह क्यूए परीक्षा पास कर लेता है तो हम इसे विकसित करने के लिए विलय कर देते हैं। और QA फिर से विकसित शाखा में पूर्णांक परीक्षण करेगा।
  2. क्या हमें शाखा को विकसित करने और वहां से क्यूए परीक्षण करने के लिए सभी सुविधाओं (इकाई परीक्षणों और डेवलपर से मूल परीक्षण के बाद) को मर्ज करना चाहिए। फिक्स और परीक्षण सभी के रूप में अच्छी तरह से विकसित होगा।

मैं यह सुनने के लिए उत्सुक हूं कि दूसरों के लिए किस दृष्टिकोण ने अच्छा काम किया।

जवाबों:


14

QA को संभवतः दो बार परीक्षण करना चाहिए।

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

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

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


2
कुछ दृष्टिकोण जो मुझे इस दृष्टिकोण के साथ हैं 1) प्रत्येक सुविधा को तैनात करने के लिए एक मशीन की आवश्यकता होगी। कभी-कभी हम 5 सुविधाओं पर काम करते हैं कुछ समय केवल युगल। हम वीएम को स्पिन करने के लिए जेनकींस सेटअप कर सकते हैं? हर कोई क्या करता है? 2) क्यूए को यह जानना होगा कि कौन सी मशीन किस मशीन पर है। 3) मुझे आश्चर्य है कि क्या इसके निरर्थक के रूप में हम रिलीज शाखा में पूरी तरह से परीक्षण करने जा रहे हैं या नहीं।
श्रीनि

4

बड़ा सवाल है। मुझे नहीं लगता कि इसके लिए कोई 'आधिकारिक' सही उत्तर है। यह इस बात पर निर्भर करता है कि आप कितनी तेजी से परीक्षण कर सकते हैं।

आवश्यक समस्या यह है कि प्रत्येक मर्ज, संकलन या यहां तक ​​कि तैनाती, संभवतः एक बग बना सकती है। आपके द्वारा परीक्षण की जाने वाली श्रृंखला 'अप' के लिए, जितनी जल्दी आप बग्स के बारे में जानते हैं, उतनी ही बार आपको फिर से परीक्षण करना होगा।

यह सुनिश्चित करने के लिए कि आपने सॉफ़्टवेयर का परीक्षण किया है, जिसका उपयोग ग्राहक वास्तव में कर रहे हैं, आपको ग्राहकों की ट्रैफ़िक (वेब ​​ऐप मानकर) ब्लू / ग्रीन परिनियोजन पैटर्न के माध्यम से रूट करने से पहले लाइव परिनियोजन का परीक्षण करना होगा।

लेकिन जाहिर है यह दिन में थोड़ी देर है जब आपने पहली बार कोड की जांच की थी!

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

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

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

अपने अनुभव से मैं सुझाऊंगा:

देव मशीन पर सुविधा शाखा का त्वरित परीक्षण। बस इसकी सुविधा पूरी सुनिश्चित करें और परीक्षक / देवता इस बात पर सहमत हों कि आवश्यकताओं का क्या मतलब है।

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

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

(भक्तों का कहना है कि आपको स्प्रिंट 2 में केवल बग सुधार करना चाहिए लेकिन व्यावहारिक होने देना चाहिए)

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


-2

मैं थॉमस ओवेन्स से सहमत हूं। आपको शायद दो बार परीक्षण करना चाहिए। एक बार फीचर शाखा में विलय होने से पहले और एक बार रिलीज होने से पहले अपनी मुख्य शाखा पर।

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

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

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


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

यह आपके गैर-फॉस उपकरण के लिए एक विज्ञापन की तरह लग रहा था, इसलिए डाउनवोट्स। मैं आपको एक और एक देता, अगर मैं कर सकता था।
जोहान्सम
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.