हम सक्रिय रूप से मॉड्यूल विकसित कर रहे हैं और जब हम अपनी उत्पादन साइट में परिवर्तन को दबाते हैं, तो आमतौर पर कई कॉन्फ़िगरेशन परिवर्तन होते हैं जिन्हें हमें बनाने की आवश्यकता होती है। इसे स्वचालित करने के लिए अच्छा होगा ... विचार?Magento: मैं विकास से उत्पादन वातावरण में कॉन्फ़िगरेशन परिवर्तन कैसे माइग्रेट कर सकता हूं?
अपने मॉड्यूल की "एसक्यूएल" निर्देशिका में स्थापित या अपग्रेड स्क्रिप्ट के हिस्से के रूप में परिवर्तन करें। आपके मॉड्यूल की "config.xml" फ़ाइल में प्रत्येक मिलान परिवर्तन की संस्करण संख्या बढ़ जाती है और <config><global><resources><MODULE_setup><setup> नोड को भरना भी याद है।
क्योंकि स्क्रिप्ट Magento के संदर्भ में चलाया जाता है तुम भी, अद्यतन एसक्यूएल कमांड के रूप में हो की जरूरत नहीं है सब सामान्य कार्यक्षमता की पहुंच है।
मैं आपकी टिप्पणी से सहमत हूं, लेकिन इसे आगे ले जाऊंगा यानी "अपडेट ** ** एसक्यूएल कमांड के रूप में नहीं होना चाहिए"। मैं किसी भी डीडीएल या डीएमएल आंकड़ों में नहीं आया हूं जिन्हें Magento की कॉन्फ़िगरेशन संरचनाओं के माध्यम से निष्पादित नहीं किया जा सकता है। संस्करण नियंत्रण के लिए बहुत आसान है। –
एक फॉलो-अप प्रश्न [यहां] है (http://stackoverflow.com/q/4315660/471559)। – clockworkgeek
सुनिश्चित नहीं हैं कि अगर यह अभी भी वास्तविक है, लेकिन अगर आप व्यवस्था करने के लिए बदलाव का मतलब है -> config, तो यह और अधिक बेहतर बजाय डेटाबेस उन्नयन लेखन के इस तरह के config.xml नोड्स उपयोग करने के लिए है।
मैग्नेटो वैश्विक XML संरचना में core_config_data तालिका को संसाधित करता है, ताकि आप सिस्टम कॉन्फ़िगरेशन में परिवर्तन करने के लिए डीबी तालिका का उपयोग किये बिना एक्सएमएल संरचना को बदल सकें।
<config>
<stores>
<french>
<design>
<theme>
<default>french</default>
<theme>
</design>
</french>
</stores>
<websites>
<base>
<design>
<theme>
<default>english</default>
<theme>
</design>
</base>
</websites>
</config>
इस उदाहरण एक विन्यास क्षेत्र Magento में दो क्षेत्रों के लिए बदल गया है में:
यहाँ छोटा सा उदाहरण है। वर्तमान वेबसाइट और स्टोर के आधार पर यह वर्तमान विषय की परिभाषा है।
तो <stores /> नोड एक खास दुकान के लिए विन्यास मान हैं। जहां प्रत्येक बच्चे तत्व को स्टोर कोड के साथ नामित किया जाता है और इसमें नेस्टेड व्यू में कॉन्फ़िगरेशन डेटा होता है। और <website /> नोड में किसी विशेष वेबसाइट के लिए कॉन्फ़िगरेशन मान होते हैं। जहां प्रत्येक बच्चे तत्व को वेबसाइट कोड के साथ नामित किया गया है और इसमें नेस्टेड दृश्य में कॉन्फ़िगरेशन डेटा भी शामिल है।
इसके अलावा वैश्विक क्षेत्र में कॉन्फ़िगरेशन मान के लिए उपलब्ध <default /> नोड है। लेकिन यह <stores /> और <websites /> द्वारा ओवरराइड किया जाएगा यदि कोई विशेष मान दायरे के लिए है।
मैं कॉन्फ़िगरेशन में केवल config.xml के माध्यम से कॉन्फ़िगरेशन में बदलाव कर रहा हूं क्योंकि प्रोजेक्ट को तैनात करना बहुत आसान है जब आपको इसे "सिस्टम -> कॉन्फ़िगर" में परिवर्तन किए बिना Magento इंस्टॉलर के माध्यम से इंस्टॉल करना होगा।
जहां तक मैं इस तकनीक को समझता हूं केवल डिफ़ॉल्ट मानों के लिए उपयोग किया जा सकता है जो मौजूद नहीं हैं या डीबी तालिका 'core_config_data' पर' NULL' 'हैं। यदि मान मौजूद है, तो हमें डेटाबेस अपग्रेड लिखना होगा। क्या मैं सही हू? –
@ v.kondratyuk, हाँ आप सही हैं। असल में यह दृष्टिकोण आपको प्रति स्टोर/वेबसाइट/डिफ़ॉल्ट दायरे के डिफ़ॉल्ट डेटा सेट निर्दिष्ट करने देता है, जिसे बाद में व्यवस्थापक उपयोगकर्ता द्वारा बदला जा सकता है। यदि आप टीम में डेवलपर्स या क्यूए तैनाती के बीच कोड का आदान-प्रदान करते हैं, तो एक्सएमएल फ़ाइल के माध्यम से कॉन्फ़िगरेशन माइग्रेट करना हमेशा अच्छा होता है। यदि डेवलपर या किसी अन्य उपयोगकर्ता ने डीबी में एक मान बदल दिया है, तो आपको डीबी अपग्रेड द्वारा इस बदलाव को प्रभावित नहीं करना चाहिए, क्योंकि यह टीम में अन्य देवताओं के लिए सत्र डीबग करने के लिए लगाया जा सकता है। –
जब तक मैगेंटो को तैनात किए जाने पर कुछ बहुत ही अजीब आवश्यकताएं न हों, तो मैं कहूंगा कि यह [PHP साइट परिनियोजन सुझाव] का एक संभावित डुप्लिकेट है (http://stackoverflow.com/questions/2628835/php-site-deployment-suggestion)। असल में, फिंग आपको मदद करनी चाहिए। – Gordon