संरचना और स्वचालन के बारे में

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

शुरुआत में यह शब्द था

शुरू करने के लिए, मैं आपको थोड़ा बताऊंगा कि यह सब कैसे शुरू हुआ:

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

शुरुआत में एक संरचना थी

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

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

"कैसे ठीक से svn का संचालन करें" के बारे में लंबी बहस के दौरान, टैग को ठीक करने का विकल्प चुना गया था और कई आवश्यकताओं / नियमों को तैयार किया गया था जिसका पालन किया जाना चाहिए:

ट्रंक

• कार्यक्षमता में सुसंगत नहीं हो सकता है
• मैनुअल व्यापक परीक्षण के अधीन नहीं
• उत्पादन के लिए बाहर रोल करने या ब्रंच में विलय करने के अधीन नहीं

टैग एन

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

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

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

हमने खोपड़ी को काट दिया

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

एकल संस्करण प्रारूप

अगला महत्वपूर्ण कदम एक कसौटी का परिचय था जिसके आधार पर यह कहना सुरक्षित होगा कि दोनों घटक सुसंगत हैं। हमने तय किया कि कसौटी संस्करण होगा। इसके अलावा, संस्करण को ही जानकारी लेनी चाहिए जिसके आधार पर यह समझा जा सकता है कि दो घटक सुसंगत हैं।
संस्करण प्रारूप: MAJOR_NUM.MINOR_NUM.REVISION। यानी संस्करण का पहला भाग टैग संख्या भी है। और हम जानते हैं कि हमारे पास टैग संगत सभी घटक हैं। टैग नाम में एक साथ दो संख्याओं का संकेत आपको प्रमुख संस्करणों के बीच एक सामान्य संक्रमण बनाने की अनुमति देता है, अर्थात। 1.1.x, 1.2.x, 1.3.x, 2.4.x के बजाय, हमारे पास 1.1.x, 1.2.x, 1.3.x, 2.1.x होगा। संशोधन संख्या बनी हुई है और हमेशा की तरह उपयोग की जाती है। यह प्रत्येक व्यक्तिगत घटकों की संशोधन संख्या है, न कि केवल टैग का अंतिम संशोधन।

फिर ऑटोमेशन आया

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

मैं तुम्हारा स्वामी हूँ तुम मेरे दास हो

हमारी प्रणाली के घटक बहुत विविध हैं और वर्तमान में 3 बिल्ड प्लेटफॉर्म का उपयोग करते हैं: विंडोज़, लिनक्स और मैक ओएस। यह एक मास्टर और 2 गुलाम निकला (मैं अब "दास" शब्द दोहराना नहीं चाहता)। लिनक्स पर निश्चित रूप से विज़ार्ड को कहां करना है, इसका सवाल नहीं उठता। प्रारंभिक कॉन्फ़िगरेशन एक मास्टर (लिनक्स) और एक दास (विंडोज) से तैनात किया गया था। हमारे सभी घटकों की विधानसभा को स्वचालित करने की प्रक्रिया शुरू हो गई है। काम के दौरान, टैग 1.1 पहले से ही दिखाई दिया और जेनकिंस में कार्यों की संख्या 10. से अधिक हो गई और फिर समस्याएं शुरू हो गईं। एक दिन, जेनकिंस गिर गया। हमने उसे उठाया, वह फिर से गिर गया। और एक बार और। और यह गिरना जारी रहा, कोई फर्क नहीं पड़ता कि हम इसे टॉमकैट के माध्यम से या सेवा के रूप में कैसे चलाते हैं। JAVA मशीन के बावजूद, JDK या SUN जावा खोलें। भले ही वर्तमान संस्करण। बल्कि, यह जेनकिन्स खुद नहीं था जो गिर गया, लेकिन जेएवीए मशीन जो वह दुर्घटनाग्रस्त हो गई थी। मैंने उनके बगट्रैक ( JENKINS-16199 , में एक अलग बग शुरू किया, हालांकि यह सब मर गया)। यह समझने के लिए कि क्या हो रहा है या कम से कम क्यों, यह समझने के लिए सभी तरह के प्रयासों पर एक-डेढ़ हफ़्ता बिताने के बाद, विज़ार्ड को विंडोज सिस्टम में स्थानांतरित करने का निर्णय लिया गया। और लो और निहारना, एक ही विन्यास में सब कुछ stably काम करना शुरू कर दिया। समय के बाद से, कार्यों की संख्या दोगुनी हो गई है, लेकिन सब कुछ काम करना जारी रखता है। नतीजतन, अंतिम संरचना इस तरह दिखती है:
विंडोज पर विज़ार्ड, दो दास, लिनक्स और मैकओएस पर, एसएसएच सार्वजनिक कुंजी के माध्यम से संचार।

प्रत्यारोपण के बारे में

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

और दूसरे में, इस प्लगइन का उपयोग करके, इस कला को डाउनलोड करें

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

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

विशेष, काला, जादू

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

यह कार्य परिचालित है।
मापदंडों
TAG, HOST, USER, DEPLOY_DIR, OPENSSL_DIR, यहाँ कोई जादू नहीं है, साधारण रेखाएँ हैं।
JOBS_NUMBER - "कॉपी एट्रीफ़ैक्ट के लिए चयनकर्ता बनाएँ", आपको यह निर्दिष्ट करने के लिए कि विधानसभा के कौन से संस्करण को लेना है, अंतिम सफल या कुछ विशिष्ट संख्या या कुछ और।
PASSWORD "पासवर्ड पैरामीटर" प्रकार का एक पैरामीटर है - पासवर्ड को तारांकन के साथ बंद कर देता है।
इस प्रकार वांछित कार्य से वांछित असेंबली ली जाती है

सेटअप देखें

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

हम बेकार में शूट करते हैं

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

नजरबंदी की जगह पर

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

आपका ध्यान देने के लिए धन्यवाद।

धन्यवाद

FrimInc , एक लेख को प्रूफ करने के लिए zzapp