सबसे अच्छी तैनाती की रणनीति क्या है?

Question

Magento स्टोर स्थापित करना न केवल स्व-इंस्टॉल करने योग्य एक्सटेंशन को विकसित करने का विषय है, बल्कि इसके लिए "मैन्युअल एंट्री" संचालन की भी बहुत आवश्यकता होती है, जैसे कि एंड एडिटिंग एट्रिब्यूट्स, कैटेगिरी, प्रोडक्ट्स, प्राइस रूल्स CMS पेज वगैरह बनाना, सभी का उल्लेख नहीं करना। सिस्टम कॉन्फ़िगरेशन में परिवर्तन।

मैं आपकी सबसे अच्छी रणनीति को रेखांकित करने में आपकी मदद करना चाहूंगा, जब यह विकास से मंचन और उत्पादन पर्यावरण तक एक Magento स्टोर को तैनात करने की बात आती है।

मेरी एक रणनीति "तैनाती मॉड्यूल" लिखने की है, जो प्रोग्रामेटिक रूप से ऊपर उल्लिखित संस्थाओं को बनाता है, लेकिन यह बहुत समय लेने वाला कार्य है और कभी-कभी यह मुझे थोड़ा ओवरकिल लगता है।

हाल ही में मैंने सेलेनियम आईडीई का उपयोग व्यवस्थापक कार्यों को फिर से शुरू करने के लिए किया था, लेकिन सभी परीक्षण सूटों को स्थापित करने के लिए आवश्यक समय उपरोक्त वर्णित से दूर नहीं है।

शायद एक इष्टतम समाधान एक Magento सिस्टम के स्नैपशॉट करने में सक्षम मॉड्यूल का उपयोग हो सकता है जो आपको यह चुनने देता है कि क्या तैनात करना है।

इसलिए:

• तैनाती के लिए आपकी रणनीति क्या है?
• वहाँ एक मॉड्यूल Magento सिस्टम का एक स्नैपशॉट करने में सक्षम है जो आपको यह चुनने देता है कि क्या तैनात करना है?
• यदि ऐसा कोई मॉड्यूल मौजूद नहीं है और प्रदान किया गया ऐसा मॉड्यूल एक उचित समाधान है, तो क्या किसी को इसे विकसित करने में अपना योगदान देने में कोई दिलचस्पी है?

धन्यवाद!

Comments

यह किसी अन्य टैग या टैग श्रेणी की आवश्यकता को इंगित कर सकता है। क्या आप एक बंद दुकान हैं या आप एक सेवा प्रदाता के रूप में सामान्य सुझावों की तलाश कर रहे हैं? यदि उत्तरार्द्ध, किसी भी उत्तर को "डेटा पर ग्राहक को कितना नियंत्रण चाहिए" पर निर्भर करता है।

— benmarks

मेरा दृष्टिकोण एक देव टीम से संबंधित डेवलपर में से एक है। मान लीजिए कि मैं एक ऐसा खंड विकसित कर रहा हूं, जिसे काम करने के लिए कुछ डेटा की जरूरत है, एक श्रेणी संरचना कहें। मैं व्यवस्थापक के माध्यम से संरचना बनाता हूं, कोड करता हूं और अपना कोड धक्का देता हूं। मैं सोच रहा हूं कि क्या सर्वश्रेष्ठ रणनीति भी कोड लिखना और पुश करना है जो आवश्यक श्रेणी संरचना बनाता है। क्या होगा यदि मेरी श्रेणी की संरचना या सेटिंग अन्य डेवलपर्स द्वारा अपने साथ धकेल दी जाती हैं, जिन्होंने खुद को धक्का दिया? मैं संघर्षों को कैसे संभालूँ? यही मेरा सवाल है।

— एलेसेंड्रो रोंची

@AlessandroRonchi यह एक मूट बिंदु है, और एक संघर्ष जो कभी नहीं होना चाहिए। आपकी श्रेणी की संरचना कुछ ऐसी नहीं है जिसे पूरी तरह से बदलना चाहिए, इस प्रकार एक डेवलपर को दूसरे के बारे में जानने के बिना आपकी संरचना में एक बड़े बदलाव को बाहर नहीं करना चाहिए। यदि ऐसा होता है, तो आपको अपने अंतर-देव संचार को संबोधित करने की आवश्यकता है। आम तौर पर किसी साइट के लिए श्रेणी संरचना को पहले दिन से नीचे रखने की आवश्यकता होती है, और कभी भी फिर से बदलने की आवश्यकता नहीं होती है, बस इसमें जोड़ा जाता है। यदि आपको इसे बदलने की आवश्यकता है, तो आपने इसे पहली बार सही तरीके से स्कोप नहीं किया है।

— ProxiBlue

@dedmeet दुर्भाग्य से, दुनिया में मैं जानता हूं और काम करता हूं, चीजें हर दिन बदलती हैं; ग्राहक अपना दिमाग बदलते हैं, डेवलपर्स अपना दिमाग बदलते हैं, काले हंस होते हैं। मुझे परिवर्तनों के लिए तैयार रहना होगा; वैसे भी अगर श्रेणी संरचना को पहले दिन से बदलने की जरूरत नहीं है, तो यह पूरे हिस्से का केवल एक छोटा सा हिस्सा है और पूरा हिस्सा एक "प्रगति में काम" परियोजना है जिसे चीजों को प्राप्त करने के लिए बदलना चाहिए।

— एलेसेंड्रो रोंची

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

— प्रोब्ब्ल्यू

Answer 1

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

इसके पीछे मानसिकता यह है कि अगर साइट को नए सिरे से डीबी का उपयोग करके पुन: स्थापित करने की आवश्यकता है, तो सब कुछ वापस आ जाता है जैसा कि आपके पास था। यह इस तथ्य में भी मदद करता है कि मैं समय-समय पर लाइव डीबी की एक प्रति के साथ यूएटी साइट को अपडेट करता हूं। उट में मॉड्यूल फिर से काम करना जारी रखते हैं क्योंकि वे अपने कॉन्फ़िगरेशन में फिर से स्लॉट करते हैं।

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

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

हां स्क्रिप्टिंग में अधिक समय लगता है, लेकिन बाद में मैन्युअल रूप से एक संपूर्ण साइट कॉन्फ़िगरेशन सेटिंग्स को फिर से बनाने में बहुत अधिक समय लगेगा। यह शर्मनाक हो सकता है अगर आप कुछ भूल जाते हैं और साइट को ठीक से काम नहीं करने का कारण बनाते हैं, या किसी स्थानीय साइट पर एक नया देव कार्य है जो कुछ महत्वपूर्ण कॉन्फ़िगरेशन सेटअप को याद कर रहा है।

Comments

मैं समर्पण से सहमत हूं। जब आप पहली बार सभी अद्यतनों को स्क्रिप्ट करना सीखते हैं, तो यह अधिक प्रारंभिक कार्य हो सकता है, लेकिन यदि आपको 3-4 डेवलपर्स के लिए मैन्युअल रूप से कॉन्फ़िगरेशन अपडेट लागू करना है, तो स्टेजिंग, यूएटी और लाइव, समन्वय और वास्तविक काम में अधिक समय लगने वाला है। हमारा वर्कफ़्लो बहुत समान है: यदि कॉन्फ़िगरेशन को एक (पुन: प्रयोज्य) एक्सटेंशन के लिए आवश्यक है, तो इसे वहां रखें। यदि कॉन्फ़िगरेशन क्लाइंट-विशिष्ट है, तो इसे प्रोजेक्ट-विशिष्ट एक्सटेंशन में डालें। कुछ अपवादों में से एक गाड़ी के नियम हैं जो अपडेट करने / बनाने के लिए मज़ेदार नहीं हैं।

— मथायस ज़ीस

मैं सिर्फ एक मॉड्यूल जारी करता हूं जो आवश्यक कॉन्फिग स्क्रिप्ट बनाने में मदद करता है, इस प्रकार मैन्युअल स्क्रिप्ट बनाने के लिए होने के सांसारिक कार्य को समाप्त कर देता है। मॉड्यूल निर्यात करने के लिए कॉन्फ़िगरेशन मूल्यों के चयन की अनुमति देने के लिए core_config_data तालिका के ग्रिड प्रदर्शन का उपयोग करता है। मेरे जीवन को बस थोड़ा सा सरल बनाएं, और मुझे आशा है कि यह दूसरों के लिए काम करेगा। proxiblue.com.au/blog/magento-config-data-generator

— ProxiBlue

Answer 2

मैं कई महीनों पहले कुछ शोध कर रहा था। यहां ऐसी साइटें हैं जिन्हें आप संदर्भित कर सकते हैं।

Magento बेस URL और देव / स्टेजिंग इंस्टॉलेशन
Magento Development और तैनाती
Magento Git गाइड और ब्रांचिंग के लिए Magento MySQL डाटाबेस के वर्क फ्लो
क्विकर डंपिंग

Comments

धन्यवाद, मैं उन सभी को पढ़ूंगा और कुछ विचारों के साथ वापस आऊंगा।

— एलेसेंड्रो रोंची

मैंने सभी संसाधनों को पढ़ा है; मैं पहले से ही उनमें से कुछ को जानता था, अन्य जिन्हें मैं नहीं जानता था वे बहुत दिलचस्प हैं। उनमें से कोई भी, वैसे भी, मेरी समस्या का समाधान है और मैंने एक एक्सटेंशन को स्केच करने का फैसला किया है जो मेरी जरूरतों को पूरा करने की कोशिश करेगा। आप सभी को धन्यवाद जिसने मुझे कीमती सलाह दी। मैं कुछ परिणामों के साथ यहां वापस आने की उम्मीद करता हूं।

— एलेसेंड्रो रोंची

प्रिय एलेसेंड्रो, मैं आपके तरीके को देखना चाहूँगा जो कि मैं और अधिक आरामदायक तकनीक देख रहा हूँ!

— औज़ुज़ Oलिक्देमीर

Answer 3

मैं आप सभी को धन्यवाद देना चाहता हूं क्योंकि आपके विचारों ने मुझे प्रेरित किया है और मुझे एक एक्सटेंशन विकसित करने के लिए प्रेरित किया है, जिसे सिंक में विभिन्न वातावरणों को बनाए रखने की समस्या को हल करने के इरादे से "माजप्लॉय" कहा जाता है।

http://www.mageploy.com

Mageploy को अभी भी विस्तारित किया जाना है, अच्छी तरह से प्रलेखित और पूरी तरह से परीक्षण किया गया है, भले ही मैं पहले से ही कुछ लाभों वाले परियोजनाओं में इसका उपयोग कर रहा हूं।

यह खुला स्रोत है और किसी भी मदद या सुझाव wil की सराहना की जाएगी।

सादर

Answer 4

स्क्रिप्ट स्थापित करने और संस्थाओं को बनाने के संबंध में, मेरी सामान्य भावना यह है कि यदि यह आवश्यक है या मॉड्यूल द्वारा अपेक्षित है, तो इसे एक स्क्रिप्ट के भाग के रूप में बनाया जाना चाहिए।

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

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

Comments

"स्क्रिप्ट स्थापित करने और संस्थाओं को बनाने के संबंध में, मेरी सामान्य भावना यह है कि यदि यह मॉड्यूल द्वारा अपेक्षित या अपेक्षित है, तो इसे इंस्टॉल स्क्रिप्ट के हिस्से के रूप में बनाया जाना चाहिए।" यह विचार करने के लिए सबसे प्रमुख बिंदु है, और कॉन्फ़िगर सेटिंग्स पर लागू होता है। मेरा त्वरित परीक्षण: जब मुझे रेपो क्लोन करने और पर्यावरण को स्थापित करने के लिए एक नए देव की आवश्यकता होती है, तो सिस्टम को कार्य करने के लिए क्या मौजूद होना चाहिए?

— 23

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

— मथायस ज़ीस

Answer 5

मेरी राय बनाने और संपादन विशेषताओं, श्रेणियों, उत्पादों, मूल्य नियमों का "तैनाती रणनीति" से कोई लेना-देना नहीं है, ये सभी वस्तुएं एक दुकान के लिए बहुत अनोखी हैं, और ज्यादातर मामलों में उत्पादों के विश्लेषण और अनुसंधान का एक उचित सा मांग करते हैं बेचने जा रहे हैं।

यदि आप अपने द्वारा उल्लिखित सभी तत्वों के समान कॉन्फ़िगरेशन के साथ "एक आकार सभी फिट बैठता है" दुकानों का निर्माण कर रहे हैं, तो आप अपने डेटाबेस की एक "स्नैपशॉट" निर्यात कर सकते हैं, जब आप हर दुकान के लिए आवश्यक सभी सेटअप कर चुके होते हैं।

Comments

नहीं, "एक आकार सभी फिट बैठता है" यह बात नहीं है; यह वही स्थिति है जब हम डेवलपर्स के रूप में आते हैं, जब देव टीम के किसी अन्य सदस्य के साथ हमारे स्रोत कोड को मर्ज करने का समय आता है: उस मामले में हमारे पास स्रोत नियंत्रण प्रणालियां होती हैं जो जादू करती हैं। मेरा प्रश्न "नॉन डेव" चीजों को मर्ज करने के अवसर से संबंधित था जैसे कि कॉन्फ़िगरेशन सेटिंग्स और विशिष्ट व्यवस्थापक सेटिंग्स और प्रविष्टियां।

— एलेसेंड्रो रोंची

आह ठीक है, कि यह और अधिक स्पष्ट करता है

— रटगर

मान लें कि हम एक पूरी नई वेबसाइट बना रहे हैं, इसलिए पुराने डेटा आदि के साथ कोई समस्या नहीं है। लगभग हर समय हमारे सभी देवता एक ही डेटाबेस को विकसित करने के लिए उपयोग करते हैं। यह बहुत सारी समस्याओं का हल करता है। अन्य मामलों के लिए मेरे पास किसी भी तरह के रोडमैप / पटकथा में आवश्यक सभी चरणों को लिखने से बेहतर समाधान (अभी तक) नहीं है और विलय के बाद उन सभी को फिर से तैयार करना। यदि केवल एक व्यक्ति "magento कोर" व्यवस्थापक सेटिंग्स के लिए जिम्मेदार है, तो ये कई चरणों में नहीं होना चाहिए। मैं एक बार यह पाया, लेकिन यह कभी नहीं की कोशिश की है smallbrick.com/magento-modules/admin-tools/…

— Rutger

Answer 6

मैं दो उत्कृष्ट समय-बचत उपकरण जोड़ना चाहूंगा:

• विकास के लिए: मैजिकटेल प्लगइन के साथ PhpStorm IDE
• तैनाती के लिए: Magentify , Magento के लिए एक Capistrano नुस्खा

Comments

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

— एलेसेंड्रो रोंची