Git में परीक्षण शाखाओं का उपयोग करना

Question

हमारे पास कोई है (चलो उसे टेड कहते हैं) जो नई सुविधाओं और बग फिक्स के परीक्षण के लिए जिम्मेदार है।

हम Git और GitHub का उपयोग कर रहे हैं । masterहोना चाहिए / हमेशा तैनात रहता है और developmentहम नई सुविधाओं या बग फिक्स के लिए प्रतिबद्ध / मर्ज करते हैं, लेकिन उसके बाद ही वे टेड द्वारा परीक्षण किए गए हैं।

परियोजना PHP में है।

मुझे इस तरह से जाने के लिए परीक्षण प्रक्रिया चाहिए:

1. डेवलपर तो वह खींचती है, (चलो कहते हैं कि सुविधा / बग # 123 टेड के रूप में समस्या ट्रैकर में प्रलेखित) एक नई सुविधा पर काम करना चाहता है origin/developmentके लिए developmentअपने स्थानीय भंडार पर और एक नई शाखा (मान लें कि बनाता है issue-123) से वहाँ।
2. एक बार जब वह अपने काम से खुश हो जाता है, तो वह अपनी नई शाखा को भेजता है और धक्का देता है origin।
3. टेड कनेक्ट होने test.ourproject.com/choose-branchवाली शाखाओं की सूची को देखता है originऔर चालू करने का विकल्प चुनता है issue-123(यह वेबपृष्ठ के माध्यम से संभव होना चाहिए)। फिर वह चला जाता है test.ourproject.com, वेब एप्लिकेशन से नर्क का परीक्षण करता है (वह वास्तव में दयनीय है) और डेवलपर के साथ कुछ आगे-पीछे होने के बाद, वह सुविधा से खुश है।
4. टेड डेवलपर कि वह विलय कर सकते हैं बताता है issue-123पर developmentपर origin।
5. धोये और दोहराएं।

तीसरे चरण के लिए, मैं कुछ ऐसा कर सकता हूं जो काम करता है (एक विशिष्ट पृष्ठ से शाखाओं को दिखाना और स्विच करना), लेकिन मुझे लगता है कि मैंने जो वर्णन किया है वह एक बहुत ही सामान्य पैटर्न है।

तो मेरा सवाल है: क्या यह ब्रांचिंग के लिए एक अच्छा / टिकाऊ / बनाए रखने योग्य वर्कफ़्लो है? क्या आप इस वर्कफ़्लो के बाद अन्य प्रोजेक्ट्स के कुछ उदाहरणों का हवाला देकर अपना जवाब दे सकते हैं?

Comments

"वेबैप से नरक का परीक्षण करता है (वह वास्तव में लापरवाह है) और देव के साथ कुछ आगे-पीछे होने के बाद, वह इस सुविधा से खुश है।" - यह व्यक्ति प्रतिभा के करीब होना चाहिए। क्या वह वास्तव में जानता है कि प्रश्न में कोड क्या है? इस तरह की परियोजनाएं हैं लेकिन मुझे चरण 3 के परिणामों में वास्तव में संदेह है।

— SChepurin

मुझे issue-123बग / फ़ीचर # 123 के संदर्भ को स्पष्ट करना चाहिए था क्योंकि टेड दस्तावेज़ हर बग / नई सुविधा को हमारे इश्यू ट्रैकर पर रखते थे।

— cpa

@ सीपीए: इसे स्पष्ट करें। प्रश्न संपादन योग्य हैं।

— Jan Hudec

@SChepurin: परीक्षक को कोड के बारे में कुछ भी जानने की आवश्यकता नहीं है। उन्हें केवल आवश्यक सुविधाओं और बगों की सूची और उनके लिए परीक्षण मामलों की आवश्यकता है।

— Jan Hudec

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

— MJS

Answer 1

शाखा वर्कफ़्लो बहुत कुछ लगता है जैसे gitflow http://jeffkreeftmeijer.com/2010/why-arent-you-use-git-flow और इसके चारों ओर सपोर्ट टूल हैं। यह अत्यधिक अनुशंसित है।

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

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

मैं http://sethrobertson.github.com/GitBestPractices/ पढ़ने की सिफारिश करना चाहता हूं, जिसमें इन सभी मामलों पर चर्चा की गई है और कई अच्छे संदर्भ हैं।

Comments

git-flowबिल्कुल वैसा नहीं है जैसा मैं देख रहा था, लेकिन यह निश्चित रूप से कुछ है जिसकी हमें ज़रूरत है! धन्यवाद!

— cpa

Answer 2

मुझे यकीन नहीं है कि स्विचिंग पेज ही एक सामान्य पैटर्न है। अधिकांश परियोजनाओं में संभवत: बस परीक्षक के पास इसे git कमांड से जांचना होता है।

सामान्य दृष्टिकोण निश्चित रूप से उचित लगता है।

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

Git स्वयं थीम पर थोड़ी भिन्नता का उपयोग करता है। यह अनुरक्षक के पास एक स्क्रिप्ट है जो सभी लंबित सबमिशन को एक शाखा में विलय कर देता है जिसे pu"प्रस्तावित अद्यतनों के लिए" कहा जाता है , संभवतः शाखा को हटा दिया जाता है और प्रत्येक बार फिर से बनाया जाता है क्योंकि लंबित प्रस्तुतियाँ अक्सर छूट होती हैं)। यह विभिन्न लोगों द्वारा परीक्षण की तुलना में है। यदि यह ठीक है, तो जिन सबमिशन को पूरा माना जाता है, उनमें विलय हो जाता है next(यह आपके जैसा ही है development)। यदि नहीं, तो किसी ने अलग-अलग प्रस्तुतियाँ का परीक्षण करने के लिए यह देखने के लिए कि कौन सा टूट गया है। यह परीक्षक के लिए थोड़ा आसान हो जाता है क्योंकि उन्हें ज्यादातर समय शाखाएं बंद नहीं करनी पड़ती हैं; वे बस रिपोर्ट करते हैं कि क्या परीक्षण एकीकरण काम करता है।

Answer 3

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

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

यदि कमिट को शाखा में जोड़ा जाता है, तो परीक्षण फिर से चलाए जाते हैं। (हालांकि किसी कारण से मास्टर को जोड़ने से परीक्षणों को फिर से चलाने के लिए प्रतीत नहीं होता है।)

Comments

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

— ऐश

@Ash कोड को वास्तव में मास्टर में विलय नहीं किया गया है; जैसा कि मैं समझता हूं कि परीक्षण अनिवार्य रूप से एक अस्थायी शाखा पर चलाए जाते हैं जो कि शाखा-परीक्षण को मास्टर में विलय करने का परिणाम है।

— MJS