स्वचालित रूप से उत्पादन में अपडेट कैसे रोल करें

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

इस लेख में मैं एक विशिष्ट तकनीकी वातावरण के लिए इसके संचालन को बाधित किए बिना स्वत: सिस्टम अपडेट स्थापित करने में व्यावहारिक अनुभव साझा करना चाहता हूं, जैसे: ASP.NET MVC + Azure SQL + Entity फ्रेमवर्क वेब अनुप्रयोग कोड फर्स्ट मोड में, एप्लिकेशन के माध्यम से Azure में एप्लिकेशन को तैनात किया। , और असेंबली और तैनाती Azure DevOps (पूर्व विजुअल स्टूडियो टीम सर्विसेज) के माध्यम से की जाती है।



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

हमारी प्रौद्योगिकी स्टैक के लिए निरंतर तैनाती को लागू करने से रोकने वाले मुख्य कारक निम्नानुसार हैं:

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

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



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

क्या करें?

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

update-database -script 

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

और यह स्क्रिप्ट की पीढ़ी और निष्पादन प्रक्रिया को रिलीज़ गणना प्रक्रिया में बनाने के लिए सही होगा। माइग्रेशन स्क्रिप्ट जेनरेट करने के लिए, आप माइग्रेट ..exe यूटिलिटी का उपयोग कर सकते हैं, जो कि एंटिटी फ्रेमवर्क के साथ शामिल है। मैं इस तथ्य पर आपका ध्यान आकर्षित करता हूं कि आपको Entity Framework संस्करण 6.2 या उच्चतर की आवश्यकता है, क्योंकि स्क्रिप्ट उपयोगिता विकल्प अप्रैल 2017 में ही इस उपयोगिता में दिखाई दिया था। उपयोगिता कॉल इस तरह दिखता है:

 migrate.exe Context.dll /connectionString="Data Source=localhost;Initial Catalog=myDB;User Id=sa;Password=myPassword;" /connectionProviderName="System.Data.SqlClient" /sc /startUpDirectory="c:\projects\MyProject\bin\Release" /verbose 

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

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

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

  public class MigrationScriptBuilder : SqlServerMigrationSqlGenerator { public override IEnumerable<MigrationStatement> Generate(IEnumerable<MigrationOperation> migrationOperations, string providerManifestToken) { var statements = base.Generate(migrationOperations, providerManifestToken); var result = new List<MigrationStatement>(); result.Add(new MigrationStatement { Sql = "SET QUOTED_IDENTIFIER ON;" }); foreach (var item in statements) { item.BatchTerminator = "GO"; result.Add(item); } return result; } } 

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

  public Configuration() { SetSqlGenerator("System.Data.SqlClient", new MigrationScriptBuilder()); …. } 

उसके बाद, परिणामी माइग्रेशन स्क्रिप्ट में प्रत्येक कथन के बीच GO होगा, और फ़ाइल की शुरुआत में SET QUOTED_IDENTIFIER ON होगा;

हुर्रे, तैयारी की जाती है, यह प्रक्रिया को स्वयं कॉन्फ़िगर करने के लिए बनी हुई है। सामान्य तौर पर, Azure DevOps (VSTS / TFS) में रिलीज़ प्रक्रिया के भाग के रूप में, यह पहले से ही काफी सरल है। हमें इस तरह से एक PowerShell स्क्रिप्ट बनाने की आवश्यकता है:

 param ( [string] [Parameter(Mandatory=$true)] $dbserver, [string] [Parameter(Mandatory=$true)] $dbname, [string] [Parameter(Mandatory=$true)] $dbserverlogin, [string] [Parameter(Mandatory=$true)] $dbserverpassword, [string] [Parameter(Mandatory=$true)] $rootPath, [string] [Parameter(Mandatory=$true)] $buildAliasName, [string] [Parameter(Mandatory=$true)] $contextFilesLocation, ) Write-Host "Generating migration script..." $fullpath="$rootPath\$buildAliasName\$contextFilesLocation" Write-Host $fullpath & "$fullpath\migrate.exe" Context.dll /connectionProviderName="System.Data.SqlClient" /connectionString="Server=tcp:$dbserver.database.windows.net,1433;Initial Catalog=$dbname;Persist Security Info=False;User ID=$dbserverlogin;Password=$dbserverpassword;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;" /startUpDirectory=$fullpath /verbose /scriptFile=1.SQL Write-Host "Running migration script..." & "SQLCMD" -S "$dbserver.database.windows.net" -U $dbserverlogin@$dbserver -P $dbserverpassword -d $dbname -i 1.SQL Write-Host "====Finished with migration script====" 

और PowerShell स्क्रिप्ट निष्पादन इकाई को रिलीज़ गणना प्रक्रिया में जोड़ें। ब्लॉक और इसकी सेटिंग्स इस तरह दिख सकती हैं:



PowerShell सेटअप कुछ इस तरह दिखता है:



यह महत्वपूर्ण है कि <YourProject> /packages/EntityFramework.6.2.0/tools/ फ़ोल्डर से प्रोजेक्ट में माइग्रेट। Exe फ़ाइल को जोड़ना न भूलें और कॉपी ऑलवेज प्रॉपर्टी को इसमें सेट करें ताकि यह उपयोगिता आउटपुट डायरेक्टरी में कॉपी हो जाए जब प्रोजेक्ट बनाया जाए और आप इसे एक्सेस कर सकें। Azure DevOps रिलीज़।

बारीकियाँ । यदि आपका प्रोजेक्ट भी Azure App Service परिनियोजित करते समय WebJob का उपयोग करता है, तो आपके प्रोजेक्ट में Migrate.exe जोड़ना सुरक्षित नहीं है। हम इस तथ्य से सामना कर रहे हैं कि आपके वेबजॉब को प्रकाशित किए जाने वाले फ़ोल्डर में, एज़्योर प्लेटफ़ॉर्म बेवकूफी से शुरू होता है जो पहले एक्सई फ़ाइल में आता है। और अगर आपके WebJob ने वर्णानुक्रम में बाद में migrate.exe खर्च किया है (और हमने किया), तो यह आपकी परियोजना के बजाय migrate.exe को चलाने की कोशिश करता है!

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

  <entityFramework> <contexts> <context type="<full namespace for your DataContext class>, MyAssembly" disableDatabaseInitialization="true"/> </contexts> </entityFramework> 

जहाँ full namespace for your DataContext class के लिए पूर्ण नामस्थान DbContext से आपके वंशज का पूरा नाम स्थान है, और MyAssembly विधानसभा का नाम है जहाँ आपका संदर्भ निहित है।

और अंत में, यह सुनिश्चित करना हमारे लिए बहुत ही वांछनीय है कि एप्लिकेशन नए संस्करण में उपयोगकर्ताओं को बदलने से पहले वार्मिंग कर रहा है। ऐसा करने के लिए, लिंक के साथ web.config के लिए एक विशेष ब्लॉक जोड़ें जो कि आपका एप्लिकेशन प्रारंभ प्रक्रिया के दौरान स्वचालित रूप से क्विट करता है:

  <system.webServer> <applicationInitialization doAppInitAfterRestart="true"> <add initializationPage="/" hostName="" /> </applicationInitialization> </system.webServer> 

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

लेकिन .NET कोर पर एक परियोजना के बारे में क्या?

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

खैर, विशेष रूप से, प्रक्रिया के चरण इस तरह दिखते हैं। निर्माण प्रक्रिया में, कार्य जोड़ें:



हम एक फाइल को माइग्रेशन के साथ उत्पन्न करने के लिए इसे कॉन्फ़िगर करते हैं:



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



यह केवल इस तरह से ऊपर वर्णित के रूप में इस PowerShell स्क्रिप्ट के निष्पादन को कॉन्फ़िगर करने के लिए उपयुक्त रिलीज़ चरण में रहता है।

लेखक के बारे में

पावेल कुताकोव क्लाउड प्रौद्योगिकियों पर एक विशेषज्ञ, विभिन्न व्यावसायिक क्षेत्रों में सॉफ्टवेयर सिस्टम के एक डेवलपर और वास्तुकार - संयुक्त राज्य अमेरिका से पापुआ न्यू गिनी के लिए दुनिया भर में बैंकिंग आईपी ऑपरेटिंग से लेकर राष्ट्रीय लॉटरी ऑपरेटर के लिए क्लाउड समाधान तक है।