लाइव वेबसाइट को सुरक्षित रूप से अपडेट करने के लिए

Question

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

1. उपयोगकर्ता एक वेब प्रपत्र
2. साइट के लिए इस प्रपत्र
3. उपयोगकर्ता प्रपत्र वे
4. सर्वर पर काम कर रहा है प्रस्तुत पर नए क्षेत्र की आवश्यकता के लिए अद्यतन किया जाता है खोलता है एक त्रुटि देता है क्योंकि यह चरण 2

में जोड़े गए नए फ़ील्ड को प्राप्त करने की उम्मीद है, अन्य साइटें इस तरह की समस्याओं को कैसे संभालती हैं? मेरे विचार:

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

विचार?

Answer 1

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

एक रखरखाव खिड़की दृष्टिकोण के रूप में सामग्री जमा करने के बारे में "वापस स्केलिंग" के बारे में क्या, उन लोगों को प्रभावित उपयोगकर्ताओं को कम करने के लिए जिन्होंने अपने ब्राउज़र को खोला है?

Answer 2

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

Answer 3

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

Answer 4

ऐसी कई साइटें हैं जिनका उपयोग मैं करता हूं (जो कि मेरे रोजगार के स्थान पर अधिकतर आंतरिक है), जो कुछ इस तरह के सप्ताहांत में शनिवार सुबह 6:00 बजे से शाम 6:00 बजे तक रखरखाव के लिए नीचे आ जाएगा। कृपया उस समय सिस्टम से बाहर निकलने की योजना बनाएं। " हालांकि यह सही नहीं है, कुछ भी नहीं है, और यह एक अच्छा दृष्टिकोण की तरह लगता है। नई चीजें डालने के लिए बस इतना समय निकालें, इसका परीक्षण करें, और यदि आवश्यक हो तो पुराने पर वापस रोल करें। यदि आपको लगता है कि यह आवश्यक है, तो आप हमेशा एक साधारण पृष्ठ स्थापित कर सकते हैं जो कहता है "क्षमा करें, हम अभी उपलब्ध नहीं हैं" और लोगों को डाउन टाइम के दौरान उस पर निर्देशित करें। आम तौर पर कोई भी शिकायत नहीं करेगा अगर आपको मूल रूप से बताए गए समय की आवश्यकता नहीं है और आप जल्दी ही बैक अप ले रहे हैं (हो सकता है कि स्लेकर्स जो काम से बचने का बहाना चाहते हैं, अपवाद होगा, लेकिन वे शायद वैसे भी काम नहीं कर रहे हैं)।

Answer 5

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