क्या आप अभी भी प्रोजेक्ट को मैन्युअल रूप से प्रकाशित कर रहे हैं? फिर हम आपके पास जाते हैं

कटलाइन के तहत, .NET प्रोजेक्ट्स के लिए CI को खरोंच से लागू करने के लिए एक दिशानिर्देश, जिसमें शामिल हैं:

1. स्वचालित दैनिक बनाता है
2. समस्या सूचनाएँ
3. बग ट्रैकर और संस्करण नियंत्रण प्रणाली के साथ एकीकरण
4. उत्पाद संस्करण
5. डेटाबेस संस्करण
6. स्वचालित गणना और बैकअप

के साथ शुरू करने के लिए, "निरंतर एकीकरण" क्या है?

निरंतर एकीकरण (Eng। सतत एकीकरण) - यह सॉफ्टवेयर विकास की प्रथा है, जिसमें एकीकरण समस्याओं को जल्दी से पहचानने और हल करने के लिए परियोजना के लगातार स्वचालित विधानसभाओं के कार्यान्वयन में शामिल है।

व्यावहारिक दृष्टिकोण से, इसका मतलब है कि किसी भी समय आपके पास "उत्पाद का लाइव, वर्तमान संस्करण" होना चाहिए जिसे आप परीक्षण और प्रदर्शित कर सकते हैं।
ऐसा करने के लिए, आपको चाहिए:

1. ताकि डेवलपर्स कम से कम हर दिन वीसीएस में अपने कोड का योगदान दें
2. उत्पाद विधानसभा स्वचालित रूप से हुई
3. उत्पाद प्रदर्शन (डेटाबेस को अद्यतन करने सहित) स्वचालित रूप से हुआ
4. उत्पाद परीक्षण स्वचालित था (जितना संभव हो उतना)

निरंतर एकीकरण फुर्तीली प्रथाओं को संदर्भित करता है। एजाइल में पुनरावृत्ति प्रक्रिया के साथ विकास, परीक्षण और उत्पाद विकास के चक्र को दोहराया जाता है। नियमित प्रक्रियाओं का स्वचालन कई नियमित संचालन से बचता है।

VCS के साथ काम करें

सबसे पहले, हमें आवेदन का परीक्षण करने के लिए एक परीक्षण वातावरण की आवश्यकता है। यदि परीक्षण चक्र काफी लंबा है, और विकास तेज है, तो यह देव वातावरण को भी उजागर करने के लिए समझ में आता है। VCS संरचना आपके परिवेश को प्रतिबिंबित करेगी।
सभी डेवलपर्स मुख्य विकास शाखा के साथ काम करते हैं, फिर एक निश्चित संस्करण तय किया जाता है और परीक्षण शाखा में विलय हो जाता है। परीक्षण शाखा से परीक्षण वातावरण पर एक गणना होती है। कुंवारी में परीक्षण, फिक्सिंग और रिवर्स मर्ज का प्रदर्शन किया जाता है। परीक्षण किया गया संस्करण रिलीज़ शाखा को भेजा जाता है और वहाँ से उत्पादन के लिए प्रकाशित किया जाता है। यदि उत्पादन पर गलतियाँ हैं (दुर्भाग्य से, ऐसा होता है), हम इसे उत्पादन शाखा से आपातकालीन मोड में ठीक करते हैं और फिर से हम इसे डीईवी शाखा में रखते हैं।

दर्शन में, जीआईटी थोड़ा अलग होगा, क्योंकि जीआईटी के साथ काम करने के बाद यह मास्टर और यहां तक ​​कि देव के लिए प्रतिबद्ध करने के लिए प्रथागत नहीं है। इसके बजाय, फीचर-ब्रांड दृष्टिकोण का अभ्यास किया जाता है। आप यहाँ git वर्कफ़्लो के बारे में पढ़ सकते हैं: habrahabr.ru/post/60030 । सामान्य तौर पर, सभी प्रस्तावित वीसीएस संरचनाओं का एक लक्ष्य होता है: ऐसी स्थिति से बचने के लिए जहां विकास शाखा स्थिर नहीं है, और यह जल्दी से "ठीक" या "खत्म" करने के लिए बिल्कुल आवश्यक है और इसे पूरा करें। अपनी संरचना चुनते समय, अपने आप से सवाल पूछें “क्या मैं एक दिन के लिए उत्पादन कर सकता हूं और सब कुछ नहीं तोड़ सकता। यदि उत्तर हां है, तो संरचना आपके लिए सही है।

उत्पादन त्रुटियों को याद नहीं करने के लिए, आपको परीक्षण वातावरण को यथासंभव लक्ष्य के करीब बनाना चाहिए। आमतौर पर, मुख्य कठिनाई तृतीय-पक्ष वेब सेवाओं या अन्य घटकों और वास्तविक वित्तीय लेनदेन से जुड़े संचालन पर निर्भरता है।

विन्यास

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

<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.Tasks.dll" /> <Target Name="AfterCompile" Condition="Exists('App.$(Configuration).config')"> <!--Generate transformed app config in the intermediate directory--> <TransformXml Source="App.config" Destination="$(IntermediateOutputPath)$(TargetFileName).config" Transform="App.$(Configuration).config" /> <!--Force build process to use the transformed configuration file from now on.--> <ItemGroup> <AppConfigWithTargetPath Remove="App.config" /> <AppConfigWithTargetPath Include="$(IntermediateOutputPath)$(TargetFileName).config"> <TargetPath>$(TargetFileName).config</TargetPath> </AppConfigWithTargetPath> </ItemGroup> </Target> 

नौसिखिया डेवलपर्स अक्सर स्थानीय मशीनों पर वेब.कॉन्फ़िग के परिवर्तनों को डिबगिंग करते समय अकड़ में पड़ जाते हैं: App.config के विपरीत, वे आवेदन स्तर पर संग्रहीत किए जाते हैं, और बिन फ़ोल्डर में नहीं, इसलिए परिवर्तन स्थानीय असेंबली के दौरान नहीं होता है। किसी प्रोजेक्ट को प्रकाशित करते समय रूपांतरण लागू होते हैं। यदि आपको वास्तव में इस सीमा के आसपास जाने की आवश्यकता है, तो आप Web.template.config फ़ाइल बना सकते हैं और PostBuild एप्लिकेशन में परिवर्तन जोड़ सकते हैं। परियोजना से परिवर्तन कार्य को हटाने के लिए मत भूलना, अन्यथा परिवर्तन दो बार लागू किया जाएगा।
यदि अनुप्रयोग में अन्य तकनीकों का उपयोग किया जाता है, तो संदर्भ सेटिंग्स को बदलने के लिए सामान्य सेटिंग्स और अतिरिक्त कॉन्फ़िगरेशन फ़ाइलों के साथ एक मुख्य कॉन्फ़िगरेशन फ़ाइल रखना अभी भी बेहतर है। यह आपको एक ही सेटिंग के कॉपी-पेस्ट से बचाएगा।

उन फ़ाइलों को जोड़ना जो परियोजना में गणना के लिए नहीं हैं

  <PropertyGroup> <CopyAllFilesToSingleFolderForPackageDependsOn> CustomCollectFiles; $(CopyAllFilesToSingleFolderForPackageDependsOn); </CopyAllFilesToSingleFolderForPackageDependsOn> </PropertyGroup> <Target Name="CustomCollectFiles"> <!-- Copy JavaScript files --> <ItemGroup> <CompressedScripts Include="Sources\**\*.js" /> <FilesForPackagingFromProject Include="%(CompressedScripts.Identity)"> <DestinationRelativePath>Sources\%(RecursiveDir)%(Filename)%(Extension)</DestinationRelativePath> </FilesForPackagingFromProject> </ItemGroup> <!-- Copy stylesheets --> <ItemGroup> <CompressedScripts Include="Sources\**\*.css" /> <FilesForPackagingFromProject Include="%(CompressedScripts.Identity)"> <DestinationRelativePath>Sources\%(RecursiveDir)%(Filename)%(Extension)</DestinationRelativePath> </FilesForPackagingFromProject> </ItemGroup> </Target> 

उत्पाद संस्करण

.NET असेंबलिंग असेंबलियों के लिए 2 विशेषताएँ प्रदान करता है
[असेंबली: असेंबली वर्जन ("1.0.0.0")]
[असेंबली: असेम्बलीफाइलवर्जन ("1.0.0.0")]
पहले दो अंक प्रमुख और मामूली संस्करण संख्या हैं। ये संख्या कार्यात्मक परिवर्तन की वृद्धि की व्याख्या करती है। तीसरा अंक तथाकथित विधानसभा संख्या है। हर दिन, जबकि एक संस्करण विकास में है, यह संस्करण बढ़ता है। और आखिरी नंबर रिवीजन नंबर है। जब आप दिन में बिल्ड सर्वर पर संस्करण बनाते हैं तो यह संख्या बढ़ जाती है। .NET संस्करण नीतियों पर विवरण रिक्टर CLR में C # के माध्यम से वर्णित हैं।
स्वचालित संस्करण को कई तरीकों से कॉन्फ़िगर किया जा सकता है। इस विषय पर यहां विस्तार से चर्चा की गई है: stackoverflow.com/questions/1126880/how-can-i-auto-increment-the-c-sharp-assembly-version-via-our-ci-platform-hudso ।

मुख्य दृष्टिकोण

1. प्रपत्र 1.0 के संस्करण का उपयोग करना। *। * (बिल्ड सर्वर के साथ अच्छी तरह से काम नहीं करता है)
2. इस स्थान से सभी असेंबली के संस्करणों को प्रबंधित करने के लिए एक एकल फ़ाइल SharedAssemblyInfo का उपयोग करके सभी संस्करण में एक फ़ाइल बनाई जाती है और "लिंक के रूप में" सभी परियोजनाओं में जोड़ा जाता है
3. असेंबलीइंफो फ़ाइल के बजाय msbuild का उपयोग करना
4. TFS के लिए, आप WWF- गतिविधि का उपयोग कर सकते हैं

मेरी राय में, यह msbuild का उपयोग करने के लिए सबसे सुविधाजनक है और CI सर्वर का उपयोग करके मूल्य को नीचे रखा गया है:

 <Major>1</Major> <Minor>0</Minor> <Build>$(BUILD_NUMBER)</Build> 

सभी आधुनिक CI समाधान बिल्ड समय पर इस तरह के एक चर की पेशकश करते हैं। काम करने के लिए इस दृष्टिकोण के लिए, आपको msbuildtasks.tigris.org से आयात msbuild कार्यों को जोड़ने और परियोजना के अंत में जोड़ने की आवश्यकता है:

 <Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" Condition="Exists('$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets')" /> <Target Name="BeforeBuild" Condition="Exists('$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets')"> <Message Text="Version: $(Major).$(Minor).$(Build).$(Revision)" /> <AssemblyInfo CodeLanguage="CS" OutputFile="AssemblyFileInfo.cs" AssemblyFileVersion="$(Major).$(Minor).$(Build).$(Revision)" AssemblyConfiguration="$(Configuration)" Condition="$(Revision) != '' " /> </Target> 

डेटाबेस संस्करण

मुझे एक भी परियोजना का पता नहीं है जिसमें मुझे डेटाबेस में बदलाव नहीं करना पड़ेगा। .NET निम्नलिखित समाधान प्रदान करता है:

SSDT प्रोजेक्ट msdn.microsoft.com/en-us/data/tools.aspx

पेशेवरों: एक डेटाबेस बनाने और संपादित करने की प्रक्रिया जैसा दिखता है कि आप इसे प्रबंधन स्टूडियो के साथ कैसे करेंगे।
विपक्ष: माइग्रेशन स्क्रिप्ट लिखने में कठिनाई। क्योंकि वृद्धिशील परिवर्तन परियोजना द्वारा ही किए जाते हैं, डेटा सुरक्षा पूर्व-परिनियोजित और पश्च-पोस्ट स्क्रिप्ट द्वारा सुनिश्चित की जाती है। आपको डेटाबेस में फ़ील्ड्स की मौजूदगी / अनुपस्थिति पर भरोसा करना होगा या माइग्रेशन इंजन में पहले से लागू स्कीमा वर्जन टेबल को “आविष्कार” करना होगा।

ECM7 माइग्रेटर कोड. google.com/p/ecm7migrator

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

इकाई फ्रेमवर्क माइग्रेशन blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-code-based-migrations-walkthrough.aspx

पेशेवरों: बॉक्स से बाहर काम करता है, स्वचालित रूप से डीबी संदर्भ में माइग्रेशन बनाता है, दृश्य स्टूडियो कंसोल से कमांड को समझता है, विज़ुअल स्टूडियो से मानक प्रकाशित का उपयोग करके माइग्रेशन प्रकाशित होते हैं।
विपक्ष: इकाई ढांचे पर निर्भर करता है।

---

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

स्वचालित प्रकाशन प्रकाशित करें

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




जैसा कि स्क्रीनशॉट में देखा जा सकता है, WebDeploy के नवीनतम संस्करण में, आप केवल एक चेकमार्क के साथ EF माइग्रेशन चला सकते हैं। इसके अलावा, स्टूडियो से एक प्रकाशन परिवर्तन का उपयोग किए बिना कनेक्शन स्ट्रिंग को बदल सकता है।
परिवर्तन और प्रकाशन के बारे में विवरण ट्रॉय हंट ने एक लेख में लिखा है: www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity.html । अब हम उसके दिशानिर्देश के पांचवें चरण में रुचि रखते हैं, अर्थात्, बिल्ड सर्वर का उपयोग करके स्वचालित प्रकाशन: www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_26.html । मैं टीमसिटी का बहुत बड़ा प्रशंसक हूं, तो आइए इस विशेष सीआई को देखें।

स्वचालित Windows सेवा प्रकाशन

विंडोज़ कमांड को स्वचालित रूप से बनाने का सबसे आसान तरीका sc कमांड का उपयोग करना है:

 sc [<ServerName>] create|stop|start <ServiceName> binpath= <BinPath> start= demand 

एकमात्र सूक्ष्म बिंदु यह है कि बायनेरिज़ को <BinPath> तक कैसे पहुँचाया जाए। आप इसे विभिन्न तरीकों से कर सकते हैं: FTP के माध्यम से अपलोड करें, PowerShell का उपयोग करें, सर्वर पर साझा किए गए फ़ोल्डर में xcopy / robocopy या rsync का उपयोग करें। चुनाव आपके नेटवर्क पर्यावरण और सुरक्षा आवश्यकताओं पर निर्भर करता है।

TeamCity

ऊपर वर्णित टूल का उपयोग करने से आपका समय बचेगा। चलो आगे बढ़ते हैं और बिल्ड सर्वर स्थापित करते हैं। TeamCity डाउनलोड करें: www.jetbrains.com/teamcity और इंस्टॉलर चलाएं, हर जगह ओके पर क्लिक करें।
TeamCity की दो मुख्य अवधारणाएँ "प्रोजेक्ट" और "बिल्ड" हैं। "प्रोजेक्ट" आपके समाधान से मेल खाता है, और बिल्ड आपके प्रोजेक्ट पर कार्यों के किसी भी सार्थक सेट को संदर्भित करता है: चाहे वह कोडांतरण हो, परीक्षण चल रहा हो, इसे सर्वर पर अपलोड करना, बैकअप बनाना, और इसी तरह।

स्वचालित लेआउट

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

 /P:Configuration=%env.Configuration% /P:DeployOnBuild=True /P:DeployTarget=MSDeployPublish /P:MsDeployServiceUrl=https://%env.TargetServer%/MsDeploy.axd /P:AllowUntrustedCertificate=True /P:MSDeployPublishMethod=WMSvc /P:CreatePackageOnPublish=True /P:UserName=AutoDeploy\Administrator /P:Password=Passw0rd 

ये विकल्प इंगित करेंगे कि आप कहां प्रकाशित करना चाहते हैं।
माइग्रेशन प्रकाशित करने के लिए, एक अतिरिक्त कमांड लाइन कदम की आवश्यकता है:

 SET AssemblyName=MyMvc4App SET StartUpDirectory=MyMvc4App\bin\ SET ConnectionString=Server=tcp:XXXX.database.windows.net,1433;Database=XXXX;User ID=XXXX;Password=XXXX;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;MultipleActiveResultSets=True SET ConnectionStringProvider=System.Data.SqlClient SET ConfigFilePath=%CD%\MyMvc4App\web.config SET MigrateExe=packages\EntityFramework.5.0.0\tools\migrate.exe %MigrateExe% %AssemblyName%.dll /startUpDirectory:%StartUpDirectory% /startUpConfigurationFile:"%ConfigFilePath%" /connectionProviderName:"%ConnectionStringProvider%" /connectionString:"%ConnectionString%" /verbose 

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

रोलिंग बनाता है

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

कैसे नहीं तोड़ा जाए निर्माण

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

स्वचालित रूप से परीक्षण चलाएं

इस चरण को 2 में विभाजित किया जाना चाहिए: इकाई परीक्षण और एकीकरण और स्वीकृति परीक्षण। यह महत्वपूर्ण है क्योंकि इकाई परीक्षण किसी भी वातावरण पर काम करना चाहिए। सभी बाहरी निर्भरता को नकली द्वारा प्रतिस्थापित किया जाता है।

यूनिट परीक्षण चल रहा है

यहां सब कुछ सरल है। बिल्ड स्टेप "नूनिट" या "एमएसटेस्ट" चुनें, पैटर्न ** दर्ज करें। परीक्षण * .dll, TeamCity आपके लिए बाकी काम करेगा, बशर्ते कि आप अपने परीक्षण परियोजनाओं के नाम पर .Tests पैटर्न का उपयोग करें।

एकीकरण और स्वीकृति परीक्षण चलाएं

ये परीक्षण कई कारकों पर निर्भर कर सकते हैं और उनके प्रक्षेपण में रोलिंग बैकअप या आरंभीकरण स्क्रिप्ट शामिल हो सकते हैं। आप ऐसे परीक्षणों के लॉन्च पर अतिरिक्त रिपोर्ट बनाना चाहते हैं। यह बेहतर है कि गणना के साथ अपनी परियोजना को न करें और उनके लिए एक विशेष निर्माण बनाएं। TeamCity आपको बिल्ड की एक श्रृंखला बनाने की अनुमति देता है। स्वीकृति / एकीकरण परीक्षणों के साथ बिल्ड के बिल्ड ट्रिगर्स में, आप एक ट्रिगर जोड़ सकते हैं जो तब काम करता है जब गणना के साथ बिल्ड सफलतापूर्वक पूरा हो जाता है। इस तरह के निर्माण को स्वीकृति परीक्षण चलाने के लिए मैंने विषय में वर्णित किया है: habrahabr.ru/post/182032 ।

बैकअप

गणना के दौरान बैकअप बनाना भी स्वचालित हो सकता है। फ़ाइल सिस्टम बैकअप के लिए, मुझे व्यक्तिगत रूप से nnbackup से बेहतर कुछ नहीं मिला: www.nncron.ru/index_ru.shtml ।

 nnbackup -n 10 verz -i <Src> -o <Destination> -s -e –v 

कमांड ज़िप में स्रोत फ़ोल्डर बनाता है और संग्रह को गंतव्य पर कॉपी करता है। लक्ष्य मशीनों पर nnbackup स्थापित करें या किसी बिल्ड सर्वर से कॉल करें: आपकी प्राथमिकताओं का प्रश्न, सर्वर स्थान, नेटवर्क ओवरहेड और सुरक्षा का निर्माण करें।

आप टी-एसक्यूएल का उपयोग करके एसक्यूएल सर्वर का बैकअप ले सकते हैं

 BACKUP DATABASE AdventureWorks2012 TO DISK='X:\SQLServerBackups\AdventureWorks1.bak', DISK='Y:\SQLServerBackups\AdventureWorks2.bak', DISK='Z:\SQLServerBackups\AdventureWorks3.bak' WITH FORMAT, MEDIANAME = 'AdventureWorksStripedSet0', MEDIADESCRIPTION = 'Striped media set for AdventureWorks2012 database; GO RESTORE DATABASE AdventureWorks FROM DISK='$(Backup)' 

यानी स्वचालित बैकअप के लिए, आपको एक और कमांड लाइन चरण जोड़ना होगा। या आप एक ही समुदाय पैकेज से msbuild कार्यों का उपयोग कर सकते हैं, और nnbackup के लिए अपना msbuild कार्य लिखें।
यदि स्वीकृति परीक्षण विफल हो जाता है तो आप बैकअप से स्वचालित रोलबैक शुरू करने के लिए और आगे बढ़ सकते हैं। फिर आपके पास बिल्ड्स की एक श्रृंखला होगी: लेआउट »स्वीकृति परीक्षण» बैकअप से रोलबैक।

परियोजना प्रबंधन प्रणाली और बग ट्रैकर के साथ एकीकरण

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

कलाकृतियों का निर्माण

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

एक विरूपण साक्ष्य किसी भी फाइल का निर्माण का एक महत्वपूर्ण परिणाम है। इंस्टॉलर के साथ बिल्ड के लिए, आप my-इंस्टॉलर। Exe या my-package.zip निर्दिष्ट कर सकते हैं, बिल्ड कलाकृतियों के लिए एक मुखौटा के रूप में और TeamCity उन्हें संबंधित टैब में प्रदर्शित करेगा।
यह वह जगह है जहाँ समस्या ट्रैकर के साथ एकीकरण उपयोगी है। परीक्षक या प्रबंधक बंद कार्य को देख सकते हैं, बिल्ड के साथ लिंक का पालन कर सकते हैं और बिल्ड कलाकृतियों से सुधार के साथ संस्करण उठा सकते हैं।

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