मुझे लगता है कि इस समस्या के दो भाग हैं।
पहले डेटाबेस स्कीमा और उसके परिवर्तनों का प्रबंधन कर रहा है। हम अपने SCM रिपॉजिटरी में वर्किंग मॉडल और माइग्रेशन फाइल दोनों को रखते हुए साउथ का उपयोग करते हुए ऐसा करते हैं। सुरक्षा (या व्यामोह) के लिए, हम किसी भी माइग्रेशन को चलाने से पहले (और अगर हम वास्तव में डरे हुए हैं, तो) डेटाबेस का डंप लेते हैं। दक्षिण हमारी अब तक की सभी आवश्यकताओं के लिए पर्याप्त रहा है।
दूसरा स्कीमा परिवर्तन को लागू कर रहा है जो दक्षिण द्वारा उत्पन्न माइग्रेशन फ़ाइल को चलाने से परे है। मेरे अनुभव में, डेटाबेस में बदलाव के लिए आम तौर पर तैनात कोड में बदलाव की आवश्यकता होती है। यदि आपके पास एक छोटा वेब फ़ार्म भी है, तो परिनियोजित कोड को आपके डेटाबेस स्कीमा के वर्तमान संस्करण के साथ सिंक में रखना मामूली नहीं हो सकता है - यदि आप पहले से सक्रिय साइट उपयोगकर्ता के लिए विभिन्न कैशिंग परतों और प्रभाव पर विचार करते हैं तो यह और भी खराब हो जाता है। अलग-अलग साइटें इस समस्या को अलग-अलग तरीके से संभालती हैं, और मुझे नहीं लगता कि एक आकार-फिट-सभी उत्तर है।
इस समस्या के दूसरे भाग को हल करना जरूरी नहीं कि सीधे आगे हो। मुझे विश्वास नहीं है कि एक आकार-फिट-सभी दृष्टिकोण है, और आपकी स्थिति के लिए सबसे उपयुक्त समाधान सुझाने के लिए आपकी वेबसाइट और पर्यावरण के बारे में पर्याप्त जानकारी नहीं है। हालांकि, मुझे लगता है कि कुछ बातों को ध्यान में रखा जा सकता है ताकि अधिकांश स्थितियों में परिनियोजन को निर्देशित किया जा सके।
पूरी साइट (वेब सर्वर और डेटाबेस) को ऑफलाइन लेना कुछ मामलों में एक विकल्प है। यह निश्चित रूप से अपडेट को प्रबंधित करने का सबसे सीधा तरीका है। लेकिन बार-बार डाउनटाइम (योजनाबद्ध होने पर भी) हमारे व्यवसाय को जल्दी से आगे बढ़ाने का एक अच्छा तरीका हो सकता है, छोटे कोड परिवर्तनों को भी लागू करना थकाऊ बनाता है, और यदि आपके पास एक बड़ा डेटासेट और/या जटिल माइग्रेशन है तो इसमें कई घंटे लग सकते हैं। उस ने कहा, उन साइटों के लिए जिन्हें मैं प्रबंधित करने में मदद करता हूं (जो सभी आंतरिक हैं और आमतौर पर केवल व्यावसायिक दिनों में काम के घंटों के दौरान उपयोग की जाती हैं) यह दृष्टिकोण अद्भुत काम करता है।
यदि आप अपने मास्टर डेटाबेस की एक प्रति में परिवर्तन करते हैं तो सावधान रहें। यहां मुख्य समस्या यह है कि आपकी साइट अभी भी लाइव है, और संभावित रूप से डेटाबेस को लिखने को स्वीकार कर रही है। जब आप क्लोन को बाद में उपयोग के लिए माइग्रेट करने में व्यस्त होते हैं तो मास्टर डेटाबेस में लिखे गए डेटा का क्या होता है? आपकी साइट को या तो पूरे समय बंद रहना होगा या अस्थायी रूप से केवल पढ़ने के लिए कुछ अवस्था में रखना होगा अन्यथा आप उन्हें खो देंगे।
यदि आपके परिवर्तन पीछे की ओर संगत हैं, और आपके पास एक वेब फ़ार्म है, तो कभी-कभी आप लाइव प्रोडक्शन डेटाबेस सर्वर (जो मुझे लगता है कि ज्यादातर स्थितियों में अपरिहार्य है) को अपडेट करने से दूर हो सकते हैं और फिर उन्हें बाहर निकालकर फ़ार्म में नोड्स को अपडेट कर सकते हैं। एक छोटी अवधि के लिए लोड बैलेंसर। यह ठीक काम कर सकता है - हालांकि यहां मुख्य समस्या यह है कि यदि एक नोड जो पहले से अपडेट किया गया है एक यूआरएल के लिए अनुरोध भेजता है जो पुराने नोड द्वारा समर्थित नहीं है तो आप असफल हो जाएंगे क्योंकि आप लोड बैलेंसर स्तर पर इसे प्रबंधित नहीं कर सकते हैं।
मैंने कुछ अन्य तरीकों को अच्छी तरह से काम करते देखा/सुना है।
पहला फीचर लॉक में सभी कोड परिवर्तनों को लपेट रहा है जो कि कुछ साइट-व्यापी कॉन्फ़िगरेशन विकल्पों के माध्यम से रन-टाइम पर कॉन्फ़िगर करने योग्य है। इसका अनिवार्य रूप से मतलब है कि आप कोड जारी कर सकते हैं जहां आपके सभी परिवर्तन बंद हैं, और फिर अपने सर्वर में सभी आवश्यक अपडेट करने के बाद आप सुविधा को सक्षम करने के लिए अपना कॉन्फ़िगरेशन विकल्प बदल सकते हैं। लेकिन यह काफी भारी कोड बनाता है...
दूसरा कोड को माइग्रेशन को प्रबंधित करने दे रहा है। मैंने उन साइटों के बारे में सुना है जहां कोड में परिवर्तन इस तरह से लिखा जाता है कि यह रनटाइम पर माइग्रेशन को संभालता है। यह उपयोग किए जा रहे स्कीमा के संस्करण का पता लगाने में सक्षम है, और डेटा का प्रारूप जो इसे वापस मिला है - यदि डेटा पुराने स्कीमा से है तो यह जगह में माइग्रेशन करता है, यदि डेटा पहले से ही नई स्कीमा से है तो यह कुछ भी नहीं करता है . प्राकृतिक साइट उपयोग से आपके डेटा का एक बड़ा हिस्सा साइट का उपयोग करने वाले लोगों द्वारा माइग्रेट किया जाएगा, बाकी आप जब चाहें माइग्रेशन स्क्रिप्ट के साथ कर सकते हैं।
लेकिन मुझे लगता है कि इस बिंदु पर Google आपका मित्र बन जाता है, क्योंकि जैसा कि मैं कहता हूं, समाधान बहुत विशिष्ट संदर्भ है और मुझे चिंता है कि यह उत्तर अर्थहीन होने लगेगा... "शून्य डाउन टाइम परिनियोजन" जैसी किसी चीज़ की खोज करें और आप ' जैसे परिणाम मिलेंगे यह ढेर सारे विचारों के साथ...
