AIDA। गिट, जेआईआरए और टीमसिटी के साथ काम का स्वचालन

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

AIDA (इंजी। ऑटोमेटेड इंटरएक्टिव डिप्लॉय असिस्टेंट) एक ऐसा खाता है जो Git, TeamCity और JIRA के साथ काम करना बहुत आसान बनाता है।
आज हम इस बारे में बात करेंगे कि इसकी मदद से हम कई कार्य प्रक्रियाओं को स्वचालित करने में सक्षम थे।

सबसे पहले, हम संस्करण नियंत्रण प्रणाली का उपयोग याद करेंगे, तब हम बात करेंगे कि रिलीज़ शाखाओं का निर्माण कैसे स्वचालित था और शाखाओं को स्वचालित रूप से Git में विलय कर दिया गया था, और हम JRA के साथ काम करने में AIDA की महत्वपूर्ण मदद के बारे में बात करेंगे (निगरानी और कार्यों को बदलना, खेतों में भरना। ) और eamCity (निरंतर एकीकरण और एक परीक्षण वातावरण में तैनाती)।

गिट वर्क

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

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

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

यह आरेख चित्र में दिखाया गया है:



परीक्षण कई चरणों में होता है:

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

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

AIDA और Git

ऊपर वर्णित मॉडल में शाखाओं की बड़ी संख्या के कारण, शाखाओं के विलय, एक रिलीज बनाने और कोड को नियंत्रित करने के लिए कई कार्य उत्पन्न होते हैं। उनके स्वचालित समाधान पर विचार करें:

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

AIDA और JIRA

विकास को नियंत्रित करने, गठन और परीक्षण जारी करने के लिए, हम JIRA का उपयोग करते हैं। सभी परियोजनाओं में वर्कफ़्लो पूरी तरह से विकसित और औपचारिक है। विकास और परीक्षण के दौरान, बग ट्रैकर में काम का हिस्सा AIDA द्वारा किया जाता है।
असल में, यह हमें कार्यों को स्थानांतरित करने या उनमें जानकारी प्रदर्शित करने में मदद करता है। यहाँ कुछ उदाहरण हैं:

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

यदि कुछ निश्चित संकल्प हैं, तो यह कार्य की स्थिति को बदलने में भी मदद करता है:

• निश्चित और उत्पादन पर निर्भर - एक टिकट स्वचालित रूप से अपनी स्थिति को उत्पादन में बदल देता है

AIDA हमें कार्यों के साथ इसकी सभी गतिविधियों की जानकारी देता है।
यह स्वचालन वर्कफ़्लो के साथ काम करने को बहुत सरल करता है और नियमित क्रियाओं को समाप्त करता है।

AIDA और टीमसिटी

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

आइए देखें कि विधानसभा और स्वचालित तैनाती के साथ परिणाम क्या है:

1. TeamCity में प्रोजेक्ट बिल्ड_ * मास्क के साथ शाखाओं पर कॉन्फ़िगर किया गया है।
2. रिलीज शाखा में बदलाव के बाद, स्वचालित असेंबली शुरू होती है।
3. सफल निष्पादन पर, सर्वरों का परीक्षण करने के लिए परिनियोजन स्क्रिप्ट प्रारंभ होती है।
4. त्वरित धूम्रपान परीक्षणों (हम एक सरल कर्ल का उपयोग करते हैं) की मदद से परीक्षण वातावरण की जांच की जाती है।
5. यदि परीक्षण विफल हो जाते हैं, तो रिलीज़ संस्करण खराब के रूप में चिह्नित किया जाता है और रिलीज़ के पिछले (अच्छे) संस्करण में रोलबैक होता है।

पूरी प्रक्रिया में तीन मिनट लगते हैं। परीक्षण केवल घातक त्रुटियों को प्रकट करते हैं। इस मामले में, सभी इकाई-, ऑटो और कार्यात्मक परीक्षण समानांतर में चलते हैं।
यह इसलिए किया जाता है ताकि परीक्षक परीक्षण वातावरण में कार्य को जितनी जल्दी हो सके देख सके।

परिणाम

आइए देखें कि AIDA हमारे साथ क्या कार्य करती है:

1. गिट के साथ काम करता है, शाखाएं बनाता है, उन्हें विलय करता है, अगर कुछ गलत हो जाता है तो हमें चेतावनी देता है।
2. JIRA के साथ इंटरेक्ट करता है, स्वचालित रूप से कार्यों में स्थिति और अद्यतन जानकारी को बदलता है।
3. टीमसिटी को स्क्रिप्ट, परीक्षण चलाने और एक परीक्षण वातावरण में तैनात करने में मदद करता है।

AIDA बहुत कुछ कर सकता है, लेकिन हम वहाँ नहीं रुकते हैं और अपने सहायक को निम्नलिखित क्रियाएं सिखाना चाहते हैं:

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

यदि आप प्रत्येक प्रकार के स्वचालन के बारे में अधिक विस्तृत कहानी में रुचि रखते हैं, तो टिप्पणियों में इसके बारे में लिखें और हम ख़ुशी से इस विषय पर लेखों की श्रृंखला जारी रखेंगे।

PS अपने आप को अच्छे सहायक बनाएँ जो आपको मुश्किल समय में निराश नहीं होने देंगे!