शून्य डाउनटाइम के साथ ASP.NET एप्लिकेशन को कैसे तैनात करें

Question

हमारी वेबसाइट के एक नए संस्करण को तैनात करने के लिए हम निम्नलिखित कार्य करते हैं:

1. नया कोड ज़िप करें, और इसे सर्वर पर अपलोड करें।
2. लाइव सर्वर पर, IIS वेबसाइट निर्देशिका से सभी लाइव कोड हटाएं।
3. अब खाली IIS निर्देशिका में नया कोड ज़िपिपाइल निकालें

यह प्रक्रिया सभी स्क्रिप्टेड है, और काफी जल्दी होती है, लेकिन पुरानी फ़ाइलों को हटाए जाने और नई फ़ाइलों को तैनात किए जाने के बाद भी 10-20 सेकंड डाउनटाइम हो सकता है।

0 सेकंड डाउनटाइम विधि पर कोई सुझाव?

Comments

क्या यह सर्वरफॉल्ट पर नहीं होना चाहिए?

— डैनियल रॉड्रिग्ज

शायद, लेकिन ServerFault सितंबर में मौजूद नहीं था '08

— कार्ल ग्लेनॉन

क्या IIS एक सिम्लिंक फ़ोल्डर की ओर इशारा कर सकता है? क्या सिमलिंक को बदलने से IIS रीसायकल प्रक्रिया फिर से शुरू होगी?

— नील मैकगिन

पूर्ण स्रोत कोड स्क्रिप्ट नमूने के साथ कोई अंतिम समाधान?

— किकेनेट

क्या एक से अधिक ऐप पूल होना और ट्रैफ़िक को एक ऐप पूल से दूसरे में बदलना संभव नहीं है?

— ल्यूक

Answer 1

आपको 2 सर्वर और एक लोड बैलेंसर की आवश्यकता है। यहाँ चरणों में है:

1. सर्वर 2 पर सभी ट्रैफ़िक चालू करें
2. सर्वर पर तैनात 1
3. टेस्ट सर्वर 1
4. सर्वर 1 पर सभी ट्रैफ़िक चालू करें
5. सर्वर पर तैनात 2
6. टेस्ट सर्वर 2
7. दोनों सर्वरों पर ट्रैफ़िक चालू करें

बात यह है, यहां तक ​​कि अगर आप "चिपचिपा सत्र" का उपयोग कर रहे हैं, तब भी आपके पास सत्र पुनरारंभ और सत्रों का नुकसान होगा। यदि आपके पास डेटाबेस सत्र या एक राज्य सर्वर है, तो सब कुछ ठीक होना चाहिए।

Comments

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

यह विधि तब गिर जाती है जब कोड रोल में डेटाबेस में संरचनात्मक परिवर्तन होते हैं। एक बार जब आप सर्वर 1 के लिए DB को अपग्रेड करते हैं, तो सर्वर 2 फट जाएगा। अब आप सर्वर 1 पर परीक्षण के लिए डेटाबेस का बैकअप / पुनर्स्थापना कर सकते हैं, लेकिन फिर आपके पास समानांतर डीबी चलने के दौरान लाइव डीबी में परिवर्तित हुए डेटा को छाँटने का मुद्दा है।

— 22

@AndreiRinea - क्या आप मानते हैं कि यह एक उच्च वॉल्यूम OLTP सिस्टम में काम करेगा? या तो सिस्टम सिंक से बाहर चला जाता है और जब आप काटते हैं तो आप डेटा को ढीला कर देते हैं, या आपको डेटा प्रविष्टि को रोकना पड़ता है और नए DB संरचना में ट्रांज़िट डेटा की पहचान और माइग्रेट करने के लिए एक स्क्रिप्ट लिखना होता है।

— 21

@EBarr: और किसी भी मामले में तकनीकी रूप से आपके पास अभी भी ASP.NET ऐप पर शून्य डाउनटाइम है - सवाल यह नहीं है कि "शून्य डाउनटाइम के साथ एसक्यूएल सर्वर डीबी पर कैसे तैनात किया जाए"।

— स्किलिविज़

वे कुंजी इस तरह से विकसित करने के लिए है कि आपके sql परिवर्तन विनाशकारी नहीं हैं। एक बार उपयोग नहीं होने के बाद, आपको अक्सर निम्न रिलीज में कोई विनाशकारी sql परिवर्तन करना होगा। अभ्यास के साथ ऐसा करना कठिन नहीं है।

— बीलर

Answer 2

माइक्रोसॉफ्ट वेब तैनाती उपकरण कुछ हद तक इस का समर्थन करता है:

Windows Transactional फ़ाइल सिस्टम (TxF) समर्थन को सक्षम करता है। जब टीएक्सएफ समर्थन सक्षम होता है, तो फ़ाइल संचालन परमाणु होते हैं; यही है, वे या तो सफल होते हैं या पूरी तरह से विफल होते हैं। यह डेटा अखंडता सुनिश्चित करता है और डेटा या फ़ाइलों को "आधे रास्ते" या दूषित स्थिति में मौजूदा से रोकता है। MS Deploy में, TxF डिफ़ॉल्ट रूप से अक्षम होता है।

ऐसा लगता है कि लेन-देन पूरे सिंक के लिए है। साथ ही, TxF विंडोज सर्वर 2008 की एक विशेषता है, इसलिए यह लेनदेन सुविधा पूर्व संस्करणों के साथ काम नहीं करेगी।

मेरा मानना ​​है कि संस्करणों और IIS मेटाबेस के रूप में फ़ोल्डर्स का उपयोग करके अपनी स्क्रिप्ट को 0-डाउनटाइम के लिए संशोधित करना संभव है:

• मौजूदा पथ / url के लिए:
  • पथ : \ web \ app \ v2.0 \
  • url : http: // app
• के तहत सर्वर पर नई (या संशोधित) वेबसाइट की प्रतिलिपि बनाएँ
  • \ वेब \ एप्लिकेशन \ v2.1 \
• वेबसाइट पथ को बदलने के लिए IIS मेटाबेस को संशोधित करें
  • से \ वेब \ एप्लिकेशन \ 2.0 \
  • to \ web \ app \ v2.1 \

यह विधि निम्नलिखित लाभ प्रदान करती है:

• घटना में नए संस्करण में एक समस्या है, आप आसानी से v2.0 पर रोलबैक कर सकते हैं
• कई भौतिक या आभासी सर्वर पर तैनात करने के लिए, आप फ़ाइल परिनियोजन के लिए अपनी स्क्रिप्ट का उपयोग कर सकते हैं। सभी सर्वरों का नया संस्करण होने के बाद, आप Microsoft वेब परिनियोजन उपकरण का उपयोग करके सभी सर्वरों के डेटाबेस को एक साथ बदल सकते हैं।

Comments

मैंने हमारी पॉवरशेल परिनियोजन स्क्रिप्ट्स को अपना कर इस दृष्टिकोण को लागू किया है। आप स्क्रिप्ट का हिस्सा देख सकते हैं जो IIS साइट फ़ोल्डर को यहां बदलता है: stackoverflow.com/questions/330608/… सूचक के लिए धन्यवाद।

— कार्ल ग्लेनन

दुर्भाग्य से, यह विधि DB के संरचनात्मक परिवर्तनों के लिए जिम्मेदार नहीं है। एक बार जब आप v2.1 के लिए DB को अपग्रेड करते हैं तो v.2.0 विस्फोट हो जाता है।

— 22

TxF का उपयोग करना यहाँ ओवरमिल है, IMO। यह एक ही समय में फाइल सिस्टम में v2.0 और v2.1 दोनों के लिए कुछ भी चोट नहीं करता है। बड़ा बदलाव तब होता है जब v2.1 ऑनलाइन हो जाता है, और उस समय तक, TxF लेनदेन प्रतिबद्ध हो गया है। शून्य डाउनटाइम वास्तव में होता है क्योंकि जिस तरह से IIS एक पुराने AppPool से एक नए में जाता है, TxF के कारण नहीं।

— रिकएन

इसके साथ एक अन्य समस्या यह है कि यदि ऐप फ़ोल्डर के सबफ़ोल्डर में बड़ी मात्रा में उपयोगकर्ता डेटा संग्रहीत है।

— केनी एविट

यह 0 दूसरा परिनियोजन नहीं है क्योंकि नए ऐप को शुरू करने की आवश्यकता है।

— usr

Answer 3

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

एक पूर्ण ट्यूटोरियल यहां पाया जा सकता है।

Answer 4

मैं हाल ही में इस माध्यम से गया था और मैं जिस समाधान के साथ आया था वह दो साइटों को IIS में स्थापित करने और उनके बीच स्विच करने के लिए था।

मेरे कॉन्फ़िगरेशन के लिए, मेरे पास प्रत्येक A और B साइट के लिए इस तरह की एक वेब निर्देशिका थी: c: \ Intranet \ Live A \ Interface c: \ Intranet \ Live B \ Interface

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

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

Comments

यह फाइल कॉपी के कारण डाउनटाइम के साथ मदद करता है, लेकिन @Sklivvz के रूप में एक ही मुद्दा है - जैसे ही कोड रोल में डेटाबेस में संरचनात्मक परिवर्तन होता है, साइट बूम हो जाती है।

— 22

यह मेरे लिए सहज तरीका जैसा लग रहा था, लेकिन ऐसा करने का एक आसान, अंतर्निहित तरीका क्यों नहीं है?

— पेट्रस थेरॉन

@ एबर्र फिर विनाशकारी एसक्यूएल परिवर्तनों को रोल आउट नहीं करता है। उदाहरण के लिए, यदि आपको एक कॉलम को निकालने की आवश्यकता है, तो अगली रिलीज में ऐसा करें जब इसका उपयोग ए या बी द्वारा नहीं किया जाता है

— बीलर

@ बीलर - सहमत (कैविएट के साथ)। इन सवालों की एक पूरी श्रृंखला "कोड भूमिकाओं के दौरान डाउनटाइम" पर है। मुझे अभी तक एक ऐसा नहीं मिला है जो वास्तव में एक डीबी स्कीमा को विकसित करने की वास्तविकताओं पर चर्चा करता है। कैविएट - स्कीमा में दो-चरण परिवर्तनों के साथ आने वाली विभिन्न जटिलताएं हैं। एक उदाहरण - ORMs बारफ के कई अगर तालिका परिभाषा परिभाषा से अलग है क्योंकि यह इसे (नए या लापता कॉलम) समझती है।

— उबर

@ रो आप साइट को "प्री-वार्म" कैसे कर सकते हैं यदि इसे रोका जाए?

— एंड्रयू जी

Answer 5

Microsoft.Web.Administration के ServerManager वर्ग का उपयोग करके आप अपना स्वयं का परिनियोजन एजेंट विकसित कर सकते हैं।

ट्रिक को VirtualDirectory के PhysicalPath को बदलना है, जिसके परिणामस्वरूप पुराने और नए वेब ऐप्स के बीच एक ऑनलाइन परमाणु स्विच होता है।

ज्ञात हो कि यह समानांतर में निष्पादित पुराने और नए AppDomains में परिणाम कर सकते हैं!

समस्या यह है कि डेटाबेस आदि में परिवर्तन को कैसे सिंक्रनाइज़ किया जाए।

पुराने या नए PhysicalPaths के साथ AppDomains के अस्तित्व के लिए मतदान करके यह पता लगाना संभव है कि पुराने AppDomain (s) ने कब समाप्त किया है, और यदि नया AppDomain (s) शुरू हो गया है।

एक AppDomain को शुरू करने के लिए मजबूर करने के लिए आपको एक HTTP अनुरोध (IIS 7.5 ऑटोस्टार्ट सुविधा का समर्थन करता है) करना चाहिए

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

(मैं म्यूटेक्स प्रतीक्षा व्यवहार को सक्षम करने के लिए वेब ऐप में एक मार्कर फ़ाइल का उपयोग करता हूं) एक बार जब नया वेब ऐप चल रहा होता है तो मैं मार्कर फ़ाइल को हटा देता हूं।

Answer 6

ठीक है, क्योंकि हर कोई उत्तर लिख रहा है जो मैंने 2008 में वापस लिख दिया था ... *

मैं आपको बताऊंगा कि हम इसे 2014 में कैसे करते हैं। अब हम वेब साइट्स का उपयोग नहीं करते हैं क्योंकि हम ASP.NET MVC का उपयोग कर रहे हैं।

हमें निश्चित रूप से इसे करने के लिए एक लोड बैलेंसर और दो सर्वरों की आवश्यकता नहीं है, यह ठीक है यदि आपके पास बनाए रखने वाली प्रत्येक वेबसाइट के लिए 3 सर्वर हैं लेकिन यह अधिकांश वेबसाइटों के लिए कुल ओवरकिल है।

इसके अलावा, हम Microsoft से नवीनतम विज़ार्ड पर भरोसा नहीं करते हैं - बहुत धीमा, और बहुत अधिक छिपा हुआ जादू, और इसका नाम बदलने के लिए प्रवण।

यहाँ हम यह कैसे करते हैं:

1. हमारे पास एक पोस्ट बिल्ड कदम है जो प्रतियां DLL को 'बिन-पब' फ़ोल्डर में उत्पन्न करता है।

2. हम उत्पादन सर्वर पर परिवर्तित फ़ाइलों को सत्यापित करने और एफ़टीपी (क्योंकि यह व्यापक रूप से समर्थित है) से परे (तुलना में उत्कृष्ट है) से परे का उपयोग करें

3. हमारे पास वेबसाइट पर एक सुरक्षित यूआरएल है जिसमें एक बटन है जो 'बिन-पब' में 'बिन' के लिए सब कुछ कॉपी करता है (त्वरित रोलबैक सक्षम करने के लिए पहले बैकअप लेता है)। इस बिंदु पर ऐप खुद को पुनरारंभ करता है। तब हमारा ओआरएम जांचता है कि क्या कोई टेबल या कॉलम हैं जिन्हें जोड़ने और उन्हें बनाने की आवश्यकता है।

यह केवल मिलीसेकंड डाउनटाइम है। ऐप रिस्टार्ट में एक या दो बार लग सकता है लेकिन रिस्टार्ट रिक्वेस्ट के दौरान बफरिंग हो जाती है इसलिए प्रभावी रूप से जीरो डाउनटाइम होता है।

पूरी तैनाती प्रक्रिया 5 सेकंड से 30 मिनट तक कहीं भी हो जाती है, यह निर्भर करता है कि कितनी फाइलें बदली गई हैं और समीक्षा के लिए कितने बदलाव हैं।

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

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

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

Comments

लेकिन, आपको अभी भी डाउनटाइम मिलेगा क्योंकि ऐप पूल रीसायकल करता है।

— Testpattern

नहीं, कोई डाउनटाइम नहीं क्योंकि एप्लिकेशन पुनः आरंभ होने के दौरान IIS द्वारा स्वचालित रूप से बफ़र किए जाते हैं

— माइक नेल्सन

Answer 7

केवल शून्य डाउनटाइम विधियां मैं कम से कम 2 सर्वरों पर होस्टिंग को शामिल करने के बारे में सोच सकता हूं।

Answer 8

मैं जॉर्ज के उत्तर को थोड़ा परिष्कृत करूंगा, इस प्रकार, एकल सर्वर के लिए:

1. किसी एकल DLL में साइट को पूर्व-संकलित करने के लिए वेब परिनियोजन प्रोजेक्ट का उपयोग करें
2. नई साइट को ज़िप करें, और इसे सर्वर पर अपलोड करें
3. साइट के लिए सही अनुमतियों के साथ एक फ़ोल्डर में स्थित एक नए फ़ोल्डर में इसे अनज़िप करें, इसलिए अनज़ैप्ड फ़ाइलें सही तरीके से अनुमतियों को विरासत में देती हैं (शायद e: \ web, सबफ़ोल्डर्स v20090901, v20090916, आदि के साथ)
4. साइट वाले फ़ोल्डर का नाम बदलने के लिए IIS प्रबंधक का उपयोग करें
5. पुराने फोल्डर को थोड़ी देर के लिए इधर-उधर रखें, ताकि आप समस्याओं की स्थिति में उस पर वापस आ सकें

चरण 4 में IIS कार्यकर्ता प्रक्रिया को रीसायकल करने का कारण होगा।

यदि आप InProc सत्र का उपयोग नहीं कर रहे हैं तो यह केवल शून्य डाउनटाइम है; यदि आप कर सकते हैं तो SQL मोड का उपयोग करें (और भी बेहतर, सत्र की स्थिति से पूरी तरह से बचें)।

जब कई सर्वर और / या डेटाबेस परिवर्तन होते हैं, तो निश्चित रूप से यह थोड़ा अधिक शामिल होता है ...।

Comments

@Sklivvz के रूप में भी एक ही मुद्दा - जैसे ही कोड रोल में डेटाबेस में संरचनात्मक परिवर्तन होते हैं, यह विधि नीचे गिर जाती है।

— 22

इसलिए मैंने कहा कि जब डीबी में बदलाव होते हैं तो यह अधिक शामिल था ... डीबी के लिए संरचनात्मक परिवर्तनों के साथ कोड को रोल आउट करना केवल एक तैनाती मुद्दा नहीं है; वहाँ भी कोड में समर्थन किया जाना है, और शायद DB में भी।

— रिकनज

Answer 9

Sklivvz के उत्तर पर विस्तार करने के लिए, जो किसी प्रकार के लोड बैलेंसर पर निर्भर था (या उसी सर्वर पर एक स्टैंडबाय कॉपी)

1. साइट / सर्वर 2 पर सभी ट्रैफ़िक को निर्देशित करें
2. वैकल्पिक रूप से थोड़ा इंतजार करें, यह सुनिश्चित करने के लिए कि संभव के रूप में कुछ उपयोगकर्ताओं के पास तैनात संस्करण पर वर्कफ़्लो लंबित हैं
3. साइट / सर्वर 1 पर तैनात करें और इसे जितना संभव हो उतना गर्म करें
4. डेटाबेस का माइग्रेशन ट्रांसेक्शनल रूप से करें (इसे संभव बनाने का प्रयास करें)
5. साइट / सर्वर 1 पर सभी ट्रैफ़िक को तुरंत निर्देशित करें
6. साइट / सर्वर 2 पर नियोजित करें
7. दोनों साइटों / सर्वरों के लिए सीधे यातायात

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

यदि संभव हो और जरूरत हो तो "राउटिंग डिफरेंस", जैसे कि अलग टेनेंट URL: s (customerX.myapp.net) या अलग-अलग उपयोगकर्ता, पहले गिनी सूअरों के एक अनजाने समूह को तैनात करने के लिए। यदि कुछ भी विफल नहीं होता है, तो सभी को जारी करें।

चूंकि डेटाबेस माइग्रेशन शामिल हैं, पिछले संस्करण में वापस रोल करना अक्सर असंभव होता है।

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

Answer 10

यह मेरा इसे करने का तरीका है:

पूर्ण न्यूनतम सिस्टम आवश्यकताएँ:
1 सर्वर के साथ

• पोर्ट 80 पर चलने वाला 1 लोड बैलेंसर / रिवर्स प्रॉक्सी (जैसे नेग्नेक्स)
• 2 ASP.NET-Core / मोनो रिवर्स-प्रॉक्सी / Fastcgi chroot-jails या docker- कंटेनर 2 अलग-अलग टीसीपी पोर्ट पर सुन रहे हैं
  (या बिना किसी सैंडबॉक्स के 2 अलग-अलग टीसीपी पोर्ट पर सिर्फ दो रिवर्स-प्रॉक्सी एप्लिकेशन भी)

कार्यप्रवाह:

myupdate लेनदेन शुरू करें

try
    Web-Service: Tell all applications on all web-servers to go into primary read-only mode 
    Application switch to primary read-only mode, and responds 
    Web sockets begin notifying all clients 
    Wait for all applications to respond

    wait (custom short interval)

    Web-Service: Tell all applications on all web-servers to go into secondary read-only mode 
    Application switch to secondary read-only mode (data-entry fuse)
    Updatedb - secondary read-only mode (switches database to read-only)

    Web-Service: Create backup of database 
    Web-Service: Restore backup to new database
    Web-Service: Update new database with new schema 

    Deploy new application to apt-repository 
    (for windows, you will have to write your own custom deployment web-service)
    ssh into every machine in array_of_new_webapps
    run apt-get update
    then either 
    apt-get dist-upgrade
    OR
    apt-get install <packagename>
    OR 
    apt-get install --only-upgrade <packagename>
    depending on what you need
    -- This deploys the new application to all new chroots (or servers/VMs)

    Test: Test new application under test.domain.xxx
    -- everything that fails should throw an exception here
    commit myupdate;

    Web-Service: Tell all applications to send web-socket request to reload the pages to all clients at time x (+/- random number)
    @client: notify of reload and that this causes loss of unsafed data, with option to abort 

    @ time x:  Switch load balancer from array_of_old_webapps to array_of_new_webapps 
    Decomission/Recycle array_of_old_webapps, etc.

catch
        rollback myupdate 
        switch to read-write mode
        Web-Service: Tell all applications to send web-socket request to unblock read-only mode
end try 

Answer 11

मैं सुझाव दूंगा कि पुरानी फाइलों को वहीं रखें और उन्हें अधिलेखित कर दें। इस तरह से डाउनटाइम सिंगल-फाइल ओवरराइट समय तक सीमित है और एक समय में केवल एक फाइल गायब है।

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

Comments

हाय माइक, आप इस उत्तर को हटाना चाह सकते हैं।

— सोहेल अहमद