TFS 2010 और NuGetter का उपयोग करके लाइब्रेरी का एक नया संस्करण स्वचालित रूप से प्रकाशित करें

Dano

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

समस्याओं को आप हल करना चाहते हैं

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

समाधान और समस्याओं का सामना करना पड़ा

यह तुरंत स्पष्ट हो गया कि किसी भी समाधान का निर्माण करते समय लाइब्रेरी के नवीनतम / विशिष्ट संस्करण के साथ पैकेज प्राप्त करना NuGet के माध्यम से करना सबसे आसान है - Azure SDK के साथ काम करना एक समान दृष्टिकोण है।

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

परिणामस्वरूप, लाइब्रेरी के लिए बिल्ड डेफ़िनिशन (बिल्ड) जोड़ते हुए, प्रकाशन प्रक्रिया को TFS सर्वर पर स्थानांतरित करने का निर्णय लिया गया। इन सभी कार्यों को टीम एक्सप्लोरर वीएस 2010 में किया गया था, लेकिन वीएस 2012 में स्विच करने पर मुझे कोई विशेष अंतर नजर नहीं आया।

सर्वश्रेष्ठ के लिए खोजें

सहायक परियोजना के रूप में, NuGetter को TFSVersioning (सर्वर पर निर्माण के दौरान असेंबलीइन्फो फ़ाइल को संपादित करने के लिए) के साथ चुना गया था, परियोजनाओं का लेखक केवल एक ही था, और एकीकरण की कोई समस्या नहीं होनी चाहिए।

व्यक्तिगत कार्यान्वयन अनुभव का चरण-दर-चरण वर्णन

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

0. कॉन्फ़िगरेशन के लिए तैयारी - सर्वर पर अपलोड करें।

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

यह अनुशंसा की जाती है कि डिफ़ॉल्ट टेम्पलेट $/(Solution Name)/BuildProcessTemplates संग्रहीत करने के लिए फ़ोल्डर में वर्कफ़्लो टेम्पलेट डाले जाएं।
यह अनुशंसा की जाती है कि आप पुस्तकालयों और NuGet.exe फ़ाइल को एक अलग फ़ोल्डर में इसकी सेटिंग्स के साथ रखें (हमारे सर्वर पर इसका एक बहुत ही मूल नाम .nuget - लेकिन हमेशा शीर्ष पर, जो बिल्ड स्थापित करते समय सुविधाजनक होता है)।

इन पुस्तकालयों के निर्माण की प्रक्रिया में पाए जाने के लिए, आपको इस समाधान के लिए बिल्ड नियंत्रक को कॉन्फ़िगर करने की आवश्यकता है। यह निम्नानुसार किया जाता है:
टीम एक्सप्लोरर -> (सॉल्यूशन नेम) -> बिल्ड -> राइट क्लिक -> मैनेज बिल्ड कंट्रोलर्स ...


नियंत्रक चयन:


(समाधान नाम) के लिए एक नियंत्रक का संपादन:


Version control path to custom assemblies फ़ील्ड में Version control path to custom assemblies , आपको अपने साझा लाइब्रेरी फ़ोल्डर में पथ निर्दिष्ट करना होगा।

यहां मुझे पहली छोटी समस्या थी - मैंने नियंत्रक के गुणों को संपादित करने की कोशिश की , लेकिन इसके निर्माण एजेंटों में से एक की नहीं । सावधान रहें।
बस मामले में, फ़ोल्डर के कनेक्शन की जांच करें ( Test Connection बटन)।
कनेक्शन की जांच करने के बाद, परिवर्तनों को सहेजें।

1. टेम्पलेट के आधार पर एक नया निर्माण जोड़ना।

अब आपको पिछले चरण में लोड किए गए टेम्पलेट के अनुसार एक नया बिल्ड जोड़ने की आवश्यकता है। यह निम्नानुसार किया जाता है:
टीम एक्सप्लोरर -> (समाधान नाम) -> बनाता है -> राइट क्लिक -> नई बिल्ड परिभाषा ...


नाम और निर्माण का विवरण:


बिल्ड लॉन्च करने के लिए अनुसूची:

विकल्प:

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

कोड को बिल्ड के दौरान एकत्र किया जाना चाहिए:

कभी-कभी यहां बहुत सारी परियोजनाएं होती हैं - अनावश्यक को हटा दें। आप यह भी निर्दिष्ट कर सकते हैं कि निर्माण के दौरान कौन से प्रोजेक्ट को फ़ोल्डर में कॉपी किया जाना चाहिए।

बिल्ड के लिए डिफ़ॉल्ट पैरामीटर को परिभाषित करना:

आपको चुनना होगा:

• नियंत्रक जो पिछले पैराग्राफ में कॉन्फ़िगर किया गया था।
• कोड कहां रखें:
  
  • कहीं भी विधानसभा के परिणाम की नकल न करें।
  • साझा फ़ोल्डर में प्रतिलिपि बनाएँ परिणाम
    फॉर्म \\server\share एक वैध यूएनसी पता आवश्यक है ।
  • TFS सर्वर फ़ोल्डर में बिल्ड परिणाम की प्रतिलिपि बनाएँ
    बिल्ड बनाने वाले उपयोगकर्ता के अधिकारों के आधार पर विकल्प हमेशा उपलब्ध नहीं होता है ।

सेटिंग बनाएँ:

पहले तीन बिंदु ऐसी सेटिंग्स हैं जो किसी भी बिल्ड के लिए हमेशा उपलब्ध होती हैं। अब हमारे लिए, केवल पहला ब्लॉक ब्याज का है - विधानसभा के लिए परियोजनाओं या समाधान का विकल्प ( Projects to Build )।

Build number format भी ध्यान देने योग्य है - यह पैरामीटर बिल्ड परिणाम के साथ फ़ोल्डर के नाम के लिए ज़िम्मेदार है (फ़ोल्डरों के एक बड़े नेस्टिंग वाले प्रोजेक्ट के लिए यह बहुत लंबा नहीं होना चाहिए)।

बिल्ड परिणामों को बचाने के लिए सेटिंग्स:


2. बिल्ड के लिए टेम्पलेट चुनना।

ऊपरी हिस्से में Process टैब पर, ड्रॉप-डाउन सूची में, आवश्यक टेम्पलेट का चयन करें। यदि वांछित ड्रॉप-डाउन सूची में दिखाई नहीं दे रहा है, तो इसका मतलब है कि यह पहली बार उपयोग किया जाएगा, और इसे सर्वर को New... बटन का उपयोग करके "दिखाया" जाना चाहिए (टीएफएस सर्वर पर पहले से अपलोड की गई फ़ाइल का चयन करें या कॉपी करें)। हलवा, यह ऐलिस है, ऐलिस, यह हलवा है।

खाका चयन:


विकल्प:

• [TFS सर्वर पर स्थापित सभी निर्माण टेम्पलेट्स]।
• VersioningBuildTemplate.xaml - असेंबलीInfo.cs फ़ाइल में संस्करणों को बदलने के लिए मूल टेम्पलेट।
• VersioningBuildTemplate15.xaml - असेंबली में प्रतिस्थापन के लिए टेम्पलेट .fo फ़ाइल - संस्करण TFSVersioning 1.5 में उपलब्ध पुस्तकालय गुणों के संपादन के लिए अतिरिक्त सुविधाएँ।
• NuGetterStandardBuildTemplate.xaml - NuGet के लिए परिणाम बनाने के प्रकाशन के लिए एक बुनियादी टेम्पलेट।
• NuGetterVersioningBuildTemplate.xaml - NuGet के निर्माण परिणामों को प्रकाशित करने और असेंबली NuGetterVersioningBuildTemplate.xaml फ़ाइल में संस्करणों को बदलने के लिए एक मूल टेम्पलेट।
• NuGetterVersioningBuildTemplate15.xaml - NuGet के निर्माण परिणामों को प्रकाशित करने के लिए एक टेम्पलेट और संस्करण TFSVersioning 1.5 से अतिरिक्त सुविधाओं के साथ असेंबलीInfo.cs फ़ाइल में प्रतिस्थापित करना।

3. असेंबलीइन्फो.के.एक्स फ़ाइल में प्रतिस्थापन को कॉन्फ़िगर करना।

यदि TFSVersioning की भागीदारी वाला टेम्पलेट चुना गया था, तो बिल्ड सेटिंग्स दिखाई देंगी
बिंदु संख्या 4:

आपको क्या और क्यों चाहिए:

• पहली दो पंक्तियाँ AssemblyFileVersion और AssemblyVersion वर्जन के लिए वर्जन नंबर टेम्प्लेट के लिए ज़िम्मेदार हैं।
• संस्करण संख्या टेम्पलेट के लिए प्रतिस्थापन नियम:
  
  • टेम्पलेट में कहीं भी पाया गया नंबर अपरिवर्तित रहता है।
  • B को एक दिन के भीतर बिल्ड नंबर से बदल दिया जाता है।
  • YYYY को वर्तमान वर्ष के 4 अंकों के प्रतिनिधित्व के साथ बदल दिया गया है।
  • YY को वर्तमान वर्ष (अंतिम दो अंक) के 2 अंकों के प्रतिनिधित्व के साथ बदल दिया जाता है।
  • MM या M को वर्तमान महीने की संख्या के साथ बदल दिया जाता है (जब MM जगह शून्य को सामने नहीं रखा जाता है )।
  • DD या D को महीने में वर्तमान दिन की संख्या से बदल दिया जाता है (जब DD जगह शून्य को सामने नहीं रखा जाता है )।
  • J को प्रारूप YYDDD में एक तारीख से बदल दिया गया है, जहां DDD वर्ष की शुरुआत से दिन का क्रम है।
  
  प्रस्तावित डिफ़ॉल्ट टेम्प्लेट, 1.0.JB , लाइब्रेरी के लिए लगभग अद्वितीय संस्करण संख्या प्रदान करता है। 100 वर्षों में कठिनाइयाँ शुरू होंगी, बशर्ते कि परियोजना के प्रमुख और छोटे संस्करणों को संरक्षित किया जाए। लिगेसी कोड वापस हमला करता है।
  
• तीसरी लाइन असेंबली प्रोजेक्ट्स में असेंबलीइन्फो फाइल्स खोजने के लिए एक मास्क है। आमतौर पर संपादन की आवश्यकता नहीं होती है।
• चौथी पंक्ति वह संख्या है जिसे संख्या B जोड़ा जाएगा B इसका उपयोग तब किया जा सकता है जब आप एक प्रोजेक्ट के लिए कई बिल्ड कॉन्फ़िगर करते हैं - 100 को एक, 200 को दूसरे में जोड़ें, हर कोई खुश है। बिल्ड संख्या और उपसर्ग के योग का अधिकतम मूल्य 65535 है । परियोजनाओं के लेखक भी उनसे संपर्क करने के लिए कहते हैं यदि आप एक दिन में 999 से अधिक निर्माण करते हैं, तो आप स्पष्ट रूप से कुछ दिलचस्प के साथ व्यस्त हैं।
• पांचवीं पंक्ति इंगित करती है कि क्या वे AssemblyVersion AssemblyFileVersion और AssemblyVersion विशेषताओं को बनाना चाहते हैं यदि वे गायब हैं।
• छठी पंक्ति इंगित करती है कि डेटा स्टोर में संशोधित असेंबलीइन्फो फ़ाइलों को अपलोड करना है या नहीं।

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

 <?xml version="1.0" encoding="utf-8" ?> <VersionSeed> <Solution name="Default"> <AssemblyVersionPattern>1.8.jb</AssemblyVersionPattern> <AssemblyFileVersionPattern>1.8.jb</AssemblyFileVersionPattern> </Solution> <NuGetPackage id="ServiceLib"> <VersionPattern>1.8.jb</VersionPattern> </NuGetPackage> </VersionSeed> 

यदि आप TFSVersioning 1.5 के लिए बिल्ड टेम्पलेट का उपयोग करते हैं, तो आप भी उपलब्ध होंगे
असेंबली में अतिरिक्त स्वतः पूर्ण सुविधाओं के साथ टैब


4. नुगेट में प्रकाशन की स्थापना।

NuGetter के लिए टेम्पलेट का उपयोग करते समय, तीन और टैब उपलब्ध हैं।
NuGetter (ए) - प्री-पैकेजिंग:

पहले टैब पैकेजिंग और प्रकाशन के लिए इकट्ठे प्रोजेक्ट को तैयार करने के लिए जिम्मेदार है। यदि आवश्यक हो, तो आप सर्वर पर अपनी PowerShell स्क्रिप्ट जोड़ सकते हैं (उदाहरण के लिए, NuGet विनिर्देश में निर्दिष्ट फ़ोल्डर बनाने के लिए)।

सावधान रहें: निष्पादन योग्य PowerShell स्क्रिप्ट को सर्वर पर निष्पादित होने से प्रतिबंधित किया जा सकता है। इस स्थिति में, बिल्ड एक त्रुटि नहीं देगा , लेकिन बस NuGet को चलाने का प्रयास करें जैसे कि स्क्रिप्ट सही तरीके से काम करती है।
PowerShell स्क्रिप्ट के निष्पादन के बारे में नीति को आदेशों के माध्यम से जांचा और ठीक किया जा सकता है

 Get-ExecutionPolicy Set-ExecutionPolicy 

NuGetter (B) - पैकेज:

आपको क्या और क्यों चाहिए:

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

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

NuGetter (C) - पुश और प्रकाशित करें:

आपको क्या और क्यों चाहिए:

• पहली पंक्ति API कुंजी है, अगर NuGet रिपॉजिटरी के लिए परिभाषित किया जाता है जहां पैकेज प्रकाशित होता है। लेखक एक GUID की अपेक्षा करता है कि वह aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee प्रवेश कर सकता है, यदि निर्दिष्ट कुंजी रेगेक्स चेक पास नहीं करता है, तो लाइन को उस फ़ाइल के सापेक्ष पथ माना जाता है जिसमें एपीआई कुंजी निर्दिष्ट है ।
• दूसरी पंक्ति इंगित करती है कि क्या आपको केवल पैकेज बनाने और उसे रिपॉजिटरी में कॉपी करने की आवश्यकता है या यदि दूरस्थ सर्वर पर प्रकाशन की आवश्यकता है। वास्तव में, जब ध्वज चालू होता है, तो यह NuGet स्टार्टअप पैरामीटर में -co पैरामीटर जोड़ता है , जो संपूर्ण बिल्ड को नष्ट कर देता है, क्योंकि संस्करण 2.1 में पैरामीटर को मान्यता नहीं दी जाती है।
• तीसरी पंक्ति इंगित करती है कि पैकेज बनाने के बाद उसे प्रकाशित करने का प्रयास करना है या नहीं।
• चौथी पंक्ति प्रकाशन के लिए NuGet भंडार का पता है।
  संभावित मूल्य:
  
  • दूरस्थ रिपॉजिटरी का URL।
  • स्थानीय नेटवर्क पर फ़ोल्डर का UNC नाम।
  • सर्वर पर फ़ोल्डर का स्थानीय पता जहां निर्माण शुरू होता है।
  
  

हम बिना किसी अतिरिक्त के मानक NuGet सर्वर का उपयोग करते हैं।

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

5. बिल्ड लॉन्च करना।

बिंदु 1 से सेटिंग के अनुसार निर्माण को स्वचालित रूप से शुरू करने के अलावा, निर्माण मैन्युअल रूप से शुरू किया जा सकता है।
टीम एक्सप्लोरर -> (समाधान का नाम) -> बनाता है -> लॉन्च करने के लिए निर्माण -> राइट क्लिक -> नया बिल्ड कतार ...


वर्तमान स्थिति के साथ रनिंग टेबल की तालिका:


6. कुल

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

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

मुझे उम्मीद है कि यह लेख किसी के समय और तंत्रिकाओं को बचाता है।
आपका ध्यान देने के लिए धन्यवाद।