एक साइट पर काम करने वाले कई डेवलपर्स / संपादक प्रगति पर हैं

Question

पृष्ठभूमि

मैं अपनी पहली काफी बड़ी वर्डप्रेस साइट के निर्माण के अंतिम चरणों के पास हूं, और अब कुछ घर्षण का सामना कर रहा हूं। अधिकांश भाग के लिए, साइट को मेरी स्थानीय मशीन पर विकसित किया गया था और मैं समीक्षा के लिए एक स्टेजिंग सर्वर तक बदलावों को आगे बढ़ाऊंगा ( अधिक पृष्ठभूमि के लिए यह प्रश्न देखें )। जिस समाधान के साथ मैंने काम किया, वह तब बहुत अच्छी तरह से काम कर रहा था जब यह सिर्फ मेरे लिए संपादन सामग्री थी, लेकिन अब कुछ अन्य लोग सामग्री को संपादित कर रहे हैं, जबकि मेरे पास अभी भी विशेषताएं हैं। यह विचार था: यदि कंसर्ट में सामग्री और सामग्री एक साथ आती हैं तो हम चीजों को अधिक तेज़ी से प्राप्त कर सकते हैं ... लेकिन अब मुझे यकीन नहीं है।

वर्तमान में मेरे स्थानीय मशीन की तुलना में मंचन सर्वर पर डेटाबेस में अलग-अलग सामग्री है। यह अपने आप ठीक है, क्योंकि मुझे अपनी स्थानीय मशीन पर अंतिम बॉडी कॉपी की आवश्यकता नहीं है, लेकिन मुझे और अधिक विकास करने की आवश्यकता है जो डेटाबेस को प्रभावित करेगा (एक जोड़े को और अधिक प्लगइन्स लिखना / लिखना होगा जिन्हें अपनी स्वयं की तालिकाओं की आवश्यकता है)।

मेरा सवाल यह है कि:

क्या डेटाबेस के विलय को स्वचालित करने का एक आसान तरीका है ताकि कई लोग वर्डप्रेस इंस्टॉल पर काम कर सकें? मैं, निश्चित रूप से, उन तालिकाओं को निर्यात कर सकता हूं जो मुझे पता है कि मेरे स्थानीय मशीन पर बदल गए हैं और उन्हें मचान सर्वर पर धकेल दिया है, लेकिन यह संभव है कि मचान सर्वर पर कुछ चीजें भी हैं जिन्हें मैं नीचे लाना चाहूंगा। मैं दोनों DB के SQL आउटपुट को पकड़ सकता हूं और उन्हें अलग कर सकता हूं ... लेकिन यह थकाऊ और हैकिश लगता है। मैं सोच रहा था कि यह एक समस्या है जिसे दूसरों ने हल किया है; अगर इस तरह की चीज़ को संभालने के लिए एक समुदाय-स्वीकृत तरीका है।

धन्यवाद!

Comments

किसी अन्य साइट को बंद करने या स्थानांतरित करने के लिए मतदान (जनवरी: एक अच्छे पर कोई विचार? सुपरयूज़र शायद)। यह वर्डप्रेस विशिष्ट नहीं है, जैसा कि आप Drupal, Joomla, या किसी भी PHP + MySQL संचालित साइट पर समान समस्याओं में चलाएंगे।

— जॉन पी बलोच

यह कहा गया है, मेरा सुझाव यह है कि आप एक स्थानीय के बजाय एक दूरस्थ मचान सर्वर का उपयोग करें।

— जॉन पी बलोच

@ जॉन पी बलोच: ड्रुपल के साथ, ड्रश जैसी चीज इस स्थिति में बहुत मदद करेगी। मैं व्यक्तिगत रूप से Django के लिए उपयोग किया जाता हूं जहां इन प्रकार की समस्याओं को जुड़नार द्वारा कम किया जाता है। इसके अलावा, मेरे पास वर्तमान में दो स्टेजिंग सर्वर हैं: एक स्थानीय और एक रिमोट। बात यह है कि मैं अपने रिमोट मशीन पर अपना काम करता हूं, लेकिन इसे सर्वर पर धकेलने की जरूरत है ताकि दूसरे इसे देख सकें। अंतिम सर्वर कुछ ऐसा है जिसे तब सेट किया जाएगा जब हमारे पास सब कुछ एक साथ होगा।

— गेविन एंडरग

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

— माइकस्किंकेल

@ गैविन: क्षमा करें, मैंने आपके प्रश्न की गलत व्याख्या की। हां, मेरा मानना ​​है कि उत्पादन सर्वर पर सब कुछ लिख देगा। : /

— ज़ैक

Answer 1

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

Git में सब कुछ

यह कुछ ऐसा था जो मैं सवाल पूछते हुए भी कर रहा था, लेकिन इस बिंदु को कॉल करना अच्छा है। Git का उपयोग करने से न केवल हमें अधिक उत्पादक होने में मदद मिली है, बल्कि इसने हमारे सामूहिक गधों को भी कई बार बचाया है।

क्या आपको कभी किसी साइट पर प्रमुख संरचनात्मक नवीनीकरण करने, क्लाइंट से नवीनीकरण के लिए अनुमोदन प्राप्त करने और गैर-नवीनीकृत संस्करण में मामूली अपडेट करने की आवश्यकता है? हमारे पास है, और Git हमें इसे करने देंगे। इस सेटअप का वर्णन करना थोड़ा लंबा हो जाएगा, लेकिन मूल बातें यह हैं कि हमने एक नई शाखा बनाई, उस शाखा को सर्वर पर खींचा, और उस शाखा के लिए एक उपडोमेन संलग्न किया।

हमें Git द्वारा भी सहेजा गया है। यह निश्चित रूप से हमें वापस परिवर्तनों को रोल करने की अनुमति देता है, जो महान है, लेकिन यह हमें फ़ाइलों के पुराने संस्करणों को वापस लाने की भी अनुमति देता है। इसका मतलब यह है कि यदि कोई ग्राहक पूछता है, "याद रखें कि साइट के इस हिस्से ने लगभग एक साल पहले काम किया था? क्या हम उसे वापस ला सकते हैं?", इसका उत्तर हां है - भले ही उस व्यक्ति से पूछा जाए कि वह एक वर्ष में उस परियोजना पर नहीं था। पहले।

इन बिंदुओं के अलावा, इसका मतलब यह भी है कि हम कभी भी उन फाइलों के बिना अटक जाते हैं जिनकी हमें जरूरत नहीं है। हम किसी भी मशीन से साइट के नवीनतम संस्करण को हमेशा नीचे खींच सकते हैं और बदलाव करना शुरू कर सकते हैं।

तैनात करने के लिए Git का उपयोग करें

हम अपने वर्डप्रेस को मीडिया टेम्पल पर होस्ट करते हैं , और हम वास्तव में उन्हें पसंद करते हैं। वे सबसे सस्ते प्रदाता नहीं हैं, लेकिन उनकी सेवा उत्कृष्ट है और उनके सर्वर वास्तव में अच्छी तरह से स्थापित हैं। डिफ़ॉल्ट रूप से Git भी प्रदान करते हैं। इसका अर्थ है कि हम सर्वर को Git रिपॉजिटरी के रूप में सेट कर सकते हैं, और SFTP का उपयोग करने के बजाय उस तरह से परिवर्तन खींच सकते हैं। इसका अर्थ यह भी है कि सर्वर पर काम करने से अधिलेखित होने का खतरा नहीं है (जैसा कि उन परिवर्तनों को विलय किया जा सकता है और वापस ऊपर धकेल दिया जा सकता है)।

क्योंकि हम बिटबिट को अपने Git होस्ट के रूप में उपयोग करते हैं, इसलिए यहां थोड़ा अतिरिक्त काम करना पड़ता है। सबसे पहले हम .shsh / config files का उपयोग करते हैं ताकि हम ssh sitenameअपने सर्वर में लॉग इन करने के लिए चीजों को टाइप कर सकें (हम भी पासवर्डलेस SSH का उपयोग करते हैं , जिससे यह सुपर आसान हो जाता है)। हम यह भी सुनिश्चित करते हैं कि हमेशा ssh पासफ़्रेज़ का उपयोग करें (Mac OS X आपको Keychain.app में अपना पासफ़्रेज़ संग्रहीत करने की अनुमति देकर इसे बहुत आसान बनाता है )। अंत में, हम एक फॉरवर्डएजेंट लाइन जोड़ते हैं। हम जिस होस्ट को खींचना चाहते हैं, उस पर .shsh / config एंट्री। इसका अर्थ है कि हमें केवल बिटबकेट में प्रत्येक व्यक्ति की SSH सार्वजनिक कुंजी की आवश्यकता है, न कि प्रत्येक सर्वर की सार्वजनिक कुंजी की। हम .gitसार्वजनिक HTML निर्देशिका के ऊपर निर्देशिका को एक निर्देशिका रखना सुनिश्चित करते हैं ।

स्वचालित डेटाबेस डंप

सर्वर के उत्पादन मोड में होने के बाद, हम केवल मामले में, अपने डेटाबेस का स्वतः बैकअप लेना सुनिश्चित करते हैं ।

हर किसी का अपना wp-config है

क्योंकि हम सभी को हमारे अपने स्थानीय डेटाबेस उपयोगकर्ता नाम और पासवर्ड मिल गए हैं, और क्योंकि हम विभिन्न नामों और सेवारत तंत्रों का उपयोग कर सकते हैं, हम प्रत्येक अपनी खुद की wp-config फाइल रखते हैं। इनमें से प्रत्येक की तरह एक नाम के साथ Git में संग्रहीत किया जाता wp-config-gavin.phpहै, और जब हम उस config उपयोग करना चाहते हैं, हम सिमलिंक यह करने के लिए wp-config.php(जो का उपयोग कर Git द्वारा नजरअंदाज कर दिया है .gitignore )।

यह भी हमें डेटाबेस तालिका siteurlमें विकल्प को ओवरराइड करने की अनुमति देता है wp_optionsजैसे:

define('WP_SITEURL', 'http://sitename.localhost');
define('WP_HOME', 'http://sitename.localhost');

यह सर्वर स्थान के लिए डेटाबेस को देखने से वर्डप्रेस को रोकता है, और इसका मतलब है कि स्थानीय और सर्वर इंस्टॉल के बीच स्थान में अजीब अंतर नहीं हैं।

Wp-config.php फ़ाइलों के बारे में एक अंतिम नोट: सार्वजनिक एचटीएमएल निर्देशिका के ऊपर उन्हें संग्रहीत करना सुनिश्चित करें और केवल वेब उपयोगकर्ता के लिए पढ़ी गई अनुमतियों को बनाएं । इससे वर्डप्रेस को सुरक्षित बनाने में बहुत फर्क पड़ता है।

डेटाबेस समस्या

अंत में, इस मामले का मांस।

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

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

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

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

Answer 2

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

---

• चरण 1। अपने विकास डेटाबेस का उपयोग करें
• चरण 2। development.domain.com के सभी उदाहरणों को production.domain.com ^ ^ में बदलें
• चरण 3. MySQL में लॉगिन करें, डेटा आयात करने के लिए SOURCE कमांड चलाएँ source /path/to/file

^ ^ नए के साथ पुराने डोमेन के सभी उदाहरणों को कैसे बदलें: (1) नीचे दी गई स्क्रिप्ट की प्रतिलिपि बनाएँ। (२) chmod +xयह। (३) इसे चलाना।

उपयोग: ./script.sh development-dump.sql > production-dump.sql

#!/bin/sed -f
s/'\([^\\']*\)development.domain.com\([^\\']*\)'/'\1production.domain.com\2'/g

Comments

थोड़ा ध्यान रखें: sed पहले से सीरियलाइज्ड किए गए mysql dumps के अंदर एन्कोडेड डेटा से निपटने में सक्षम नहीं है।

— हैकर

प्रश्न का उत्तर आपने पहले दिया था, वास्तव में :) मुझे लगता है कि मैं यहाँ एक अलग प्रश्न पूछ रहा हूँ, हालाँकि। यह पूरी डीबी को डंप करने के लिए बहुत अच्छा है जब यह सिर्फ मुझ पर काम कर रहा है, लेकिन अगर मैं उपरोक्त वर्णित स्थिति में ऐसा करता हूं तो मैं या तो अन्य लोगों के परिवर्तनों को अधिलेखित कर दूंगा, या अपने स्वयं के परिवर्तनों को अधिलेखित कर दूंगा। मैं उन परिवर्तनों को संयोजित करना चाह रहा हूं जो एक से अधिक व्यक्ति वर्डप्रेस इंस्टेंस पर काम करते हैं।

— गेविन एंडरग

Answer 3

मैं अभी इसी समस्या के विभिन्न समाधानों के साथ प्रयोग कर रहा हूं। यह निश्चित रूप से एक मुश्किल है।

मेरा वर्तमान समाधान है --स्काइप-एक्सटेंडेड-इन्सर्ट फ़्लैग का उपयोग करके एक स्थानीय mysql डंप करना। मेरा मानना ​​है कि यह ध्वज डेटाबेस की प्रत्येक पंक्ति के लिए एक सम्मिलित रिकॉर्ड विवरण उत्पन्न करता है, जिससे डंप थोड़ा और मर्ज के अनुकूल हो जाता है। मैंने इस लेख से वह तरकीब निकाली: http://www.viget.com/extend/backup-your-database-in-git/ ।

मैं तब स्रोत को नियंत्रित करता हूं। साइट के स्रोत फ़ाइलों के साथ Git का उपयोग करके .sql datadump फ़ाइल को नियंत्रित करता है। जब दूसरा डेवलपर कोड परिवर्तन को खींचता है, .sql फ़ाइल इसके साथ आती है। फिर वह इस फाइल को डेटाबेस के अपने स्थानीय संस्करण में आयात करता है। हम दोनों ने अपने-अपने स्थानीय डेटाबेस को दोनों मशीनों पर उसी तरह सेट किया है, जो MAMP का उपयोग कर रहे हैं, इसलिए किसी भी खोज और प्रतिस्थापन को करने की कोई आवश्यकता नहीं है।

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

मैं सर्वर पर एक साझा देव डेटाबेस स्थापित करने का प्रयास कर सकता हूं और वेबसाइट की हमारी दोनों स्थानीय प्रतियों को एसएसएच सुरंग के माध्यम से एक ही डीबी तक जोड़ने का प्रयास कर सकता हूं। हालाँकि, यह दृष्टिकोण समस्याओं में चलेगा जब भी हम में से कोई एक प्लगइन स्थापित करता है। मूल रूप से PHP फाइलें और MySQL DB सिंक से बाहर हो जाएंगे।

मैं यह सुनने के लिए उत्सुक हूं कि अन्य लोग इस समस्या से कैसे निपट रहे हैं।