पुराने दिनों में, हमारे पास केवल कुछ सेवाएं थीं, और एक दिन में उत्पादन में उनमें से एक से अधिक को अपडेट करना एक बड़ी
सफलता थी । फिर दुनिया में तेजी आई, प्रणाली और अधिक जटिल हो गई, और हम एक संगठन में बदल गए, जिसमें माइक्रोसिस्टवर्क वास्तुकला थी। अब हमारे पास लगभग सौ सेवाएं हैं, और उनकी संख्या में वृद्धि के साथ, रिलीज की आवृत्ति भी बढ़ जाती है - प्रति सप्ताह 250 से अधिक हैं।
और अगर उत्पाद टीमों के अंदर नई विशेषताओं का परीक्षण किया जाता है, तो एकीकरण परीक्षण टीम का कार्य यह सत्यापित करना है कि रिलीज में शामिल परिवर्तन घटक, सिस्टम और अन्य सुविधाओं की कार्यक्षमता को नहीं तोड़ते हैं।
मैं Yandex.Money में एक परीक्षण स्वचालन इंजीनियर के रूप में काम करता हूं।
इस लेख में, मैं वेब सेवाओं के एकीकरण परीक्षण के विकास के साथ-साथ सिस्टम घटकों की संख्या बढ़ाने और रिलीज की आवृत्ति बढ़ाने के लिए प्रक्रिया को अपनाने के बारे में बात करूंगा।
पिछले चक्र में से
एक में ऑप्स और देव द्वारा गणना चक्र के परिवर्तन और गणना तंत्र के विकास के बारे में बताया गया
था । मैं आपको इस परिवर्तन के दौरान परीक्षण प्रक्रियाओं में हुए परिवर्तनों के इतिहास के बारे में बताऊंगा।
अब हमारे पास लगभग 30 विकास दल हैं। टीम में आमतौर पर उत्पाद प्रबंधक, परियोजना प्रबंधक, फ्रंट-एंड और बैक-एंड डेवलपर्स और परीक्षक शामिल होते हैं। वे एक विशिष्ट उत्पाद के लिए कार्यों पर काम करके एकजुट होते हैं। सेवा के लिए, एक नियम के रूप में, टीम जिम्मेदार है, जो अक्सर इसमें बदलाव करती है।
एंड-टू-एंड स्वीकृति परीक्षण
बहुत समय पहले, प्रत्येक घटक की रिहाई के साथ, केवल इकाई- और घटक परीक्षण चलाए गए थे, और उसके बाद उत्पादन में सेवा डालने से पहले पूर्ण-से-अंत परीक्षण वातावरण पर केवल कुछ सबसे महत्वपूर्ण अंत-टू-एंड स्क्रिप्ट चलाए गए थे। घटकों की संख्या में वृद्धि के साथ, उनके बीच कनेक्शन की संख्या तेजी से बढ़ने लगी। अक्सर - पूरी तरह से गैर-तुच्छ कनेक्शन। मुझे याद है कि कैसे विपणन डेटा जारी करने के लिए सेवा की अनुपलब्धता ने उपयोगकर्ता पंजीकरण को पूरी तरह से (निश्चित रूप से थोड़े समय के लिए) तोड़ दिया।
परिवर्तनों की जाँच करने के लिए यह दृष्टिकोण अधिक से अधिक बार विफल होने लगा - इसके लिए ऑटोटैस्ट के साथ सभी महत्वपूर्ण व्यावसायिक परिदृश्यों को शामिल करना और उन्हें पूर्ण संस्करण के परीक्षण वातावरण पर चलाने के लिए आवश्यक था, जो रिलीज के लिए एक घटक संस्करण के साथ तैयार था।
ठीक है, महत्वपूर्ण परिदृश्यों के लिए ऑटोटैस्ट दिखाई दिए हैं - लेकिन उन्हें कैसे चलाना है? रिलीज़ चक्र में एकीकृत करने के लिए एक कार्य था, कम से कम झूठी परीक्षण बूंदों के साथ इसकी विश्वसनीयता को प्रभावित करना। दूसरी ओर, मैं एकीकरण परीक्षण चरण को जल्द से जल्द पूरा करना चाहता था। इसलिए स्वीकृति परीक्षण करने के लिए एक बुनियादी ढांचा था।
हमने क्रमशः रिलीज़ चक्र और लॉन्च कार्यों पर घटक का अधिकतम उपयोग करने के लिए उपकरणों का अधिकतम उपयोग करने की कोशिश की: क्रमशः जीरा और जेनकींस।
स्वीकृति परीक्षण चक्र
स्वीकृति परीक्षण करने के लिए, हमने निम्नलिखित चक्र निर्धारित किया:
- एक रिलीज की स्वीकृति परीक्षण के लिए आने वाले कार्यों की निगरानी,
- परीक्षण वातावरण पर रिलीज़ बिल्ड स्थापित करने के लिए जेनकींस नौकरी चलाना,
- जाँच लें कि सेवा में तेजी आई है,
- एकीकरण परीक्षण के साथ जेनकींस की नौकरी शुरू की,
- रन के परिणामों का विश्लेषण,
- दोहराया परीक्षण रन (यदि आवश्यक हो),
- कार्य की स्थिति को अपडेट करना - पूरा या टूटा हुआ, टिप्पणी में कारण का संकेत।
पूरे चक्र को हर बार मैन्युअल रूप से प्रदर्शन किया गया था। नतीजतन, पहले से ही एक दिन में दसवीं रिलीज पर, मैं एक ही काम करने की कसम खाना चाहता था, सबसे अच्छा, अपनी सांस के तहत, मेरे सिर को पकड़कर और वेलेरियन
बीयर की मांग करना।
मॉनिटर बॉट
हमने महसूस किया कि जीरा में नए कार्यों को ट्रैक करना और रिपोर्ट करना महत्वपूर्ण प्रक्रियाएं हैं जो त्वरित और स्वचालित करने में आसान हैं। तो एक बॉट था जो ऐसा करता है।
अलर्ट जनरेट करने का डेटा जीरा के पुश नोटिफिकेशन के रूप में आता है। बॉट लॉन्च करने के बाद, हमने डैशबोर्ड पेज को स्वीकृति कार्यों के साथ अपडेट करना बंद कर दिया, और ऑटोमेटन की मुस्कान की चौड़ाई थोड़ी बढ़ गई।
Pinger
हमने सत्यापन को सरल बनाने का फैसला किया कि परीक्षण के वातावरण में तैनाती के दौरान कोई असेंबली या इंस्टॉलेशन त्रुटियां नहीं हुईं और यह कि घटक का वांछित संस्करण उठाया गया था, और कुछ अन्य नहीं। घटक HTTP के माध्यम से इसका संस्करण और स्थिति देता है। और जाँचना कि सेवा सही संस्करण लौटाती है सरल और समझ में आता है यदि विभिन्न घटकों को विभिन्न भाषाओं में नहीं लिखा गया है - कुछ Node.js में, कुछ C # में। इसके अलावा, जावा में हमारी सबसे लोकप्रिय सेवाओं ने भी एक अलग प्रारूप में संस्करण दिया।
इसके अलावा, मैं न केवल संस्करण परिवर्तनों के बारे में वास्तविक समय की जानकारी और सूचनाएं चाहता था, बल्कि सिस्टम में घटकों की उपलब्धता में बदलाव के बारे में भी जानना चाहता था। इस समस्या को हल करने के लिए, पिंजर सेवा दिखाई दी, जो चक्रीय रूप से मतदान करके घटकों की स्थिति और संस्करण के बारे में जानकारी एकत्र करती है।
हम संदेश वितरण के एक पुश मॉडल का उपयोग करते हैं - एक एजेंट को परीक्षण वातावरण के प्रत्येक उदाहरण पर तैनात किया जाता है, जो इस पर्यावरण के घटकों के बारे में जानकारी एकत्र करता है और हर 10 सेकंड में केंद्रीय नोड पर डेटा संग्रहीत करता है। हम वर्तमान स्थिति के लिए इस नोड पर जाते हैं - यह दृष्टिकोण हमें सौ से अधिक परीक्षण खड़ा करने की अनुमति देता है।
लॉकर
अधिक जटिल कार्यों के लिए समय आ गया है - घटकों का स्वत: अद्यतन और परीक्षण चल रहा है। उस समय, हमारी टीम के पास पहले से ही स्वीकृति परीक्षणों के लिए ओपनस्टैक में 3 परीक्षण बेंच थे, और पहले परीक्षण बेंच के संसाधनों के प्रबंधन की समस्या को हल करना आवश्यक था: सिस्टम पर परीक्षण चलाने के दौरान अगली रिलीज़ "रोल" का अद्यतन होने पर यह अप्रिय होगा। यह भी होता है कि परीक्षण बेंच को डिबग किया जाता है, और फिर आपको इसे स्वीकृति के लिए उपयोग नहीं करना चाहिए।
मैं रोजगार की स्थिति को देखने में सक्षम होना चाहता था और, यदि आवश्यक हो, तो मैन्युअल रूप से गिर परीक्षण के विश्लेषण की अवधि के लिए या अन्य काम पूरा होने तक स्टैंड को लॉक करना चाहिए।
इस सब के लिए, लॉकर सेवा दिखाई दी है। यह लंबे समय तक परीक्षण बेंच की स्थिति को बनाए रखता है ("व्यस्त" / "मुक्त"), आपको "व्यस्त" पर एक टिप्पणी निर्दिष्ट करने की अनुमति देता है, ताकि यह स्पष्ट हो कि हम अब डिबगिंग कर रहे हैं, परीक्षण वातावरण की प्रतिलिपि बना रहे हैं या अगली रिलीज़ के लिए परीक्षण चला रहे हैं। हमने रात में भी स्टैंड को ब्लॉक करना शुरू कर दिया - उन पर प्रशासक एक शेड्यूल पर काम करते हैं, जैसे बैकअप और डेटाबेस सिंक्रोनाइज़ेशन।
ब्लॉक करते समय, समय हमेशा सेट होता है जिसके बाद ताला समाप्त हो जाता है - अब लोगों को उपलब्ध पूल में खड़े होने में भाग लेने की आवश्यकता नहीं है, और मशीन सब कुछ करती है।
कर्तव्य
परीक्षण रन के परिणामों का विश्लेषण करने के लिए टीम के सदस्यों के बीच लोड को समान रूप से वितरित करने के लिए, हम दैनिक बदलाव के साथ आए। परिचर रिलीज की स्वीकृति परीक्षण के कार्यों के साथ काम करता है, पार्स गिर गया ऑटोटेस्ट और रिपोर्ट बग। यदि परिचर यह समझता है कि वह कार्यों के प्रवाह का सामना नहीं कर रहा है, तो वह टीम से मदद मांग सकता है। इस समय, टीम के बाकी कार्य उन कार्यों में लगे हुए हैं जो रिलीज़ से संबंधित नहीं हैं।
रिलीज़ की संख्या में वृद्धि के साथ, दूसरी परिचर की भूमिका दिखाई दी, जो मुख्य से जुड़ती है यदि रुकावटें हैं या कतार में महत्वपूर्ण रिलीज़ हैं। परीक्षण रिलीज़ की प्रगति के बारे में जानकारी प्रदान करने के लिए, हमने "ओपन" / "रनिंग" / "ड्यूटी पर प्रतिक्रिया के लिए प्रतीक्षा" में कार्यों की संख्या के साथ एक पेज बनाया, जिसमें कहा गया है, परीक्षण स्टैंड की स्थिति और स्टैंड पर दुर्गम घटकों की स्थिति।
कर्तव्य अधिकारी के काम में एकाग्रता की आवश्यकता होती है, इसलिए उसके पास एक बान है - कर्तव्य के दिन, वह कार्यालय के पास पूरी टीम के लिए दोपहर के भोजन के लिए जगह चुन सकता है। शैली में ड्यूटी पर रिश्वत विशेष रूप से मज़ेदार लगती है: "मुझे कार्यों को सुलझाने में आपकी मदद करने दें, और आज हम
अपनी पसंदीदा जगह पर जाएँगे" =)
रिपोर्टर
जब हमने घड़ी को पेश किया था, तो एक कार्य को एक अधिकारी से दूसरे में ज्ञान को स्थानांतरित करने की आवश्यकता थी, उदाहरण के लिए, एक नई रिलीज़ पर गिरने वाले परीक्षण या एक घटक को अपडेट करने की बारीकियों के बारे में।
इसके अलावा, हमारे पास काम की नई विशेषताएं हैं।
- परीक्षणों की एक श्रेणी थी जो परीक्षण बेंचों की समस्याओं के कारण अधिक या कम आवृत्ति के साथ आती है। सेवाओं में से एक की वृद्धि हुई प्रतिक्रिया समय या ब्राउज़र में संसाधनों की लंबी लोडिंग के कारण फॉल्स हो सकता है। मैं परीक्षण बंद नहीं करना चाहता; उनकी विश्वसनीयता बढ़ाने के वाजिब साधन समाप्त हो गए हैं।
- हमारे पास ऑटोटैस्ट्स के साथ एक दूसरी, प्रायोगिक परियोजना थी और एल्योर रिपोर्ट को देखते हुए एक बार में दो परियोजनाओं के रनों का विश्लेषण करने की आवश्यकता उत्पन्न हुई।
- एक परीक्षण रन में 20 मिनट लग सकते हैं, और आप पहली बूंदों की शुरुआत के तुरंत बाद परिणामों का विश्लेषण शुरू करना चाहते हैं। विशेष रूप से यदि कार्य महत्वपूर्ण है और रिलीज के लिए जिम्मेदार टीम के सदस्य
चाकू के साथ गले में दयनीय आँखों के साथ खड़े हैं।
इस तरह से रिपोर्टर सेवा के बारे में आया। इसमें हम परीक्षण प्रक्रिया के दौरान परीक्षण के परिणामों को वास्तविक समय में आगे बढ़ाते हैं। सेवा में ज्ञात समस्याओं या बग का एक डेटाबेस है जो एक विशिष्ट परीक्षण से जुड़ा हुआ है। साथ ही, रिपोर्टर से रन के परिणामों पर एक सारांश रिपोर्ट के कंपनी के विकी पोर्टल पर एक प्रकाशन प्रकाशित किया गया था। यह उन प्रबंधकों के लिए सुविधाजनक है, जो उस तकनीकी विवरण में गोता नहीं लगाना चाहते हैं जिसके साथ रिपोर्टर या एल्योर इंटरफ़ेस का उल्लंघन होता है।
यदि परीक्षण क्रैश हो जाता है, तो आप संबंधित बगों की सूची के लिए रिपोर्टर में देख सकते हैं या कार्यों को ठीक कर सकते हैं। इस तरह की जानकारी पार्सिंग समय को कम करती है और हमारी टीम के सदस्यों के बीच समस्याओं के बारे में ज्ञान के आदान-प्रदान की सुविधा प्रदान करती है। पूर्ण किए गए कार्यों के रिकॉर्ड संग्रहीत किए जाते हैं, लेकिन यदि आवश्यक हो, तो आप उन्हें एक अलग सूची में "झांक" सकते हैं। व्यावसायिक घंटों के दौरान आंतरिक सेवाओं को लोड नहीं करने के लिए, हम रात में जीरा का साक्षात्कार करते हैं और अंतिम स्थिति वाले मुद्दों के लिए प्रविष्टियों का संग्रह करते हैं।
रिपोर्टर की शुरूआत से एक बोनस एक रन डेटाबेस का उद्भव था, जिसके आधार पर आप फॉल्स की आवृत्ति का विश्लेषण कर सकते हैं, उनकी स्थिरता के स्तर के अनुसार परीक्षणों को रैंक कर सकते हैं या पाए गए बग की संख्या के संदर्भ में "उपयोगिता"।
ऑटोरन
इसके बाद, हम परीक्षण के लॉन्च को स्वचालित करने के लिए आगे बढ़े जब रिलीज की स्वीकृति परीक्षण का मुद्दा इश्यू ट्रैकर पर आता है। इस उद्देश्य के लिए, ऑटोरुन सेवा लिखी गई थी, जो यह जांचती है कि क्या जीरा में नए स्वीकृति कार्य हैं, और यदि ऐसा है, तो यह कार्य की सामग्री के आधार पर घटक के नाम और उसके संस्करण का निर्धारण करता है।
कार्य के लिए, कई चरणों का पालन किया जाता है:
- लॉकर सेवा में नि: शुल्क परीक्षण बेंच में से एक का ताला ले लो,
- जेनकींस में आवश्यक घटक की स्थापना शुरू करें, आवश्यक संस्करण के साथ घटक को उठाए जाने की प्रतीक्षा करें,
- परीक्षण चलाएं
- परीक्षण के पूरा होने की प्रतीक्षा करें, उनके निष्पादन की प्रक्रिया में सभी परिणाम रिपोर्टर में धकेल दिए जाते हैं,
- हम ज्ञात परीक्षणों की वजह से गिर गए असफल परीक्षणों की संख्या के लिए रिपोर्टर से पूछते हैं,
- यदि 0 गिर गया है - हम कार्य को "समाप्त" करने के लिए स्वीकृति परीक्षण के लिए स्थानांतरण करते हैं और इसके साथ काम करना समाप्त करते हैं। सब कुछ तैयार है =)
- यदि "लाल" परीक्षण हैं - हम कार्य को "प्रतीक्षा" में तब्दील करते हैं और उन्हें पार्स करने के लिए रिपोर्टर के पास जाते हैं।
चरणों के बीच स्विचिंग एक परिमित राज्य मशीन के सिद्धांत द्वारा आयोजित की जाती है। प्रत्येक चरण खुद को अगले के लिए संक्रमण के लिए शर्तों को जानता है। चरण के परिणामों को कार्य के संदर्भ में संग्रहीत किया जाता है, जो एक कार्य के चरणों के लिए आम है।
यह सब आपको तैनाती पाइपलाइन के साथ रिलीज को स्वचालित रूप से स्थानांतरित करने की अनुमति देता है, जिसके अनुसार 100 प्रतिशत परीक्षण हरे रंग के होते हैं। लेकिन घटक में समस्याओं के कारण नहीं, बल्कि यूआई परीक्षणों की "प्राकृतिक" विशेषताओं या परीक्षण बेंच में बढ़े नेटवर्क देरी के कारण अस्थिरता के बारे में क्या?
ऐसा करने के लिए, हमने एक रिट्री मैकेनिज्म लागू किया है, जिसका उपयोग बहुत से लोग करते हैं, लेकिन कुछ लोग इसे पहचानते हैं। रिटेन को जेनकिंस पाइपलाइन में परीक्षणों के क्रमिक रन के रूप में आयोजित किया जाता है।
रन के बाद, हम जेनकिंस से रिपोर्टर से विफल परीक्षणों की एक सूची का अनुरोध करते हैं - और केवल असफल लोगों को पुनरारंभ करें। इसके अलावा, हम स्टार्टअप पर थ्रेड्स की संख्या कम कर देते हैं। यदि पिछले परीक्षण की तुलना में गिराए गए परीक्षणों की संख्या कम नहीं हुई है, तो हम तुरंत नौकरी समाप्त कर देते हैं। हमारे मामले में, पुनरारंभ करने का यह तरीका हमें स्वीकृति परीक्षण की सफलता को लगभग 2 गुना बढ़ा देता है।
त्वरित ब्लॉक
परिणामी स्वीकृति परीक्षण प्रणाली ने हमें मानव हस्तक्षेप के बिना 60% से अधिक रिलीज का संचालन करने की अनुमति दी। लेकिन बाकी के साथ क्या करना है? यदि आवश्यक हो, तो परिचर परीक्षण के तहत घटक पर एक बग रिपोर्ट बनाता है या विकास टीम को परीक्षण फिक्स करने का कार्य करता है। कभी-कभी - परीक्षण खंड कॉन्फ़िगरेशन की एक बग को ऑपरेशन विभाग तक खींचता है।
परीक्षण को सही करने के लिए कार्य अक्सर स्वचालित परीक्षण के सही मार्ग को अवरुद्ध करते हैं, क्योंकि अप्रासंगिक परीक्षण हमेशा "लाल" होंगे। विकास टीमों के परीक्षक नए परीक्षण लिखने और मौजूदा अपडेट करने के लिए जिम्मेदार हैं - स्वचालित परीक्षणों के साथ परियोजना के लिए पुल अनुरोधों के माध्यम से परिवर्तन करना। ये संपादन एक अनिवार्य समीक्षा के अधीन हैं, जिसके लिए समीक्षक और लेखक से कुछ समय की आवश्यकता होती है, और मैं अस्थायी रूप से अप्रासंगिक परीक्षणों को रोकना चाहता हूं जब तक कि कार्य उनकी अंतिम स्थिति के लिए अनुवादित न हो।
सबसे पहले, हमने परीक्षण विधियों के एनोटेशन के आधार पर शटडाउन तंत्र लागू किया। इसके बाद, यह पता चला कि एक अनिवार्य कोड समीक्षा की उपस्थिति के कारण, कोड से अवरुद्ध करना हमेशा सुविधाजनक नहीं होता है और हम जितना चाहें उतना अधिक समय ले सकते हैं।
इसलिए, हमने वेब पेज के साथ एक नई सेवा के लिए परीक्षणों को अवरुद्ध करने वाले कार्यों की सूची को स्थानांतरित कर दिया - त्वरित-ब्लॉक। इसलिए घटक के लिए जिम्मेदार टीम के सदस्य जल्दी से परीक्षण को रोक सकते हैं। रन से पहले, हम इस सेवा में जाते हैं और संगृहीत परीक्षणों की एक सूची प्राप्त करते हैं, जिसे हम छोड़ दिया स्थिति में तब्दील कर देते हैं।
परिणाम
हम मैन्युअल मोड में रिलीज की स्वीकृति से लगभग पूरी तरह से स्वचालित प्रक्रिया में चले गए हैं, जो प्रति दिन 50 से अधिक रिलीज की स्वीकृति परीक्षण के माध्यम से संचालित करने में सक्षम है। इससे कंपनी को परिवर्तनों को पोस्ट करने में लगने वाले समय को कम करने में मदद मिलती है, और हमारी टीम परीक्षण उपकरणों के प्रयोग और विकास के लिए संसाधन पा सकती है।
भविष्य में हम ऊपर की सूची से प्रत्येक सेवा के उदाहरणों की एक जोड़ी के बीच अनुरोधों को वितरित करके, उदाहरण के लिए, प्रक्रिया की विश्वसनीयता बढ़ाने की योजना बनाते हैं। यह आपको डाउनटाइम के बिना टूल अपडेट करने और केवल स्वीकृति परीक्षणों के भाग के लिए नई सुविधाएँ शामिल करने की अनुमति देगा। इसके अलावा, हम खुद परीक्षणों को स्थिर करने पर ध्यान देते हैं। विकास में, सबसे कम सफलता दर के साथ परीक्षण को फिर से शुरू करने के लिए एक टिकट जनरेटर।
परीक्षणों की विश्वसनीयता में सुधार से न केवल उन पर विश्वास बढ़ेगा, बल्कि गिरी हुई लिपियों के पुनरारंभ की कमी के कारण रिलीज के परीक्षण में भी तेजी आएगी।