ओपनसोर्स समुदाय में परतदार परीक्षणों से कैसे निपटें

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



इस पोस्ट में, हम, वास्तव में, आपको बताएंगे कि अपाचे इग्नाइट में इस समस्या को कैसे हल किया जाए। हम दिमित्री पावलोव, लीड सॉफ्टवेयर इंजीनियर / ग्रिडग्रैन में कम्युनिटी मैनेजर और निकोलाई कुलगिन, सिंबन टेक्नोलॉजीज में आईटी इंजीनियर हैं।

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

अपाचे प्रज्वलित और परीक्षण

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

हम JetBrains TeamCity को निरंतर एकीकरण सर्वर के रूप में उपयोग करते हैं - खुले स्रोत आंदोलन का समर्थन करने के लिए JetBrains से लोगों को धन्यवाद। हमारे सभी परीक्षण स्वीट्स के बीच वितरित किए जाते हैं, जिनमें से मास्टर शाखा की संख्या 140 के करीब है। सुइट्स में, परीक्षण कुछ कसौटी द्वारा समूहीकृत किए जाते हैं। यह केवल मशीन लर्निंग [RunMl], केवल कैश [RunCache], या संपूर्ण [Runll] की कार्यक्षमता का परीक्षण कर सकता है। भविष्य में, परीक्षणों के चलने का मतलब बिल्कुल [RunAll] होगा - एक पूर्ण जांच। मशीन का लगभग 55 घंटे का समय लगता है।

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

परतदार समस्याएँ

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

किसे दोष देना है?

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

परंपरागत रूप से, सभी समुदाय के सदस्यों को दो समूहों में विभाजित किया जा सकता है:

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

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

कौन ठीक करेगा?

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

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

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

एक और समस्या: योगदानकर्ता को सूचित करने के लिए कि प्रत्येक समीक्षा से पहले परीक्षण चलाने चाहिए। कुछ को नहीं पता कि कहां, क्या और कैसे चलाना है। या परीक्षण चलाए गए, लेकिन योगदानकर्ता ने टिकट में इसके बारे में नहीं लिखा। इस स्तर पर भी समस्याएं हैं।

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



जहां "अच्छा" यहां स्पष्ट नहीं है। लेकिन जाहिर है, लेखकों को कम से कम पता है कि परीक्षण चलाने की आवश्यकता है।

हम इससे कैसे लड़े

विधि 1. अलग टेस्ट

हमने परीक्षणों को दो समूहों में विभाजित किया है। पहले में, "साफ" - स्थिर परीक्षण। दूसरे में - अस्थिर। दृष्टिकोण काफी स्पष्ट है, लेकिन यह दो प्रयासों के साथ भी काम नहीं करता था। क्यों? क्योंकि अस्थिर परीक्षणों के साथ एक सूट एक यहूदी बस्ती में बदल जाता है, जहाँ कुछ आवश्यक रूप से समय, क्रैश, आदि शुरू होता है। नतीजतन, हर कोई बस इन समस्याग्रस्त परीक्षणों को अनदेखा करना शुरू कर देता है। सामान्य तौर पर, ग्रेड द्वारा परीक्षणों को विभाजित करने का कोई मतलब नहीं है।

विधि 2. पृथक्करण और अधिसूचना

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



... 0 लोगों ने इन संदेशों पर प्रतिक्रिया दी। सभी ने उन्हें नजरअंदाज कर दिया।

विधि 3. दैनिक निगरानी

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

विधि 4. स्वचालन

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

बॉट क्या करता है? इसकी क्षमताओं को दो समूहों में जोड़ा जा सकता है:

• परियोजना निगरानी - रन के परिणामों को देखने के साथ-साथ तत्काल दूतों में स्वचालित अधिसूचना (उदाहरण के लिए, सुस्त) द्वारा दृश्य निगरानी
  
• शाखा जांच - पीआर परीक्षण का विश्लेषण, साथ ही एक टिकट में वीजा जारी करना।
  

टीमसिटी बॉट वर्कफ्लो

अपाचे प्रज्वलित टीमसिटी बॉट से पहले, समुदाय में "योगदान" की प्रक्रिया इस प्रकार थी:

1. JIRA में, टिकटों में से एक का चयन और निर्धारण किया जाता है;
   
2. एक पुल अनुरोध बनाया जाता है;
   
3. चलाए गए परीक्षण जो किए गए परिवर्तनों से प्रभावित हो सकते हैं;
   
4. यदि परीक्षण पास हो जाते हैं, तो पुल अनुरोध को कमेंट द्वारा पूर्वावलोकन और टेम्पर्ड किया जा सकता है।
   

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

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

टीमसिटी बॉट के साथ योगदान योजना

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

फ़ीचर अवलोकन

योगदान का निरीक्षण करें - प्रत्येक जानकारी के सारांश के साथ सभी अछूता पीआर की एक सूची: अंतिम अपडेट की तारीख, पीआर नंबर, नाम, लेखक और जेआईआरए में टिकट ।


प्रत्येक पुल अनुरोध के लिए, अधिक विस्तृत जानकारी के साथ एक टैब उपलब्ध है: सही पीआर नाम, जिसके बिना बॉट JIRA में वांछित टिकट नहीं पा सकेगा; क्या परीक्षण चलाए गए थे; क्या परीक्षा परिणाम तैयार है; JIRA में एक टिप्पणी छोड़ दी।

परीक्षण के परिणामों का विश्लेषण:




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



चलो बॉट रिपोर्ट पर वापस आते हैं। यह रिपोर्ट नेत्रहीन रूप से दो तालिकाओं में विभाजित है: संभावित ब्लॉकर्स और सभी क्रैश। ब्लॉकर्स में परीक्षण शामिल हैं:

• 4% से कम के मास्टर में असफलता दर (100 में से 4 से कम शुरू असफल रहे थे);
  
• टीमसिटी के वर्गीकरण के अनुसार परतदार नहीं हैं;
  
• एक टाइमआउट, मेमोरी से बाहर, कोड, जेवीएम की विफलता के कारण गिर गया।
  

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



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

परीक्षा परिणाम विश्लेषण



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

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


सही रिपोर्ट: कोई अवरोधक नहीं मिला


बॉट का ग्रीन वीज़ा (टिप्पणी)। कोई अवरोधक नहीं मिला।


रेड वीज़ा - डबल-चेकिंग और / या एडिटिंग बग्स की आवश्यकता

ऐसा होता है कि कुछ कीड़े अभी भी "मास्टर" में लीक होते हैं। जैसा कि हमने कहा, इससे पहले यह व्यक्तिगत सूचनाओं के माध्यम से लड़ा गया था। या किसी व्यक्ति ने सुनिश्चित किया कि कुछ भी नहीं गिरा। अब हम एक सरल समाधान का उपयोग कर रहे हैं:



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

इस प्रकार, हम समस्या को ठीक करने में लगने वाले गर्म फ़िक्सेस की संख्या को बढ़ाने और इसे कम करने में सक्षम थे।

मॉनिटरिंग विज़ार्ड की स्थिति
बॉट का एक और कार्य नवीनतम लॉन्च के आंकड़ों के साथ विज़ार्ड की स्थिति की निगरानी कर रहा है।



मास्टर ट्रेंड



मास्टर ट्रेंड पृष्ठ विशिष्ट समय अवधि के लिए दो "मास्टर" चयनों की तुलना करता है। तालिका में प्रत्येक आइटम के लिए अधिकतम, न्यूनतम मूल्य और मंझला प्रदर्शित करता है।


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

अपाचे इग्नाइट टीमकेटिटी बॉट में अब 65 से अधिक पंजीकृत सदस्य हैं। बॉट का उपयोग करने की पूरी अवधि में, वीजा को 400 से अधिक पुल अनुरोध प्राप्त हुए, और औसतन प्रति दिन पांच वीज़ा जारी किए जाते हैं।

टीमसिटी बॉट स्ट्रक्चर

बॉट को एक अलग सर्वर पर होस्ट किया गया है, डेटा के लिए ignite.apache.org पर जाता है, सार्वजनिक रूप से देव-सूची में सभी को सूचित करता है - यह इग्नाइट डेवलपर्स के लिए हमारा मुख्य मंच है - और JIRA एपीआई के माध्यम से टिकट के लिए वीजा लिखता है।



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

बॉट कार्यान्वयन का पहला संस्करण REST कैशिंग पर एक लेख से प्रेरित था और एक REST कैश और GitHub और Teamity सेवाएँ थी। सर्वर से लौटी Teamcity xml और json को प्योर जावा ऑब्जेक्ट्स द्वारा पार्स किया गया था, जिन्हें तब कैश किया गया था। सबसे पहले यह काम किया, और काफी जल्दी। लेकिन आंकड़ों की मात्रा में वृद्धि के साथ, परिणाम खराब होने लगे।

यह ध्यान देने योग्य है कि TeamCity ~ 2 सप्ताह से अधिक पुरानी कहानी को हटा देता है, लेकिन बॉट नहीं करता है। अंततः, इस दृष्टिकोण के साथ, डेटा के टन दिखाई दिए, जिन्हें प्रबंधित करना बहुत मुश्किल है।

टीमसिटी बॉट डेवलपमेंट

नया दृष्टिकोण एक कॉम्पैक्ट डेटा स्टोरेज विकल्प को लागू करता है और कम संख्या में कैश विभाजन के लिए खुलता है। एक नोड पर बड़ी संख्या में विभाजन डिस्क को डेटा सिंक्रनाइज़ेशन की गति को नकारात्मक रूप से प्रभावित करता है और क्लस्टर के प्रारंभ समय को बढ़ाता है।

सभी प्रमुख डेटा अपडेट एसिंक्रोनस रूप से किए जाते हैं, क्योंकि अन्यथा हम TeamCity डेटा की धीमी वापसी के कारण एक बुरा UX होने का जोखिम उठाते हैं।

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



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

"अप्रत्याशित" लाइनों के लिए, उदाहरण के लिए, स्टैक ट्रेस लॉग, विभिन्न प्रकार के संपीड़न का उपयोग किया जाता है - gzip संपीड़न, तड़कना संपीड़न या असम्पीडित, जिसके आधार पर बेहतर है। ये सभी तरीके इन-मेमोरी में अधिकतम डेटा को फिट करने में मदद करते हैं और क्लाइंट को तुरंत प्रतिक्रिया देते हैं।

क्यों टीमकिट बॉट बेहतर है

यह कहना नहीं है कि TeamCity में ऊपर सूचीबद्ध विशेषताएं नहीं हैं। वे हैं, लेकिन विभिन्न स्थानों के ढेर पर बिखरे हुए हैं। बॉट में, सब कुछ एक पृष्ठ पर एकत्र किया जाता है और आप जल्दी से समझ सकते हैं कि समस्या क्या है।

एक अच्छा जोड़ वह पत्र है जो किसी समस्या का पता लगाने पर बॉट देव शीट पर भेजता है। समुदाय में तुरंत एक चर्चा शुरू करने का एक अवसर होता है: "चलो, शायद, अब हम रिवर्स करेंगे?"। इससे समीक्षकों में विश्वास बढ़ता है।

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

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