डर को रोकने के बारे में और लगातार रिलीज के साथ प्यार में पड़ना

मुझे कहना होगा कि, सिद्धांत रूप में, डेवलपर्स ऐसे trifles पर ध्यान नहीं देते हैं जैसे परीक्षण और तैनाती। और नीचे की तस्वीर में जो स्थिति है वह भी कोई मज़ाक नहीं है, लेकिन जो स्थिति गवाह है, मुझे लगता है कि कई थे।



मैं आपको अपने वर्तमान कार्यस्थल पर विकास के बारे में थोड़ा बताऊंगा।

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

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

बार-बार रिलीज़ करना केवल अच्छा नहीं है, वे उत्कृष्ट हैं: सुव्यवस्थित और लगातार रिलीज़ प्रक्रिया डेवलपर को अपडेट के डर से बचाती है, और ग्राहक प्रगति देखता है।

यह विकास प्रक्रिया निरंतर एकीकरण के साथ ओवरलैप होती है। उसके बारे में, भी, किताबें और लंबे लेख संक्षेप में लिखे गए हैं, - यह एकीकरण की समस्याओं ( विकिपीडिया ) की त्वरित पहचान और समाधान के लिए परियोजना के लगातार स्वचालित विधानसभाओं का कार्यान्वयन है।

हम एक वितरित प्रणाली विकसित कर रहे हैं, हमारे पास बैकएंड (एपीआई) के रूप में पर्ल है, क्लाइंट कोड जावास्क्रिप्ट में लिखा है, और जेनकिंस सीआई एक निरंतर एकीकरण सर्वर के रूप में।

जो लोग इससे परिचित नहीं हैं, मैं उंगलियों पर समझाऊंगा कि जेनकींस क्या है: यह एक वेब इंटरफेस के साथ एक सेवा है जहां असेंबली के लिए कार्य कॉन्फ़िगर किए गए हैं। कार्य एक चरण-दर-चरण निर्देश है जो पैकेज बनाने के लिए सर्वर को निष्पादित करना चाहिए, हमारे मामले में यह आरपीएम है। उदाहरण के लिए, यह आमतौर पर इस तरह होता है:

• वीसीएस (संस्करण नियंत्रण प्रणाली) से एक चेकआउट करें;
• परीक्षण चलाएं;
• संकलन और आवश्यक फ़ाइल संरचना को इकट्ठा करना;
• आरपीएम फ़ाइल में पैक;
• भंडार में डाल दिया।

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

तो: एक CI सर्वर है जिस पर rpm पैकेज बनाया गया है, पैकेज फिर yum रिपॉजिटरी में जाता है, और एक गंतव्य सर्वर या सर्वर का एक क्लस्टर होता है, जिस पर यह पैकेज स्थापित होता है।

हमारी परियोजना में, हम CPAN के साथ मॉड्यूल का उपयोग करते हैं - पुन: उपयोग कोड अच्छा है, लेकिन कुछ ओवरहेड को मजबूर करता है, जिसके लिए बहुत से लोग पर्ल पसंद नहीं करते हैं।

पर निर्भर करता है

एक उदाहरण पर विचार करें: हमें एक निश्चित हैश एल्गोरिथ्म का उपयोग करने की आवश्यकता है, कार्य बल्कि तुच्छ है, हम सीपीएएन पर एक मॉड्यूल लेते हैं और इसे हमारे विकास के वातावरण में डालते हैं:

# cpanm Some::CPAN::Module 

जिसके बाद हम कोड लिखते हैं:

  use Some::CPAN::Module; sub encrypt { my $string = shift; return Some::CPAN::Module::mkHash($string); } 

और इसे आटे के साथ कवर करें:

  ok(encrypt("test") eq Some::CPAN::Module::mkHash("test"), "encrypt function"); 

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

और यहां परेशानी है: परीक्षण विफल रहता है - बिल्ड सर्वर पर कोई मॉड्यूल आवश्यक नहीं है।

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

परीक्षण बनाने और पास करने के लिए, कल्पना फ़ाइल में निर्भरता जोड़ें:

  BuildRequires: perl-Some-CPAN-Module 

गंतव्य सर्वर पर लागू करने के लिए, जोड़ें:

  Requires: perl-Some-CPAN-Module 

यदि आप भाग्यशाली हैं, तो आवश्यक आरपीएम पहले से ही यम भंडार में है, यदि नहीं, तो आपको पैकेज को इकट्ठा करने और यम भंडार में रखने की आवश्यकता है।

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

समाधान: हम उस मॉड्यूल के संस्करण का पता लगाते हैं जिसके साथ हमारा कोड काम करता है, इस संस्करण के साथ आरपीएम इकट्ठा करता है और स्पी-फाइल में मॉड्यूल के सटीक संस्करण को निर्दिष्ट करता है।

  BuildRequires: perl-Some-CPAN-Module = 1.41 Requires: perl-Some-CPAN-Module = 1.41 

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

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

एक वैकल्पिक समाधान संभव है: अपने स्वयं के सीपीएएन दर्पण को उठाना, उदाहरण के लिए, पिंटो का उपयोग करना, लेकिन यह इस लेख का विषय नहीं है।

एक और उपाय है।

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

दफ़्ती

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

कार्टन क्या है? यह मोती मॉड्यूल के लिए एक निर्भरता प्रबंधक है। यह रूबी के लिए बुंडलर के प्रभाव में लिखा गया था।

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

  requires 'Some::CPAN::Module', '1.45'; 

तब कमांड चलाया जाता है:

  carton install 

और आवश्यक मॉड्यूल को स्थानीय / देय निर्देशिका में रखा जाता है और cpanfile.snapshot भी बनाया जाता है, जिसमें CPAN के साथ स्थापित मॉड्यूल के बारे में जानकारी संग्रहीत होती है। इस फ़ाइल को VCS में भी जोड़ा जाना चाहिए, ताकि बाद में बिल्ड सर्वर पर जब कार्टन शुरू हो तो स्नैपशॉट से निर्भरता आ जाए, जिससे पर्यावरण की पहचान की गारंटी हो।

अब आपको बस इतना करना है कि @INC में लोकल / @INC डायरेक्टरी को @INC ।

आप उस सटीक संस्करण को निर्दिष्ट कर सकते हैं जो आवश्यक है या संस्करणों की एक मान्य श्रेणी है:

  requires 'Some::CPAN::Module', '>= 1.41, < 1.46'; 

इसके अलावा, आप विभिन्न वातावरणों के लिए विशिष्ट मॉड्यूल निर्दिष्ट कर सकते हैं, उदाहरण के लिए:

  osname 'MSWin32' => sub { requires 'Win32::File'; }; on 'test' => sub { requires 'Test::More', '>= 0.96, < 2.0'; recommends 'Test::TCP', '1.12'; }; on 'develop' => sub { recommends 'Devel::NYTProf'; }; 

कार्टन एक ही लेखक की एक और उपयोगी उपयोगिता, cpanm के साथ तालमेल से काम करता है, और हम मॉड्यूल की प्रत्यक्ष स्थापना के लिए उसके आभारी हो सकते हैं।

अब चूंकि हमारे पास cpanfile में सभी निर्भरताएं हैं, cpanfile.snapshot में विकास के माहौल का एक स्नैपशॉट और यह सब वीसीएस में कल्पना फ़ाइल में रखा गया है, आप परीक्षणों को चलाने से पहले कार्टन इंस्टॉल कमांड जोड़ सकते हैं।

जब पैकेज जिस सर्वर के लिए आरपीएम पैकेज का इरादा होता है, उसी कमांड को इंस्टॉलेशन स्टेज में जोड़ा जा सकता है।

लेकिन हम और आगे बढ़ गए।

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

  # cap carton install 

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

अधिक सुसंगत तरीका है, हम आरपीएम पैकेज बिल्ड स्टेज पर मॉड्यूल स्थापित कर सकते हैं। और हमने एक über-rpm पैकेज बनाने का निर्णय लिया जिसमें हमने एक ही बार में सभी निर्भरताएँ रखीं। इस पैकेज को कोड के साथ एक पैकेज निर्भरता के रूप में घोषित किया गया है और इसे विधानसभा और उत्पादन के दौरान परीक्षण पास करने के लिए बिल्ड सर्वर पर स्थापित किया जा सकता है।

यह दृष्टिकोण परियोजनाओं के लिए लोकप्रिय है, उदाहरण के लिए, स्कैला पर - एक über-jar बनाया गया है जिसमें सभी परियोजना निर्भरता + कोड, आगे भी चलते हैं - वे एक ubber-binar बनाते हैं जिसमें सभी निर्भरताएं पहले से ही संकलित हैं।

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