Staging, WordPress और WooCommerce साइटों के लिए है। एक बार staging कॉपी बन जाने के बाद, दो ऑपरेशन इसे उपयोगी बनाए रखते हैं: आपके परीक्षण किए गए बदलावों को live साइट पर भेजना, और staging को production की ताज़ा कॉपी में रीसेट करना। यह गाइड दोनों दिशाओं को विस्तार से कवर करती है, वे पुष्टियाँ जो आपकी live साइट की रक्षा करती हैं, और वे मामले जहाँ डेटाबेस को भेजने से डेटा नष्ट हो जाएगा।
यदि आपने अभी तक कोई staging वातावरण नहीं बनाया है, तो Staging वातावरण का उपयोग करना से शुरू करें। यह लेख वहाँ से आगे बढ़ता है जहाँ staging पहले से मौजूद है।
दो दिशाएँ
| ऑपरेशन | यह क्या अधिलेखित (overwrite) करता है | इसका उपयोग कब करें |
|---|---|---|
| उत्पादन को भेजें | आपकी live साइट | जब staging पर किए गए बदलाव परीक्षित हों और live होने के लिए तैयार हों |
| Production से Reset करें | आपकी staging साइट | जब आप वर्तमान live साइट की एक साफ कॉपी के साथ काम करना चाहते हैं |
दोनों एक ही स्क्रीन पर स्थित हैं: वेबसाइटें, फिर आपकी साइट, फिर Environment, फिर स्टेजिंग।
उस स्क्रीन के ऊपर वाला कार्ड आपका staging डोमेन, उसकी स्थिति, कितनी देर पहले इसे production से आख़िरी बार सिंक किया गया था, और इसे आख़िरी बार कब भेजा गया था, दिखाता है। WP एडमिन आपको सीधे staging साइट के डैशबोर्ड में साइन इन कर देता है, और साइट पर जाएँ staging फ्रंट एंड को खोलता है।
जो staging कॉपी एक सप्ताह या उससे अधिक समय से सिंक नहीं हुई है, उसे उस कार्ड पर एम्बर रंग में चिह्नित किया जाता है। पुराना staging, बिना staging के भी बुरा है: आप ऐसी साइट के विरुद्ध परीक्षण करते रह जाते हैं जो अब live साइट जैसी नहीं रह जाती। काम का नया हिस्सा शुरू करने से पहले रीसेट करें, बाद में नहीं।
Staging को उत्पादन में भेजना
यह आपकी live साइट के कुछ हिस्से को, या पूरी साइट को, staging पर मौजूद चीज़ों से बदल देता है।
- Environment, फिर स्टेजिंग खोलें।
- Staging को उत्पादन में भेजें तक स्क्रॉल करें।
- चेकबॉक्स की मदद से चुनें कि क्या भेजना है: फाइलें, डेटाबेस, या दोनों।
- यदि आपने डेटाबेस टिक किया है, तो URLs को फिर से लिखें टिक रहने दें। यह हर टेबल में सर्च और रिप्लेस चलाता है ताकि भेजने की प्रक्रिया के दौरान staging होस्टनेम को आपके production होस्टनेम से बदल दिया जाए।
- मैं समझता हूँ कि यह मेरी live production साइट को संशोधित करता है। टिक करें।
- पुष्टि बॉक्स में अपना production डोमेन बिल्कुल वैसे ही टाइप करें जैसा दिखाया गया है।
- उत्पादन को भेजें पर क्लिक करें।
जब तक चेकबॉक्स टिक नहीं होता और डोमेन मेल नहीं खाता, तब तक बटन अक्षम रहता है, ताकि गलत समय पर किया गया क्लिक भेजने की प्रक्रिया शुरू न कर सके।
भेजने की प्रक्रिया अधिलेखित (overwrite) करती है, मर्ज नहीं करती। आपके आख़िरी रीसेट के बाद से production पर जो कुछ भी बदला है, उसे staging पर जो कुछ भी है उससे बदल दिया जाता है। इसमें नई पोस्ट, नए ग्राहक खाते, नई फ़ॉर्म प्रविष्टियाँ और नए ऑर्डर शामिल हैं।
कुछ भी लिखे जाने से पहले production का एक पूर्ण बैकअप स्वतः ले लिया जाता है, और यदि भेजने की प्रक्रिया बीच में विफल हो जाती है, तो production को उस बैकअप पर वापस ले जाया जाता है। छोटी साइटें आमतौर पर एक मिनट से भी कम समय में पूरी हो जाती हैं; एक बड़ा डेटाबेस या कई गीगाबाइट की मीडिया लाइब्रेरी ज़्यादा समय लेती है।
Files, Database, या दोनों में से चुनना
यह सबसे महत्वपूर्ण निर्णय है, और आमतौर पर जवाब "दोनों" नहीं होता।
केवल Files। उस साइट के लिए सुरक्षित डिफ़ॉल्ट जो आगंतुकों से कुछ भी एकत्र करती है। थीम में बदलाव, प्लगइन अपडेट, टेम्पलेट बदलाव और कस्टम कोड, ये सब फ़ाइलों में रहते हैं। केवल फ़ाइलें भेजने से production पर मौजूद हर पोस्ट, टिप्पणी, ऑर्डर और उपयोगकर्ता अछूता रहता है।
केवल Database। staging पर किए गए सामग्री या सेटिंग बदलावों के लिए, ऐसी साइट पर जहाँ कोई production को सीधे संपादित नहीं करता। व्यवहार में यह दुर्लभ है।
दोनों। किसी रीडिज़ाइन या रीबिल्ड के लिए सही है जहाँ staging नई साइट है और production को पूरी तरह बदला जा रहा है। इसकी घोषणा करें, इसे गैर-कार्य घंटों में करें, और पहले यह पुष्टि करें कि आपके पास एक वर्तमान बैकअप मौजूद है।
लाइव स्टोर पर डेटाबेस भेजने से ऑर्डर मिट जाते हैं। WooCommerce ऑर्डर, ग्राहक, सदस्यता, कूपन और स्टॉक स्तर डेटाबेस में रखता है, इसलिए production से आपके आख़िरी रीसेट के बाद दिए गए हर ऑर्डर, भेजने की प्रक्रिया पूरी होते ही गायब हो जाता है। इसकी आंशिक रिकवरी संभव नहीं है। किसी स्टोर पर, केवल फ़ाइलें भेजें, और डेटाबेस स्तर के बदलाव सीधे production पर करें। देखें WooCommerce सेट अप करना।
यही जाल, कम नाटकीय रूप में, किसी भी ऐसी साइट पर लागू होता है जिसमें टिप्पणियाँ, फ़ॉर्म सबमिशन, सदस्यता साइनअप या WordPress में संग्रहित मेलिंग सूची हो।
Production से Staging को रीसेट करना
यह सुरक्षित दिशा है: यह staging को वर्तमान live साइट से अधिलेखित (overwrite) कर देता है और production को कभी नहीं छूता।
- Environment, फिर स्टेजिंग खोलें।
- Production से Reset करें ढूँढें।
- फाइलें, डेटाबेस, या दोनों टिक करें।
- Production से Reset करें पर क्लिक करें।
ऐसा हमेशा करें जब:
- Production आगे बढ़ चुका हो, नई पोस्ट, नए ऑर्डर या सामग्री संपादनों के साथ।
- आप काम का कोई नया हिस्सा शुरू कर रहे हों और एक यथार्थवादी आधार चाहते हों।
- Staging इतना बदल चुका हो कि वहाँ का परीक्षण परिणाम कुछ अर्थ न रखता हो।
Staging पर जो कुछ भी भेजा नहीं गया है, वह नष्ट हो जाता है। यदि staging पर ऐसा काम है जो आप अभी भी चाहते हैं, तो पहले उसे भेज दें, या रीसेट करने से पहले सेटिंग्स, फिर फाइल मैनेजर के माध्यम से बदली हुई फ़ाइलों की कॉपी बाहर निकाल लें।
URL पुनर्लेखन कैसे काम करता है
WordPress अपना खुद का पता डेटाबेस में, ऑप्शंस टेबल की siteurl और home पंक्तियों में संग्रहित करता है, और पूर्ण URL पोस्ट सामग्री, मेटा मानों, विजेट सेटिंग और थीम विकल्पों में भी समाप्त हो जाते हैं।
आपकी staging साइट staging. पर चलती है जिसके बाद आपका डोमेन आता है, इसलिए जब तक आप वहाँ काम करते हैं, तब तक उन सभी मानों में से हर एक staging होस्टनेम की ओर इशारा करता है। भेजने की प्रक्रिया पर URLs को फिर से लिखें, सभी टेबल में एक उचित सर्च और रिप्लेस चलाता है, सीरियलाइज़्ड प्लगइन सेटिंग्स को सही ढंग से संभालता है, और staging होस्टनेम को आपके production होस्टनेम से बदल देता है।
जब तक आपके पास न करने का कोई विशेष कारण न हो, इसे टिक रहने दें। यदि आप केवल फ़ाइलें भेजते हैं, या कोई staging URL बच जाता है, तो इसे सर्च और रिप्लेस चलाना से ठीक करें।
एक वर्कफ़्लो जो टिका रहता है
- Production से reset करें ताकि staging live साइट से मेल खाए।
- शुरू करने से पहले production का बैकअप लें, ताकि आपके पास भेजने की प्रक्रिया से स्वतंत्र एक रिस्टोर पॉइंट हो: बैकअप लेना।
- काम staging पर करें। प्लगइन और थीम अपडेट, नया कोड, लेआउट बदलाव।
- staging डोमेन पर परीक्षण करें। जिन पेजों में आपने बदलाव किया है, उन्हें लोड करें, और जिनमें नहीं किया है उन्हें भी। किसी स्टोर पर, एक टेस्ट ऑर्डर शुरू से अंत तक चलाएँ।
- जब तक आपने जानबूझकर यह तय न किया हो कि डेटाबेस भी जाना चाहिए, तब तक केवल फ़ाइलें भेजें।
- तुरंत production जाँचें। होम पेज, एक गहरा पेज, चेकआउट, और एडमिन डैशबोर्ड।
- संतुष्ट होने के बाद staging को फिर से production से रीसेट करें, ताकि अगला दौर साफ शुरू हो।
Staging को पूरी तरह से आपकी production साइट से प्रबंधित किया जाता है। यह वेबसाइटें सूची में एक अलग प्रविष्टि के रूप में दिखाई नहीं देता, इसलिए इसके लिए हर नियंत्रण, इसे हटाने सहित, इसी एक टैब पर स्थित है।
Staging हटाना
उसी स्क्रीन के नीचे मौजूद Staging हटाएँ कार्ड staging कॉपी को हटा देता है। Production प्रभावित नहीं होता। किसी प्रोजेक्ट के पूरा होने पर इसे हटाएँ: staging आपकी योजना के स्टोरेज में गिना जाता है, और एक बासी कॉपी एक संपत्ति के बजाय एक देयता है।
समस्या निवारण
उत्पादन को भेजें बटन सक्रिय नहीं होता। दोनों शर्तें पूरी होनी चाहिए: पुष्टि चेकबॉक्स टिक हो, और production डोमेन बिल्कुल सही टाइप किया गया हो, बिना किसी https:// के और बिना अंत में स्लैश के।
भेजने की प्रक्रिया पूरी हो गई लेकिन साइट अभी भी पुरानी सामग्री दिखा रही है। यह कैशिंग है। WordPress, फिर त्वरित कार्य, फिर कैश फ्लश करें से फ्लश करें, प्रदर्शन, फिर Kapsule CDN से CDN साफ़ करें, और एक प्राइवेट विंडो में रीलोड करें।
भेजने की प्रक्रिया के बाद live साइट पर staging के URL दिख रहे हैं। डेटाबेस बिना URLs को फिर से लिखें टिक किए भेजा गया था। staging होस्टनेम से अपने production डोमेन तक सर्च और रिप्लेस चलाएँ: सर्च और रिप्लेस चलाना।
मैंने डेटाबेस भेजा और ऑर्डर खो गए। अधिलेखित डेटाबेस पर और अधिक ऑर्डर आने से पहले, तुरंत स्वचालित प्री-पुश बैकअप को पुनर्स्थापित करें: बैकअप से पुनर्स्थापित करना।
रीसेट के बाद staging में एक त्रुटि दिखाई दे रही है। इसका सामान्य कारण एक ऐसा प्लगइन है जो production डोमेन को हार्डकोड करता है। staging कार्ड पर WP एडमिन से साइन इन करें और वहाँ प्लगइन को तब तक निष्क्रिय करें जब तक त्रुटि साफ़ न हो जाए, फिर production पर संबंधित प्लगइन को ठीक करें या बदलें।