क्या कोई सीआई उपकरण है जो शाखा गुणवत्ता स्तर में कोई प्रतिगमन की गारंटी नहीं देता है?


10

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

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

क्या कोई CI उपकरण वास्तव में ऐसे प्रतिगमन को रोकने में सक्षम है , जो पूर्व-प्रतिबद्ध QA सत्यापन करेगा और केवल तभी अनुमति देगा जब संबंधित कमिट के साथ अद्यतन किया गया कोडबेस उन पूर्व-प्रतिबद्ध QA सत्यापनों को भी पारित कर देगा, इस प्रकार न्यूनतम गारंटी देता है शाखा गुणवत्ता स्तर?

अद्यतन: धारणा यह है कि संबंधित कवरेज को पता लगाने में सक्षम होने के लिए उपयुक्त कवरेज के साथ उपयुक्त स्वचालित क्यूए सत्यापन सीआई उपकरण (ओं) द्वारा मंगलाचरण के लिए उपलब्ध हैं।


मैं इस प्रश्न को समझने के सही तरीके के बारे में सोचता रहता हूं (और आपके अपने जवाब में आपकी खुद की सिफारिश)। अगर मैं "मॉनिटरिंग" को "तथ्यों के बाद", और "रोकने" को "होने से रोकने" के साथ बदल दूंगा, तो क्या कमोबेश यही सवाल होगा? इसके अलावा, शायद आप अंतर समझाने के लिए कुछ उदाहरण परिदृश्य जोड़ सकते हैं?
Pierre.Vriens

@ पियरे.वीयर क्या यह कोई बेहतर है?
डैन कॉर्निलेस्कु

जवाबों:


6

जहाँ तक मैं बता सकता हूँ, आप एक ऐसे उपकरण की तलाश कर रहे हैं, जो निर्माण को तोड़ने वाले कमिट को अस्वीकार कर दे- एक CI टूल संभवतः आपके कोड को ठीक करने से प्रतिगमन को रोकने में सक्षम नहीं होगा, लेकिन यह आपको खराब कोड जोड़ने से रोक सकता है रिपॉजिटरी को।

एटलसियन में गिट हुक के कुछ दिलचस्प अनुप्रयोग हैं :

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

यदि आप Git का उपयोग कर रहे हैं, तो हुक बहुत शक्तिशाली हैं (और SVN , Mercurial और अन्य संस्करण नियंत्रण प्रणालियों के लिए समान हुक हैं ), और आपको पूर्व-प्रतिबद्ध जांच चलाने के लिए उनका उपयोग करना उपयोगी लग सकता है।

Git प्रलेखन में पुश को अस्वीकार करने के लिए एक हुक बनाने पर एक पृष्ठ होता है यदि वे एक निश्चित मापदंड को पूरा नहीं करते हैं जो आसानी से इस उपयोग-मामले के लिए अनुकूलित किया जा सकता है।

हालांकि, बहुत से लोग यह तर्क देंगे कि कमिट्स को अस्वीकार करना एक featureशाखा पर एक बुरा विचार है -आप वास्तव में बग को ठीक करने के बजाय किसी कारण से निर्माण के टूटने पर अपने CI सिस्टम से लड़ने में समय बर्बाद कर रहे होंगे।

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


ठीक है, जो एक अच्छी छवि है जो बनाता है, लेकिन संभावित परीक्षण से डीओए है? यदि वे निर्माण करते हैं तो भी देवता उनके कोड परिवर्तनों का परीक्षण नहीं कर सकते हैं, इसलिए वे अवरुद्ध के समान होंगे। इसलिए सामान्य तौर पर मैं किसी भी चीज के लिए अस्वीकृति का विस्तार करूंगा जो कि न्यूनतम QA चेक को विफल करता है, 2 परस्पर विरोधी आवश्यकताओं को संतुलित करके चुना गया है: ब्लॉकिंग से संरक्षित देवों की संख्या को अधिकतम करने के लिए जितना संभव हो उतना कम और जितना संभव हो उतना कम क्यूए सत्यापन देरी से डॉन 'प्रक्रिया को बहुत धीमा कर दें।
डैन कॉर्निलेस्कु

इसका एक उदाहरण पुल अनुरोध मॉडल हो सकता है जहां आप एक पुल अनुरोध को मर्ज किया जा सकता है या नहीं इस पर कुछ प्रतिबंध लगा सकते हैं। उदाहरण के लिए, हम (मेरी कंपनी) Atlassian Bitbucket Server का उपयोग करते हैं और पुल अनुरोध को मर्ज करने की अनुमति देने से पहले दिए गए शाखा के लिए कम से कम N संख्या की स्वीकृति और X नंबर पासिंग बिल्ड की संख्या की आवश्यकता होती है। यह एकमुश्त इसे अस्वीकार नहीं करता है। लेकिन जब परीक्षण विफल हो जाता है या अन्य आँखों ने अभी तक कोड नहीं देखा है तो आकस्मिक विलय को रोकता है।
एंडी शिन

@AndyShinn: हाँ, मुझे पता है कि काफी उपयोगी है- GitHub भी पुल अनुरोधों पर संरक्षित शाखाएं और चेक प्रदान करता है , जो अक्सर मददगार होते हैं।
औरोरा ००००

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

2

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

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

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


"यदि एक शाखा अपने अपस्ट्रीम (जहां पीआर विलय कर रही है) के साथ अप-टू-डेट है, और उसके परीक्षण पास हो जाते हैं, तो वे मर्ज के बाद भी पास होंगे" - क्यों? एक मर्ज एक असंतोष है, यह अज्ञात लाता है। संघर्ष की तरह - कोड का निर्माण भी नहीं हो सकता है जब तक वे हल नहीं होते हैं। आपको परीक्षण चलाने और यह पुष्टि करने की आवश्यकता है कि वे किसी भी शाखा मर्ज के लिए पास हैं। अगर आप इसे सुरक्षित खेलना चाहते हैं, तो मैं एक तेज़-फ़ॉरवर्ड के लिए भी कहूंगा। इसके अलावा देखें swsw.com/insights/2016/11/16/…
Dan Cornilescu

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

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

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

मेरा कहना यह है कि यह उस सुरक्षा की पेशकश करने वाला सीआई उपकरण नहीं है, यह आप है, परीक्षण लिखकर। CI टूल आपके द्वारा प्रदान किए जाने वाले परीक्षणों से परे कोई गारंटी नहीं दे सकता है।
एड्रियन

1

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


लेकिन Reitveld एक सहयोगी कोड समीक्षा उपकरण प्रतीत होता है, न कि CI उपकरण, क्या मुझे कुछ याद आ रहा है? मैंने यही देखा: github.com/rietveld-codereview/rietveld
Dan Cornilescu

ज़ूल वास्तव में संबंधित प्रतीत होता है, मैं इसका अध्ययन करूंगा।
डैन कॉर्निलेस्कु

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

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

1

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


यह काम करता है, लेकिन केवल तभी जब आप पिछले मर्ज के पूरा होने से पहले क्यूए चेक शुरू करने के लिए 2 मर्ज की अनुमति नहीं देते हैं, अन्यथा 2 मर्ज 1 को नहीं देखेंगे, जो रेजीमेंट के लिए जगह छोड़ देंगे। दूसरे शब्दों में मर्ज (उनके क्यूए चेक सहित) पूरी तरह से क्रमबद्ध होना चाहिए, जो बड़ी टीमों के लिए पैमाने पर नहीं है।
डैन कॉर्निलेस्कु

0

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

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

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

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

डिस्क्लेमर: मैं टूल का लेखक हूं और कंपनी के संस्थापक इसे पेश करते हैं। विज्ञापन के लिए क्षमा याचना।


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

मैंने मेटा पर एक प्रश्न पूछा है कि क्या इसकी अनुमति है या नहीं: meta.devops.stackexchange.com/q/59
12

SnapCI ने भी ऐसा किया। आरआईपी।
पौल_ हं

@paul_h, जब तक कि मैं कुछ SnapCI को याद नहीं कर रहा हूँ और इसकी अनुशंसित प्रतिस्थापन GoCD दोनों पोस्ट-कमिटमेंट्स सत्यापन (SCM मतदान द्वारा ट्रिगर) पर आधारित हैं, तो वे अभी भी निगरानी कर रहे हैं। शायद पीआर चेक को छोड़कर, लेकिन जब तक इन चेक को पूरी तरह से क्रमबद्ध नहीं किया जाता है, तब तक वे केवल प्रतिगमन घटना दर को कम कर सकते हैं, लेकिन उन्हें पूरी तरह से समाप्त नहीं कर सकते हैं।
Dan Cornilescu

दान, मतदान नहीं, हुक नहीं। और एक अल्पकालिक पीआर शाखा में जो अभी तक ट्रंक / मास्टर में विलय नहीं हुई है - trunkbaseddevelopment.com/game-changers/…
paul_h
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.