यैंडेक्स में निरंतर एकीकरण

बड़ी संख्या में डेवलपर्स के लिए उच्च उत्पादकता सुनिश्चित करते हुए एक विशाल कोड बेस बनाए रखना एक गंभीर चुनौती है। पिछले 5 वर्षों में, यैंडेक्स निरंतर एकीकरण के लिए एक विशेष प्रणाली विकसित कर रहा है। इस लेख में हम यैंडेक्स कोड आधार के पैमाने के बारे में बात करेंगे, विकास के लिए ट्रंक-आधारित दृष्टिकोण के साथ एकल रिपॉजिटरी में विकास को स्थानांतरित करने के बारे में, ऐसी परिस्थितियों में एक प्रभावी एकीकरण प्रणाली को प्रभावी ढंग से काम करने के लिए किन कार्यों को हल करना चाहिए।

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

कई कार्य जो हम हल करते हैं, वे ओपन-सोर्स दुनिया में हल नहीं होते हैं। कोई मैपआरड्यूस नहीं है जो हमारे वॉल्यूम (5000+ सर्वर) और हमारे कार्यों पर अच्छी तरह से काम करता है; कोई भी कार्य ट्रैकर नहीं है जो हमारे सभी दसियों लाख टिकटों को संभाल सकता है। यह यैंडेक्स में आकर्षक है - आप वास्तव में महान चीजें कर सकते हैं।

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

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

• घटक कहाँ है
• यह कैसे काम करता है: "लेने और पढ़ने" का कोई तरीका नहीं है
• अब इसका विकास और समर्थन कौन कर रहा है?
• इसका उपयोग कैसे शुरू करें?

परिणामस्वरूप, घटकों के पारस्परिक उपयोग की समस्या उत्पन्न हुई। घटक लगभग अन्य घटकों का उपयोग नहीं कर सकते थे क्योंकि वे एक दूसरे के लिए "ब्लैक बॉक्स" का प्रतिनिधित्व करते थे। इसने कंपनी को नकारात्मक रूप से प्रभावित किया, क्योंकि घटकों का न केवल पुन: उपयोग किया गया, बल्कि अक्सर सुधार नहीं हुआ। कई घटकों को डुप्लिकेट किया गया था, जिस कोड का समर्थन किया जाना था, वह काफी बढ़ रहा था। हम आम तौर पर धीमी गति से चले गए।

एकल भंडार और बुनियादी ढाँचा

5 साल पहले, हमने विधानसभा, परीक्षण, तैनाती और निगरानी के लिए सामान्य प्रणालियों के साथ विकास को एक एकल भंडार में स्थानांतरित करने के लिए एक परियोजना शुरू की।

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

परियोजना के परिणामस्वरूप, कंपनी के लिए बुनियादी ढाँचा प्रौद्योगिकियों का एक एकल हिस्सा उत्पन्न हुआ: स्रोत कोड भंडारण, कोड समीक्षा प्रणाली, निर्माण प्रणाली, निरंतर एकीकरण प्रणाली, तैनाती, निगरानी।

अब यैंडेक्स परियोजनाओं के लिए अधिकांश स्रोत कोड एक एकल भंडार में संग्रहीत किया जाता है, या इसे स्थानांतरित करने की प्रक्रिया में है:

• 2000 से अधिक डेवलपर परियोजनाओं पर काम करते हैं।
• 50,000 से अधिक परियोजनाएं और पुस्तकालय।
• रिपोजिटरी का आकार 25 जीबी से अधिक है।
• 3,000,000 से अधिक आवागमन पहले से ही भंडार के लिए प्रतिबद्ध हैं।

कंपनी के लिए प्लस:

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

यह भी समझा जाना चाहिए कि इस तरह के विकास मॉडल में नुकसान हैं जिन पर विचार करने की आवश्यकता है:

• एक साझा भंडार के लिए एक अलग, विशिष्ट बुनियादी ढांचे की आवश्यकता होती है।
• आपको जिस लाइब्रेरी की आवश्यकता है वह रिपॉजिटरी में नहीं हो सकती है, लेकिन यह ओपन-सोर्स में है। इसे जोड़ने और अपडेट करने की लागतें हैं। भारी भाषा और पुस्तकालय पर निर्भर, कहीं मुफ्त, कहीं बहुत महंगा।
• आपको कोड के "स्वास्थ्य" पर लगातार काम करने की आवश्यकता है। इसमें कम से कम अनावश्यक निर्भरता और मृत कोड के खिलाफ लड़ाई शामिल है।

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

एक सामान्य रिपॉजिटरी का मॉडल सभी बड़ी कंपनियों को प्रभावित करता है। अखंड भंडार एक बड़ा और अच्छी तरह से अध्ययन और चर्चा का विषय है, इसलिए अब हम इसमें ज्यादा नहीं जाएंगे। यदि आप अधिक जानना चाहते हैं, तो लेख के अंत में आपको कई उपयोगी लिंक मिलेंगे जो इस विषय को और अधिक विस्तार से प्रकट करते हैं।

ऐसी स्थितियाँ जिनमें निरंतर एकीकरण प्रणाली संचालित होती है

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

प्रोजेक्ट्स सोर्स कोड पर निर्भर करते हैं। परियोजनाएं और पुस्तकालय एक जटिल निर्भरता ग्राफ बनाते हैं। और इसका मतलब है कि एक परियोजना में किए गए बदलाव संभावित रूप से बाकी भंडार को प्रभावित करते हैं।

आवागमन की एक बड़ी धारा भंडार में जाती है:

• 2000 से अधिक प्रति दिन कमाता है।
• जल्दी घंटे के दौरान प्रति मिनट 10 परिवर्तन।

कोड आधार में 500,000 से अधिक निर्माण लक्ष्य और परीक्षण शामिल हैं।

ऐसी स्थितियों में निरंतर एकीकरण की एक विशेष प्रणाली के बिना, जल्दी से आगे बढ़ना बहुत मुश्किल होगा।

निरंतर एकीकरण प्रणाली

निरंतर एकीकरण प्रणाली प्रत्येक परिवर्तन के लिए विधानसभा और परीक्षण शुरू करती है:

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

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

असेंबली के परिणामों को प्राप्त करने और उनका विश्लेषण करने और परीक्षण चलाने के बाद, उपयोगकर्ता को प्रतिक्रिया मिलती है, उदाहरण के लिए, यदि परिवर्तन किसी भी परीक्षण को तोड़ते हैं।

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

निरंतर एकीकरण प्रणाली की विशेषताएं और क्षमताएं

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

परीक्षण के प्रकार और आकार

कई प्रकार के लक्ष्य हैं जिन्हें एक सतत एकीकरण प्रणाली ट्रिगर कर सकती है:

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

टेस्ट लॉन्च आवृत्ति और बाइनरी फॉल्ट डिटेक्शन

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

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

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

फ्लैशिंग टेस्ट डिटेक्शन

चमकती परीक्षण ऐसे परीक्षण हैं जिनके रन (पास / असफल) एक ही कोड पर परिणाम विभिन्न कारकों पर निर्भर हो सकते हैं। चमकती परीक्षणों के कारण अलग-अलग हो सकते हैं: परीक्षण कोड में नींद, मल्टीथ्रेडिंग के साथ काम करते समय त्रुटियां, बुनियादी ढांचे की समस्याएं (किसी भी सिस्टम की अनुपलब्धता), आदि। चमकती परीक्षण एक गंभीर समस्या पेश करते हैं:

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

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

हमारा वर्तमान एल्गोरिथ्म काफी सरल है और इस स्थान पर बहुत सारे सुधारों की योजना बनाई गई है। सबसे पहले, हम बहुत अधिक उपयोगी संकेतों का उपयोग करना चाहते हैं।

परीक्षण इनपुट का स्वचालित अद्यतन

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

डेटा पुराना न हो जाए, इसके लिए निरंतर एकीकरण प्रणाली इसे स्वचालित रूप से अपडेट कर सकती है। यह कैसे काम करता है?

1. टेस्ट डेटा संसाधनों के एक विशेष भंडारण में संग्रहीत किया जाता है।
2. परीक्षण में आवश्यक इनपुट का वर्णन मेटाडेटा शामिल है।
3. आवश्यक परीक्षण इनपुट और संसाधनों के बीच पत्राचार एक निरंतर एकीकरण प्रणाली में संग्रहीत किया जाता है।
4. डेवलपर रिसोर्स स्टोर को नए डेटा की नियमित डिलीवरी प्रदान करता है।
5. निरंतर एकीकरण प्रणाली संसाधन रिपॉजिटरी में परीक्षण डेटा के नए संस्करणों की खोज करती है और इनपुट डेटा को स्विच करती है।

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

इसलिए, हम इसे बनाते हैं ताकि कमिट का कुछ अंतराल हो, जिस पर परीक्षण पुराने और इनपुट डेटा के नए संस्करणों के साथ लॉन्च किया गया है।

कठिन परीक्षण

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

डेटा-संचालित परीक्षण में मानक दृष्टिकोण निम्नानुसार है। जब परीक्षण पहली बार चलाया गया था तो परीक्षण का एक संदर्भ परिणाम प्राप्त हुआ है। संदर्भ परिणाम परीक्षण के बगल के भंडार में संग्रहीत किया जा सकता है। परीक्षण के बाद के रन उसी परिणाम का उत्पादन करना चाहिए।

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

बड़े प्रवाह वाले बड़े भंडार में इस दृष्टिकोण का उपयोग करते समय कठिनाइयाँ होती हैं:

1. कई परीक्षण हो सकते हैं और परीक्षण बहुत मुश्किल हो सकते हैं। डेवलपर के पास काम के माहौल में सभी प्रभावित परीक्षणों को चलाने की क्षमता नहीं है।
2. परिवर्तन करने के बाद, परीक्षण टूट सकता है यदि संदर्भ परिणाम कोड में परिवर्तन के साथ एक साथ अपडेट नहीं किया गया था। फिर एक और डेवलपर उसी घटक में बदलाव कर सकता है और परीक्षा परिणाम फिर से बदल जाएगा। हमें एक त्रुटि का दूसरे पर आरोपण मिलता है। ऐसी समस्याओं से निपटना बहुत मुश्किल है, डेवलपर्स से समय लगता है।

हम क्या कर रहे हैं? डिफ टेस्ट में 2 भाग होते हैं:

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

निरंतर एकीकरण प्रणाली द्वारा चेक और डिफरेंट कंपोनेंट्स के लॉन्च को नियंत्रित किया जाता है।

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

जारी रखा जाए

अगले लेख में हम बात करेंगे कि निरंतर एकीकरण की प्रणाली कैसे काम करती है।

संदर्भ

अखंड भंडार, ट्रंक-आधारित विकास

• मोनोरपो - विकिपीडिया
• https://trunkbaseddevelopment.com

डेटा चालित परीक्षण

• डेटा-चालित परीक्षण - विकिपीडिया