कॉपी शायद ही WordPress के स्थानांतरण को तोड़े। उसे वह तोड़ता है जो किसी ने नहीं लिखा: एक cron, एक webhook, एक प्लगइन जिसने पुराना hostname एक पंक्ति में पका दिया, एक मेलबॉक्स जो अब भी पुराने सर्वर से जाता है। मैं इन्वेंटरी को ही माइग्रेशन मानता हूँ। फ़ाइल स्थानांतरण उसके बाद की आसान दोपहर है।
छूने से पहले सिस्टम लिख दें
फ़ाइल हिलने से पहले मैं एक पृष्ठ लिखता हूँ जिसे कोई अजनबी इस्तेमाल कर सके। PHP संस्करण। डेटाबेस का आकार। cron पंक्तियाँ और WordPress के अंदर निर्धारित क्रियाएँ, जो एक सूची नहीं। मेल: कौन भेजता है, किस रास्ते, और क्या SPF उस होस्ट का नाम पहले से लेता है। हर जोड़ जो साइट को बुलाए या जिसे साइट बुलाए। भुगतान webhook और CRM समन्वय आम चौंकाने वाली बातें हैं, क्योंकि वे प्लगइन सेटिंग में रहती हैं जिसे किसी ने निर्यात नहीं किया।
मैं यह भी लिखता हूँ कि इस दुकान के लिए “चलना” का मतलब क्या है। एक भौतिक उत्पाद का चेकआउट। एक वर्चुअल उत्पाद का चेकआउट। लॉगिन। पासवर्ड रीसेट। संपर्क फ़ॉर्म, उस ईमेल समेत जो आना चाहिए। खोज, अगर कैटलॉग उस पर टिका है। अगर मैं रास्ता नाम नहीं दे सकता, मैं DNS बदलने को तैयार नहीं।
| पंक्ति | यह यहाँ क्यों है |
|---|---|
| PHP, डेटाबेस आकार, ऑब्जेक्ट कैश | नया होस्ट «ऊपर» होकर भी गलत रनटाइम हो सकता है। |
| Cron और शेड्यूल्ड ऐक्शन | छूटा रात का जॉब तब तक ठीक लगता है जब तक सुबह की रिपोर्ट खाली न हो। |
| मेल का रास्ता | साइट खुल सकती है जबकि हर ऑर्डर मेल नई मशीन पर मर जाता है। |
| Webhook और बाहर जाने वाले API | आमतौर पर वे लिखे नहीं होते, और होस्टनाम पहले वही नोटिस करते हैं। |
| पाँच रास्ते जो पैसा कमाते हैं | होम की जाँच उन पर नहीं चलती। |
एक दिन पहले TTL घटाएँ
स्विच से एक दिन पहले DNS TTL 300 सेकंड कर दें। अगर आप इसे छोड़ दें और नया होस्ट गलत हो, तो दर्शकों का एक हिस्सा घंटों पुराना रिकॉर्ड रखता है। जिस कैश को आपने छोटा नहीं किया, उसे जल्दी नहीं कर सकते। आउटेज के दौरान इंतज़ार पता चले, इससे बेहतर है जानबूझकर एक दिन रुकना।
स्टेजिंग URL असली होस्टनाम नहीं
मैं नया सर्वर उठाता हूँ और सार्वजनिक DNS अभी भी पुराने होस्ट को दे रहा हो तब hosts फ़ाइल में अपवाद से केवल अपनी मशीन को उसकी ओर करता हूँ। फिर असली नाम पर रास्ते चलता हूँ। staging का URL उन प्लगइन को छिपाता है जिन्होंने प्रोडक्शन डोमेन डेटाबेस में रखा। वे तब तक सीधे रहते हैं जब तक असली नाम अनुरोध में न हो, और वही क्षण है जब आप चौंकना नहीं चाहते।
अगर निर्णायक रास्ता असली होस्टनाम पर नहीं चला, तो माइग्रेशन जाँचा नहीं गया।
पुराने होस्ट को गर्म रखें
स्थानांतरण वाले हफ्ते मैं पुरानी होस्टिंग रद्द नहीं करता। वह कम से कम दो हफ्ते चालू रहती है, केवल पढ़ने के लिए। खर्च कम है। यही एकमात्र वापसी है जो उस बैकअप पर नहीं टिकी जिसे मुझे अभी इस्तेमाल नहीं करना पड़ा। अगर नया होस्ट तीसरे दिन बिगड़े, पुराना रिकॉर्ड तब भी कुछ मायने रखता है।
मेल वह जाँच है जिसे लोग भूल जाते हैं
साइट पूरी लग सकती है जबकि हर ऑर्डर मेल नई मशीन पर मर रहा हो। मैं From पता, relay, और पोर्ट 25 खुला भी है या नहीं, लिखता हूँ। एक से अधिक होस्ट पर वह खुला नहीं, और एकमात्र चलता रास्ता 587 पर प्रमाणित relay है। SPF का पहले से एक रिकॉर्ड है। दूसरा नहीं जोड़ता। दो SPF रिकॉर्ड मिलते नहीं। दोनों अमान्य हो जाते हैं, और जो मेल पहले पहुँचता था वह उस हफ्ते गायब होने लगता है जब स्थानांतरण बाकी सब में अच्छा रहा।
स्थानांतरण पूरा कहने से पहले नए होस्ट से, अपने नियंत्रण वाले इनबॉक्स पर एक असली ऑर्डर मेल और एक पासवर्ड रीसेट भेजता हूँ। लॉग की पंक्ति “sent” इनबॉक्स के संदेश के बराबर नहीं। जाँच दूसरा है।
apex और www पर HTTPS। प्रमाणपत्र अपने आप नवीनीकृत होता है। मेल अब भी जाता है। पाँच रास्ते अब भी पूरे होते हैं। फिर मैं एक दिन त्रुटि लॉग देखता हूँ, होमपेज नहीं। होमपेज वह है जिसके लिए मॉनिटर आपको पहले से बधाई दे रहा है। लॉग वह जगह है जहाँ webhook ने भुगतान प्रदाता को 404 लौटाना शुरू किया।
इस तरह किया गया स्थानांतरण उबाऊ होता है। बात यही है। माइग्रेशन की दिलचस्प कहानियाँ लगभग हमेशा उस पंक्ति की होती हैं जो इन्वेंटरी में थी ही नहीं।
