🛢️ 🛃 🤰🏼 CI / CD प्रक्रिया अपडेट: टीमसिटी 🍍 🤟 🚗

यह CI / CD प्रक्रियाओं को अद्यतन करने के बारे में एक श्रृंखला का दूसरा लेख है। इस बिंदु तक, नए उपकरण स्थापित करने के लिए तैयारी की जा रही थी, अर्थात्: नियोजन, दैनिक रैलियां, असहमति का समाधान, सामान्य रूप से, जिसके बिना यह संभव नहीं है कि कार्य प्रक्रिया का निर्माण संभव हो सके। और अब, सभी मुद्दों को हल कर दिया गया है, हमें विश्वास है कि हम विकास जारी रख सकते हैं, और हमारा कोड गर्मियों की शुरुआत के साथ ब्लैक होल में नहीं डूबेगा।

मुझे आपको लेखों की सूची की सामग्री, साथ ही पिछले भाग के संक्षिप्त परिणामों की तालिका याद दिलाती है।

भाग 1: क्या है, क्यों यह पसंद नहीं है, योजना, थोड़ा सा मार। मैं इस हिस्से को तकनीकी कहूंगा।
भाग 2: टीमसिटी।
भाग 3: ऑक्टोपस की तैनाती।
भाग 4: पर्दे के पीछे। अप्रिय क्षण, भविष्य की योजनाएं, संभवतः एफएक्यू। सबसे अधिक संभावना है, इसे निकट-तकनीकी भी कहा जा सकता है।

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

जैसा कि पहले उल्लेख किया गया है, मौजूदा समाधान आधुनिक आवश्यकताओं को पूरा नहीं करता है। प्रारंभ में, सबसे अधिक संभावना है, एक बिल्ड को cnet में कॉन्फ़िगर किया गया था। बहुत पहले निर्माण जिसके साथ यह शुरू हुआ (जैसे एक बड़ा धमाका, हाँ)। फिर, जाहिर है, जो व्यक्ति इसे स्थापित करता है, उसने ctrl + c, ctrl + v दबाया, कुछ पंक्तियों को ठीक किया, और एक नया कॉन्फ़िगरेशन प्राप्त किया। और बाद के सभी समय के लिए, यह पर्याप्त संख्या में किया गया था ताकि बिल्ड सर्वर पर स्रोत कोड 60G से अधिक हो। और ये सिर्फ स्रोत हैं! और लॉग हैं, कलाकृतियों का निर्माण, अस्थायी फाइलें, और इसी तरह। केवल इससे मुझे लगता है। पुरानी प्रणाली को देखते हुए, कोई भी निम्नलिखित को देख सकता है: प्रत्येक मॉड्यूल के लिए एक बिल्ड चरण निष्पादित किया गया था। वास्तव में, एक ही कोर इकट्ठा किया गया था। और यह असेंबली सर्वर पर प्रत्येक मॉड्यूल (स्रोत के साथ) के लिए संग्रहीत की गई थी।बिल्ड परिणाम (90% समान) को स्थानीय रिपॉजिटरी (गिट तैनाती) में धकेल दिया गया, और निश्चित रूप से, उनकी जगह ले ली। इसे छोड़ना संभव और आवश्यक था।

सामान्य सेटिंग्स

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

env.apiUserName और env.apiUserPassword एपीआई teamcity उपयोगकर्ता के लिए पहुँचता हैं (जो बाद में की आवश्यकता होगी), env.buildPath और env .SourcePath - फ़ाइलों और स्रोत फ़ाइलों को बनाने के लिए डिफ़ॉल्ट पथ, क्रमशः, env.octoApiKey और env.octoUrl - token और octopus url। उन्होंने अभी भी env.teamcityUrl को जोड़ा है। खैर, env.tt.exe- पाठ परिवर्तन उपयोगिता के लिए पथ। यह उपयोगिता सभी विन्यास उत्पन्न करती है।

तृतीय-पक्ष प्लगइन्स में से केवल ऑक्टोपस डिप्लॉय एकीकरण स्थापित किया गया है।

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

प्रोजेक्ट ब्रेकडाउन, वर्जनिंग, नाम

परिणाम इस तरह की एक परियोजना योजना थी (चित्र के रूप में, क्योंकि एक बहुस्तरीय सूची प्रदर्शित करने में समस्या है):

हम पैकेजों को निम्नानुसार संस्करण देंगे: major.minor.patch, जहां प्रमुख अभी भी 1 है, मामूली - बिल्ड कॉन्फ़िगरेशन से काउंटर, पैच - कॉन्फ़िगरेशन के लिए बिल्ड काउंटर तैनात करें (बिल्ड कॉन्फ़िगरेशन के लिए आवश्यक नहीं, इसलिए हमेशा 0)।

नोट: पुराने संस्करण का वर्णन यहाँ किया गया है। हम इसे फिर से डिज़ाइन कर रहे हैं ताकि यह गिट टैग पर आधारित हो।

उदाहरण के लिए, यहां 1 प्रमुख है, 95 छोटा है, और 1 पैच है।

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

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

मॉड्यूल

सभी मॉड्यूल परियोजनाएं एक ही सिद्धांत पर काम करती हैं।

प्रत्येक वातावरण में एक बिल्ड कॉन्फ़िगरेशन है:

नगेट रिस्टोर (नुगेट इंस्टॉलर, नुगेट रिस्टोर) करता है
कॉन्फ़िगरेशन उत्पन्न करता है (कमांड लाइन, टेक्स्ट ट्रांसफ़ॉर्म)
बिल्ड समाधान (विज़ुअल स्टूडियो एसएलएन)
Zip में env.buildPath से फ़ाइलों को उठाता है और इसे ऑक्टोपस (ऑक्टोपस की तैनाती: पुश पैकेज) में धकेलता है
रिलीज निर्माण (कोई तैनाती नहीं) (ऑक्टोपस तैनात रिलीज)
पैच संस्करण (पावरशेल) रीसेट करता है

वहाँ भी कॉन्फ़िगरेशन तैनात हैं जो टेम्पलेट के आधार पर काम करते हैं और निम्न कार्य करते हैं:

निर्माण चरण (चरण 2) (ऑक्टोपस तैनात पुश पैकेज) पर उत्पन्न कॉन्फ़िगरेशन को ऊपर उठाता है
कोर रिलीज जारी करें (जो बिल्ड के चरण 6 में बनाया गया था) (ऑक्टोपस तैनात: तैनाती रिलीज)
परिनियोजन व्यक्तिगत रिलीज़ (जो वर्तमान कॉन्फ़िगरेशन के चरण 1 में बनाया गया था) (ऑक्टोपस तैनात: तैनाती रिलीज़)
लॉग में इस मॉड्यूल के लिए सभी डोमेन की एक सूची प्रदर्शित करता है (परीक्षक और डेवलपर की सुविधा के लिए कदम)। (शक्ति कोशिका)।

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

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

यह कुछ ऐसा दिखता है:

आइए कुछ चरणों को थोड़ा और विस्तार से देखें।

निर्माण। सामान्य सेटिंग्स

असामान्य से केवल संख्या स्वरूप बनाते हैं। बाद में समझाया जाएगा।

Build.env

यहाँ ब्याज की हैं:
env.coreProjectName - पूरी परियोजना के लिए सेट। ऑक्टोपस में परियोजना की पहचान करने की आवश्यकता।
env.Environment - मॉड्यूल सबप्रोजेक्ट के लिए सेट किया गया। पर्यावरण के आधार पर सही कॉन्फ़िगरेशन का चयन करना आवश्यक है।
env.octoChannel - ऑक्टोपस में वह चैनल जिसमें पैकेट गिरता है। उसी के रूप में env.Environment ।
env.serviceName समाधान का नाम है। मूल रूप से, चर को विज़ुअलाइज़ेशन में आसानी के लिए जोड़ा जाता है।
env.tenantRoleTag - ऑक्टोपस में किरायेदार टैग। ऑक्टोपस अनुभाग में अधिक जानकारी।

Build.4

नाम के साथ संग्रह में जोड़ें % env.serviceName%।% Build.number%। निर्माण के परिणाम के साथ निर्देशिका से .zip फ़ाइलें, सभी कॉन्फ़िगरेशनों को छोड़कर, और बिन / देशी फ़ोल्डर से dll। अंतिम वाले को एक बार वेब सर्वर पर मैन्युअल रूप से जोड़ा गया था और कोई भी उन्हें फिर से नहीं छूएगा। यदि आवश्यक हो, तो उन्हें मैन्युअल रूप से भी अपडेट किया जाएगा (इसके लिए एक अलग स्क्रिप्ट लिखने की योजना है, लेकिन हम ईमानदार होंगे)। यह इस तथ्य के कारण है कि इन पुस्तकालयों को IIS पूल द्वारा "आयोजित" किया जाता है, और एक सफल तैनाती के लिए इसे रोका जाना चाहिए और फिर लॉन्च किया जाना चाहिए, जिसमें कुछ समय लगता है। इन पुस्तकालयों को परिनियोजन से बाहर करके, हम पूल को रोकने के चरण को छोड़ सकते हैं, जिससे तैनाती का समय कम हो जाएगा, और, तदनुसार, डाउनटाइम।

Build.5

मुझे लगता है कि यहां सब कुछ स्पष्ट है, सिवाय इसके कि पर्यावरण क्षेत्र क्यों खाली है। पैकेज मिलने पर, ऑक्टोपस पूर्व-रिलीज़ टैग (चैनलों में कॉन्फ़िगर किए गए) के आधार पर निर्णय लेता है। यह टैग % build.number% (Build.General में स्क्रीन पर समान-पेजिंग) में निहित है। तो इस मामले में यह अधिक सुविधाजनक निकला। यह "शो परिनियोजन प्रक्रिया" चेकबॉक्स पर ध्यान देने योग्य भी है । यदि यह स्थापित नहीं है, तो ऑक्टोपस शुरू हो गया है, लेकिन काम के रूप में जल्द ही निर्माण को सफल मानता है। यही है, अगर चेकबॉक्स स्थापित नहीं है और तैनाती चरण के दौरान कुछ गलत हो गया - ऑक्टोपस इंटरफ़ेस को देखे बिना, हम इसके बारे में नहीं जानते।

Build.6

कुछ भी असामान्य नहीं है, टीमशिप डॉक्यूमेंटेशन से सिर्फ एक पॉवरशेल स्क्रिप्ट और जानकारी।

$pair = "%env.apiUserName%:%env.apiUserPassword%"
$encodedCreds = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($pair))
$basicAuthValue = "Basic $encodedCreds"
$depUri="%env.teamcityUrl%/app/rest/buildTypes?locator=snapshotDependency:(from:(build:(id:%teamcity.build.id%)),includeInitial:false)"
# Get all dependencies of main build
$result = (Invoke-RestMethod -Headers @{'Origin'='http://localhost:8090'; "Authorization"="$basicAuthValue"} -Uri $depUri)
foreach ($i in $result.buildTypes.buildType.Count) { $buildId += $result.buildTypes.buildType.id }
$buildId = $buildId | Where-Object { $_ -ne 'Module_DeployAll' }
# Reset all child build counters to 1. This build counters are patch versions in every build. (1.build.patch)
for ($i=0; $i -lt $buildId.Count; $i++) {
  $buildCounterUri = "%env.teamcityUrl%/httpAuth/app/rest/buildTypes/"+$buildId[$i]+"/settings/buildNumberCounter"
  Invoke-RestMethod -Method Put -Headers @{'accept'='text/plain'; 'Origin'='http://localhost:8090'; "Authorization"="$basicAuthValue"} -Uri $buildCounterUri -ContentType "text/plain" -Body 1
}

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

Deploy.General

संस्करण प्रारूप: 1.% dep.Module_Build.build.counter%।% Build.counter% -staging , जहाँ
% dep .odule_Build.build.counter% टीमसिटी सिस्टम चर है जिसका मान संगत बिल्ड कॉन्फ़िगरेशन के बिल्ड काउंटर से मेल खाता है (जोड़ा जाना चाहिए) निर्भरता)। वास्तव में, यहां 1 प्रमुख संस्करण है, % dep.Module_Build.build.counter% मामूली है, और % build.counter% पैच है। स्टेजिंग एक पूर्व-रिलीज़ टैग है।

Deploy.Env

एक नया मॉड्यूल जोड़ते समय, इसकी तैनाती के लिए केवल कॉन्फ़िगरेशन जोड़ा जाता है और env.modName चर का मान इंगित किया जाता है । अन्य सभी चर मूल परियोजनाओं से विरासत में मिले हैं। एक ऑक्टोपस के लिए env.tenantModTag चर env.modName से बनता है ।

Deploy.2

कोर पैकेज तैनात करें।

रिलीज़ नंबर नवीनतम - इस वातावरण के लिए नवीनतम उपलब्ध रिलीज़ का उपयोग करें।
किरायेदार टैग - ग्राहक / संगठन टैग। ऑक्टोपस अनुभाग में अधिक जानकारी।
अतिरिक्त cli पैरामीटर। यहां हम उस चैनल को इंगित करते हैं जिसमें हमारा पैकेज गिर जाएगा, साथ ही अतिरिक्त पैरामीटर भी। ऑक्टोपस अनुभाग में इस पर अलग से चर्चा की जाएगी।

Deploy.3

Deploy.2 की तरह, केवल एक व्यक्तिगत मॉड्यूल पैकेज तैनात किया गया है।

Deploy.4

इस चरण को नीचे विस्तार से भी वर्णित किया जाएगा, क्योंकि यह ऑक्टोपस से डेटा प्राप्त करता है।

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

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

टीमसिटी: सारांश

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

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

स्वाभाविक रूप से, ऑक्टोपस सेटअप के साथ टीमकी सेटअप प्रक्रिया हाथ से चली गई। पाठ में समानांतर रूप से वर्णन करना असंभव है, क्योंकि भ्रम की एक बड़ी संभावना है। इसलिए, विवरण साझा किया गया है, और इस भाग में केवल CI प्रदान करने के चरणों का वर्णन किया गया है। ऑक्टोपस सेटअप प्रक्रिया निम्नलिखित में वर्णित की जाएगी।

CI / CD प्रक्रिया अपडेट: टीमसिटी