🆎 👽 🤚🏼 शुरुआती के लिए टीमसिटी सेटअप ✌🏿 ⤴️ 🤴🏿

यह आलेख उन लोगों के लिए मुख्य रूप से उपयोगी है जो हमारी टीम के रूप में एक ही प्रौद्योगिकी स्टैक का उपयोग करते हैं, अर्थात्: ASP.NET, C #, NUnit, Selenium 2, git, MSBuild। गिट के साथ एकीकरण, सी # प्रोजेक्ट्स की असेंबली, NUnit परीक्षण (यूनिट और UI दोनों परीक्षण), साथ ही सर्वर पर तैनाती के रूप में इस तरह के कार्यों पर विचार किया जाएगा। हालाँकि, इस मुद्दे पर कुत्ते को खाने के अलावा, अन्य उपयोगकर्ताओं के लिए निश्चित रूप से दिलचस्प चीजें होंगी। लेकिन फिर, वे लेख में त्रुटियों पर ध्यान देने या कुछ सलाह देने में सक्षम होंगे: उदाहरण के लिए, परिनियोजन चरण का अनुकूलन कैसे करें।

"निरंतर एकीकरण" क्या है, पूरी तरह से यहां और यहां वर्णित है , सौवीं बार इस विषय को दोहराना शायद ही आवश्यक है।

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

महत्वपूर्ण बिंदु यह है कि "एकीकरण सर्वर" और "मशीन जिस पर यह प्रक्रिया होगी" आम तौर पर (आवश्यक नहीं) विभिन्न सर्वर हैं। इसके अलावा, कई, यहां तक कि कई मशीनें भी हो सकती हैं, जिन पर असेंबली और परीक्षण चलाए जाते हैं, और सभी अलग-अलग ओएस पर - सामान्य तौर पर, जहां पर तैनात करना है।

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

अब आपको कार्य परिदृश्य के साथ आने की जरूरत है। हम अपने काम में निम्नलिखित शाखाओं का उपयोग करते हैं:

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

सामान्य तौर पर, लगभग मानक गिट-प्रवाह, जिसे अधिक विस्तार से पढ़ा जा सकता है, उदाहरण के लिए, यहां ।

इस संबंध में, हमारी स्क्रिप्ट इस तरह दिखाई देगी:

देव शाखा के भंडार से नवीनतम परिवर्तन उठाएं;
परियोजना को संकलित करें;
यदि पिछले चरण में सब कुछ ठीक रहा है - इकाई परीक्षण चलाएं;
यदि पिछले चरण में सब कुछ ठीक रहा है - कार्यात्मक परीक्षण चलाएं;
यदि पिछले चरण में सबकुछ ठीक हो गया है - परीक्षण सर्वर पर परिवर्तन अपलोड करें।

रिलीज शाखा के लिए, हम एक ही काम करते हैं, लेकिन नए डेटा को भरने के दौरान, हम सर्वर को रोकते हैं और स्टब दिखाते हैं।

अब, आगे बढ़ें - स्क्रिप्ट को लागू करें!

भंडार से नवीनतम परिवर्तन खींचो

यह सब एक परियोजना के सरल निर्माण के साथ शुरू होता है।

" बिल्ड कॉन्फ़िगरेशन " बनाने के बाद। कॉन्फ़िगरेशन बिल्ड स्क्रिप्ट को परिभाषित करता है।

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

तो, प्रमुख सेटिंग्स:

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

विकल्पों की विविधता आपके स्वाद और रंग के लिए है।

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

संकलित परियोजना

चूंकि हमारे पास Visual Studio से एक समाधान के रूप में ASP.NET प्रोजेक्ट था, इसलिए यहां भी सब कुछ सरल था।

हम बिल्ड स्टेप्स मेनू पर जाते हैं, रनर टाइप का चयन करें (और वास्तव में उनमें से बहुत सारे हैं) और MSBuild पर रुकें । क्यों बिल्कुल उस पर? यह असेंबली प्रक्रिया का वर्णन करने के लिए काफी सरल तरीका प्रदान करता है, यहां तक कि एक साधारण XML फ़ाइल में विभिन्न चरणों को जोड़कर या हटाकर भी पर्याप्त जटिल है।

इसके अलावा, सब कुछ प्राथमिक है।

फ़ाइल पथ - sln फ़ाइल का पथ बनाएँ।
हम आपकी परियोजना की आवश्यकताओं के लिए MSBuild संस्करण , MSBuild ToolsVersion और Run प्लेटफ़ॉर्म चुनें ।

यदि प्रोजेक्ट में कई कॉन्फ़िगरेशन हैं, तो आप इस कुंजी की तरह कुछ दर्ज करने के लिए कमांड लाइन पैरामीटर विकल्प का उपयोग कर सकते हैं:

/p:Configuration=Production

जहाँ उत्पादन वांछित विन्यास से बदल दिया जाता है।

डाउनलोड नूगेट संकुल सक्षम करें

एक महत्वपूर्ण बिंदु यदि आप NuGet पैकेज का उपयोग करते हैं; यदि नहीं, तो आप सीधे अगले आइटम पर जा सकते हैं।

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

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

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

यूनिट टेस्ट ड्राइव करें

हमारी इकाई परीक्षण समाधान के भीतर एक अलग परियोजना है। इसलिए पिछले चरण में वे पहले से ही संकलित हैं - यह उन्हें चलाने के लिए बनी हुई है।

एक नया चरण जोड़ें, केवल अब धावक NUnit है । Execute step पैरामीटर पर ध्यान दें: यह उन परिस्थितियों को इंगित करता है जिनके तहत कदम का प्रदर्शन किया जाना चाहिए, और इसमें 4 मान हैं:

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

यहां सबसे महत्वपूर्ण बात यह है कि कॉलम से रन परीक्षणों में परियोजना के अंदर परीक्षणों के साथ विधानसभा के लिए सही रास्ता इंगित करना है। यहाँ, उदाहरण के लिए, यह इस तरह दिखता है:

 %teamcity.build.checkoutDir%\project\project.FuncTests\bin\Dev\project.FuncTests.dll

% teamcity.build.checkoutDir% एक चर है जो उस फ़ोल्डर की ओर इशारा करता है जहां रिपॉजिटरी से डेटा डाउनलोड किया जाता है। सिद्धांत रूप में, यह इंगित करने के लिए आवश्यक नहीं है, जैसा कि डिफ़ॉल्ट रूप से, पथ इस निर्देशिका के संबंध में जाता है, इसलिए पथ को छोटा किया जा सकता है:

 project\project.FuncTests\bin\Dev\project.FuncTests.dll

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

इंटरफ़ेस परीक्षण चलाएं (कार्यात्मक परीक्षण)

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

  [SetUpFixture] class ServerInit { private const string ApplicationName = "justtest"; private Process _iisProcess; private string GetApplicationPath(string applicationName) { var tmpDirName=AppDomain.CurrentDomain.BaseDirectory.TrimEnd('\\'); var solutionFolder = Path.GetDirectoryName(Path.GetDirectoryName(Path.GetDirectoryName(tmpDirName))); string result = Path.Combine(solutionFolder, applicationName); return result; } [SetUp] public void RunBeforeAnyTests() { […] var applicationPath = GetApplicationPath(ApplicationName); var programFiles = Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles); _iisProcess = new Process { StartInfo = { FileName = string.Format("{0}/IIS Express/iisexpress.exe", programFiles), Arguments = string.Format("/path:\"{0}\" /port:{1}", applicationPath, UrlProvider.Port) } }; _iisProcess.Start(); } [TearDown] public void RunAfterAnyTests() { […] if (_iisProcess.HasExited == false) { _iisProcess.Kill(); } } }]

और लॉन्च स्वयं इकाई परीक्षणों के साथ कदम पर बिल्कुल वैसा ही दिखता है।

परीक्षण सर्वर पर परिवर्तन अपलोड करें

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

योजना इस प्रकार है:

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

यह वही है जो इस फ़ाइल की तरह दिखेगा (

 <?xml version="1.0" encoding="utf-8"?> <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0" DefaultTargets="Build"> <UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.Tasks.dll"/> <Import Project="$(MSBuildExtensionsPath32)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets"/> <PropertyGroup> <OutputDir>bin</OutputDir> <PublishDir>../output</PublishDir> <Configuration>Dev</Configuration> <TransformInputFile>..\project\project\Web.template.config</TransformInputFile> <TransformFile>..\project\project\Web.$(Configuration).config</TransformFile> <TransformOutputFile>..\project\output\Web.config</TransformOutputFile> <StackTraceEnabled>False</StackTraceEnabled> </PropertyGroup> <ItemGroup> <ProjectToBuild Include="../project/project.sln"> <Properties>WebProjectOutputDir=$(PublishDir);OutputPath=$(OutputDir);Configuration=Dev</Properties> </ProjectToBuild> </ItemGroup> <Target Name="Build"> <MSBuild Projects="@(ProjectToBuild)"/> </Target> <Target Name="CreateWebConfigs" AfterTargets="Build"> <TransformXml Source="$(TransformInputFile)" Transform="$(TransformFile)" Destination="$(TransformOutputFile)" /> </Target> <Target Name="AfterBuild" AfterTargets="CreateWebConfigs"> <PropertyGroup> <ftpHost>dev.example.com</ftpHost> <ftpUser></ftpUser> <ftpPass></ftpPass> <LocalDirectory>..\project\output</LocalDirectory> </PropertyGroup> <FtpUploadDirectoryContent ServerHost="$(ftpHost)" Port="21" Username="$(ftpUser)" Password="$(ftpPass)" LocalDirectory="$(LocalDirectory)" RemoteDirectory="" Recursive="true" /> </Target> </Project>

और इसलिए - उसे बुलाने का कार्य:

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

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

रिलीज़ स्क्रिप्ट के लिए सर्वर को रोकें और शुरू करें

हम इसे थोड़ा जंगली, लेकिन प्यारे तरीके से हल करते हैं। IIS में एक ख़ासियत है: यदि आप साइट के मूल में app_offline.html नाम के साथ एक फ़ाइल डालते हैं , तो साइट काट दी जाती है, जब सभी फ़ाइलों तक पहुंच होती है, तो इस फ़ाइल की सामग्री प्रदर्शित की जाएगी।

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

हम WinSCP स्क्रिप्ट और ऐसी फ़ाइलों के माध्यम से सर्वर को यहाँ सक्षम / अक्षम करते हैं:

server_off.cmd

 winscp.exe /console /script=server_off.txt

server_on.cmd

 winscp.exe /console /script=server_on.txt

server_off.txt

 option batch abort option confirm off open ftp://:@dev.example.com mv _app_offline.htm app_offline.htm close exit

server_on.txt

 option batch abort option confirm off open ftp://:@dev.example.com rm app_offline.htm close exit

यही है, शुरू में फ़ाइल रूट में निहित है और इसे _app_offline.html कहा जाता है। जब आपको अपडेट के दौरान एक्सेस ब्लॉक करने की आवश्यकता होती है, तो हम इसका नाम बदलकर app_offline.html कर देते हैं । फ़ाइलें अपलोड करते समय, नई _app_offline.html फ़ाइल अपलोड की जाती है , और समाप्ति के बाद, app_offline.html फ़ाइल हटा दी जाती है । और हमें वही मिलता है जो मूल रूप से था।

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

स्टब को सक्षम करने के लिए स्क्रिप्ट को कॉल करना (स्टब को अक्षम करना समान है):

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

हमने लगभग छह महीने तक इन सेटिंग्स का उपयोग किया, और अब तक कोई समस्या नहीं आई है - सब कुछ एक घड़ी की तरह काम करता है, जो अच्छी खबर है।

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

3 नवंबर 2014 का अपडेट।
रनर टाइप "कमांड लाइन" को चुनने के लिए रिक्त स्थान से बचने के लिए किसी भी तरह की आवश्यकता नहीं होती है - टीम सिटी अपने आप ही इस बात का ध्यान रखेगा।

शुरुआती के लिए टीमसिटी सेटअप