VCS के अंतर्गत Magento 2 परियोजना की पसंदीदा संरचना क्या है?

Question

जब मैं एक नया M2 प्रोजेक्ट शुरू करता हूं, तो पहली चीज जो मैं करता हूं, वह है संगीतकार के माध्यम से कोर इंस्टॉल करना:

composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition

मैं अब अपने कस्टम मॉड्यूल (एस) और थीम (एस) के तहत लिख सकता हूं app/code। फिर मैं अपने composer.*और पूरे app/codeफ़ोल्डर को अपने VCS में जोड़ दूंगा । अब तक सब ठीक है।

मान लीजिए कि अब मैं अपने प्रोजेक्ट के लिए कुछ बिल्ड टूल्स का उपयोग करना चाहता हूं, आइए ग्रंट या गल्प कहते हैं।

1. यदि मैं अपना खुद का अपराध करता हूं Gruntfile.js, magento/magento2-baseतो जब मैं composer installरेपो क्लोन करता हूं , तो यह पैकेज द्वारा ओवरराइट किया जाएगा ।

2. यदि मैं अपना वचन देता हूं gulpfile.js, तो मैं वास्तव में अपनी निर्भरता को एक में परिभाषित नहीं कर सकता package.json, क्योंकि यह भी अधिलेखित हो जाएगा magento/magento2-base।

3. अगर मैं Magento के ग्रंट सेटअप का उपयोग करने का निर्णय लेता हूं और फ़ाइलों को संपादित करके इसे अनुकूलित करना चाहता हूं /dev/tools/grunt(उदाहरण के लिए themes.js), तो मैं नहीं कर सकता क्योंकि मेरे बदलावों को अधिलेखित कर दिया जाएगा magento/magento2-base।

मेरी समझ यह है कि आप वास्तव में अपने दस्तावेज़ रूट में बहुत कुछ नहीं कर सकते। इस समस्या के बहुत सारे समाधान हैं:

• मैं git checkout -अपनी फ़ाइलों को रीसेट करने के लिए स्थापना के बाद एक सही चला सकता हूं
• मैं अपनी निर्मित फ़ाइलों को एक समर्पित फ़ोल्डर में संग्रहीत कर सकता हूं, /buildउदाहरण के लिए
• मैं एक अलग बिल्ड टूल का उपयोग कर सकता था, जैसे कि फ़िंग, एंट, या रेक (मेरे फ्रंटेंड देवता हालांकि इतने खुश नहीं होंगे)
• मैं magento/magento2-baseएक कस्टम पैकेज के साथ बदल सकता हूं जिसमें कोर फ़ाइलों के लिए एक कस्टम मैपिंग है (वास्तव में इष्टतम नहीं है लेकिन हे, यह एक विकल्प है)

मैं व्यक्तिगत रूप से इन सभी विकल्पों को नापसंद करता हूं, इसलिए मैं जानना चाहूंगा कि क्या मैं जो करने की कोशिश कर रहा हूं उसे प्राप्त करने के लिए एक पसंदीदा या बेहतर तरीका है।

क्या किसी को भी यही समस्या है? आपने इसे कैसे ठीक किया? आप वीसीएस के तहत अपने प्रोजेक्ट को कैसे तैयार करते हैं?

अपडेट करें

प्रोजेक्ट सेटअप से संबंधित एक अतिरिक्त बिंदु। अपने प्रयोगों में मैंने देखा कि मैगेंटो कंपोजर इंस्टॉलर के पास फाइल ओवरराइड करने के लिए एक झंडा है:

"extra": {
    "magento-force": "override"
}

यह आंतरिक रूप से एक बूलियन के रूप में व्यवहार किया जाता है यदि मुझे गलत नहीं लगता है, तो मैंने इसे falseओवरराइडिंग को छोड़ने के लिए सेट करने का प्रयास किया । जब मैं composer installअपना इंस्टॉलेशन चलाता हूं तो फ़ाइल पहले से मौजूद होने के कारण विफल हो जाता है। मूल रूप से, अगर मैंने Magento को अपनी फ़ाइलों को ओवरराइड नहीं करने दिया, तो मैं इसे स्थापित नहीं कर सकता।

इस ध्वज का उद्देश्य क्या है? क्या यह केवल मेरे लिए जाँच करने के लिए माना जाता है? मेरे लिए ईमानदार होने का कोई मतलब नहीं है, लेकिन हो सकता है कि कोई व्यक्ति इस विषय पर कुछ प्रकाश डाल सके।

Comments

मैं यह देखने के लिए उत्सुक हूं कि अन्य लोग उत्तर के रूप में क्या पोस्ट करते हैं। आदर्श रूप से, मुझे लगता है कि हम Magento Core को अपने मुख्य रेपो से बाहर रखना चाहते हैं और इसे केवल हमारे द्वारा बनाए गए टेम्पलेट तक ही सीमित रखते हैं और जो भी कस्टम प्लगिन हम जोड़ते हैं या सही करते हैं। फिर बिल्ड समय पर, हम कोर + हमारे प्रोजेक्ट रेपो का संदर्भ देते हैं और रिपॉजिटरी से एक एप्लिकेशन आर्टिफ़िकेशन बनाते हैं। यह वह विधि है जिसका उपयोग मैं हाल ही में M1 के लिए कर रहा हूं और मुझे आश्चर्य हो रहा है कि क्या Magento की आधिकारिक सिफारिश M2 के साथ भी कुछ ऐसा ही कर रही है कि संगीतकार पूरी तरह से समर्थित है।

— ब्रायन 'बीजे' हॉफपॉयर जूनियर

नए M2 संस्करणों में Gruntfile.js, gulpfile.jsऔर package.jsonसमस्या हल हो गई है। इस प्रश्न में संबोधित समस्या अभी भी नए Magento के 2 संस्करणों पर लागू होती है जब आपको बदलने की आवश्यकता होती है themes.js, index.phpया .htaccessउदाहरण के लिए।

— 7ochem

Answer 1

संक्षिप्त शब्द, हम अलग-अलग फ़ाइलों को देख रहे हैं जिन्हें अनुकूलन की आवश्यकता है। उदाहरण के लिए, यदि लोगों को index.php को संशोधित करने की आवश्यकता है, तो स्थानीय कस्टमाइज़ेशन की आवश्यकता से मानक फ़ाइल मैगनेटो जहाजों को अलग करने का तरीका जानें। एक बार हासिल करने के बाद, "सभी परियोजनाओं के लिए एक सच्चा .gitignore उपयोग कर सकते हैं" होना संभव है। यह है कि, "कंपोज़र इंस्‍टॉल" आपके लिए (और इंस्‍टॉल सब कुछ "कंपोज़र अपडेट" पैच या अपग्रेड इंस्‍टॉल करते समय सब कुछ बदल देगा)।

लंबे समय तक, लक्ष्य को .ignignore को कम से कम करना है। उदाहरण के लिए 'विक्रेता' निर्देशिका के तहत मॉड्यूल में अधिक धक्का।

फिर

1. उन सभी चीज़ों के लिए जिन्हें आप परियोजनाओं में साझा नहीं करना चाहते हैं, इसे ऐप / कोड के तहत छोड़ दें और मुख्य प्रोजेक्ट रेपो में प्रतिबद्ध रहें।
2. सब कुछ स्थानीय रूप से विकसित है जिसे आप परियोजनाओं में अधिक आसानी से साझा करना चाहते हैं, एक अलग जीआईटी रेपो में डाल सकते हैं और संगीतकार के माध्यम से स्थापित कर सकते हैं ताकि यह 'विक्रेता' के तहत समाप्त हो जाए। (स्थानीय संगीतकार रेपो हो सकता है, या जीआईटी से सीधे इंस्टॉल कर सकता है।)

इस तरह से आप अभी भी पूरी परियोजना के पेड़ को ऊपर से नीचे कर सकते हैं, कंपोजर.जॉन और कंपोजर फाइल को कैप्चर कर सकते हैं (केवल ऐप / कोड नहीं करता है)। .Gitignore 'विक्रेता' निर्देशिका और अन्य फ़ाइलों को नहीं चाहता था को बाहर कर देगा।

यह आपको अन्य चर्चा में उल्लिखित दोनों दुनियाओं का सबसे अच्छा मौका देता है। वर्तमान दर्द .itignore फ़ाइल की लंबाई और जटिलता है, और पैच इंस्टॉलेशन वर्तमान में कुछ स्थानीय अनुकूलन (जैसे index.php) में मिटा देता है। शॉर्ट टर्म वर्कअराउंड - .ignignore से index.php को हटा दें, और जब आप एक पैच चेक स्थापित करते हैं तो देखें कि आपके द्वारा खोए गए परिवर्तन क्या हैं (यह अलग है) और उन्हें मैन्युअल रूप से पुन: लागू करें।

Comments

ठीक है, तो आप निकट भविष्य में कुछ चीजों को बदल देंगे, अच्छा! मुझे आश्चर्य है कि क्या यह "magento-force": "override"ध्वज किसी तरह उपयोगी हो सकता है। फिलहाल यह वैसा नहीं है जैसा मैं उम्मीद करूंगा। यदि आपने अपनी index.phpया अन्य "कोर" फाइलों को संपादित / विस्तारित किया है , तो आप बस Magento को बता सकते हैं कि वह आपके परिवर्तनों को अधिलेखित नहीं कर सकती। क्या इसका कोई अर्थ बनता है?

— fmrng

Answer 2

आपके ओवरराइड की समस्या के लिए एक आसान समाधान है: कोर फाइलें न बदलें;) Magento कोड का विस्तार करने और इसे नहीं बदलने पर आधारित है।

पहली बात यह है कि, आपको अपना पूरा ऐप / कोड फ़ोल्डर एक vcs रिपॉजिटरी में नहीं रखना चाहिए। प्रत्येक Magento घटक (मॉड्यूल, थीम, आदि ...) एक भंडार ही होना चाहिए।

यदि आप फ्रंटेंड को बदलना / विस्तारित करना चाहते हैं, तो आपको एक नया विषय बनाना चाहिए और इस विषय को अपने ग्रंट प्रोजेक्ट के रूप में समझना चाहिए, न कि पूरे Magento2 इंस्टेंस को।

अपनी परियोजना में अपने विषय को स्थापित करने के लिए आप आसानी से इसे सीधे अपने vcs भंडार से संगीतकार के माध्यम से खींच सकते हैं

Comments

खैर, app/codeफ़ोल्डर विशेष रूप से Magento को अनुकूलित करने के लिए है। वर्तमान एम 2 के बारे में मेरी समझ यह है कि एम 1 में app/codeक्या app/code/localथा, इसकी जगह है , और सामुदायिक मॉड्यूल के तहत संगीतकार के माध्यम से स्थापित किया जा सकता है vendor। हमारे पास मॉड्यूल की एक बड़ी संख्या के साथ कुछ परियोजनाएं हैं, और कई थीम भी हैं। आप जो सुझाव दे रहे हैं, उसे प्रबंधित करना असंभव होगा।

— fmrng

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

— मैगेंटो

यदि आप अपने वर्तमान सेटअप से खुश हैं तो यह ठीक है। ईमानदारी से कहूं तो मुझे यह बोझिल लगता है। इसका मतलब है कि आपके पास 100+ git रिपॉजिटरी है, और हर बार जब आप कुछ बदल रहे होते हैं, तो आपको एक विशिष्ट प्रोजेक्ट खोलना होता है, अपने बदलावों को कम करना होता है composer update। तुम composer.lockफिर अपना अपराध कहां करते हो ? यदि आपके पास एक ही प्रोजेक्ट पर काम करने वाले 10+ देव हैं, तो यह वास्तव में गड़बड़ हो सकता है। बेशक हमारे पास बहुत सारे सामान्य मॉड्यूल हैं (और यहां तक ​​कि थीम) जो हम संगीतकार के माध्यम से स्थापित करते हैं, लेकिन परियोजना-विशिष्ट कोड को स्पष्टता के लिए उसी रेपो के तहत संस्करणित किया जाना चाहिए।

— fmrng

मैं यह नहीं कह रहा हूं कि आप इसे गलत कर रहे हैं, मुझे लगता है कि यह मेरे स्वाद के लिए थोड़ा अधिक है। ब्याज से बाहर, आप इस तरह के एक सेटअप के साथ अपने रेपो इतिहास का निरीक्षण कैसे करते हैं? कैसे आप जैसी सुविधाओं का उपयोग कर सकते git blameया git logजब कोड को कई घटकों में बिखरे हुए है? क्या आप यह देखने के लिए एकीकरण परीक्षण चलाते हैं कि सब कुछ ठीक चल रहा है?

— १m

हमने पिछले साल आंतरिक रूप से यह चर्चा की थी और तैनाती को सरल बना दिया था क्योंकि हमने इसे 1repo = 1module बनाने का निर्णय लिया था। मुद्दा यह है कि आप एक छोटे से बदलाव के लिए संगीतकार अपडेट नहीं करेंगे। डेवलपर्स देव वातावरणों में काम करते हैं और वहां फाइलों को सीधे बदल देते हैं। जब वे किए जाते हैं, तो वे इसे अल्फा, बीटा या रिलीज़ उम्मीदवार के रूप में टैग कर सकते हैं। इस तरह, कई डेवलपर्स एक ही समय में कई परियोजनाओं पर काम कर सकते हैं और अगली बार, आप सभी परिवर्तनों में एक संगीतकार अपडेट करते हैं जिसे आप खींचते हैं। आपके vcs और कंपोज़र पैकेज को व्यवस्थित करने के लिए बढ़िया उपकरण हैं।

— सैकड़ों रिपोज़िटरीज की

Answer 3

ठीक है, ऐसा लगता है कि मैंने जो हासिल करने की कोशिश की थी, उसके लिए एक बेहतर समाधान मिला। में composer.json, यह निर्दिष्ट करना संभव है कि मैगेंटो कम्पोज़र इंस्टॉलर द्वारा किन फ़ाइलों को अनदेखा किया जाना चाहिए। यदि मैं नहीं चाहता कि मेरा Gruntfile.jsओवरराइड हो जाए, तो मैं इसे निम्नलिखित कॉन्फ़िगरेशन के साथ निर्दिष्ट कर सकता हूं:

"extra": {
    "magento-deploy-ignore": {
        "magento/magento2-base": [
            "/Gruntfile.js",
            "/package.json"
        ]
    }
}

मैं अब अपनी आवश्यकताओं को पूरा करने के लिए मानक स्थापना का विस्तार करने में सक्षम हूं।

Comments

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

— 7ochem

Answer 4

दुर्भाग्य से स्वीकार किए गए उत्तर, हालांकि मूल रूप से वांछित लक्ष्य को प्राप्त करने का इरादा है, केवल रूट में रखी गई फ़ाइलों और निर्देशिकाओं को बाहर करने के लिए काम करते हैं, क्योंकि यदि हम एक उपनिर्देशिका (जैसे।) में रखी गई फ़ाइल को बाहर करना चाहते हैं dev/tools/grunt/configs/themes.js, अगर हम जोड़ते हैं। नई थीम और मैगेंटो ग्रंट कार्यों का उपयोग करना चाहते हैं), इसे "मैगेंटो-तैनाती-उपेक्षा" कॉन्फ़िगरेशन में डालते हुए, यह सभी मूल निर्देशिकाओं (यानी, देव और इसके सभी उपनिर्देशिकाओं) की तैनाती को अवरुद्ध करता है।

ऐसा इसलिए होता है क्योंकि "Magento-तैनात-अनदेखा" ( \MagentoHackathon\Composer\Magento\Deploystrategy\DeploystrategyAbstract::isDestinationIgnored) का उपयोग strposकरने वाली विधि को बहिष्कृत सूची के विरुद्ध गंतव्य पथ से मिलान करने के लिए उपयोग किया जाता है, इसलिए हर माता-पिता का मार्ग हमेशा सही होगा।

Comments

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

— fmrng

हमने अपनी पाइपलाइन के निर्माण के चरण के दौरान फाइलों का चेकआउट करना शुरू किया, फिर हमने बिल्ट-इन ग्रंट कार्यों का उपयोग करना बंद कर दिया, इसलिए यह समस्या नहीं है।

— जेनरो विएट्री

वैसे, हमने "मैगेंटो-तैनाती-उपेक्षा" व्यवहार को बढ़ाने के लिए कांटा मैगेंटो-संगीतकार-इंस्टॉलर का मूल्यांकन शुरू किया, अगर समस्या को फिर से प्रकट करना चाहिए तो हम इस पथ का अनुसरण कर सकते हैं

— गेन्नारो विएट्री

Answer 5

पैच का उपयोग करना

मैं जो उपयोग कर रहा हूं वह पैच बना रहा है और लागू कर रहा है। जब हमें बदलने की आवश्यकता होती है dev/tools/grunt/configs/themes.js, index.phpया .htaccessहम फ़ाइल की एक अस्थायी प्रतिलिपि में परिवर्तन लागू करते हैं और उसमें से एक पैच बनाते हैं ( build/पहले एक बार बनाएँ ):

$ cp dev/tools/grunt/configs/themes.js dev/tools/grunt/configs/themes.js.tmp
  # Now Make changes in .tmp file
$ diff -u3 dev/tools/grunt/configs/themes.js dev/tools/grunt/configs/themes.js.tmp | sed 's/\.tmp//' > build/themes.patch
$ mv dev/tools/grunt/configs/themes.js.tmp dev/tools/grunt/configs/themes.js

तब हम इस पैच को स्वचालित रूप से लागू कर सकते हैं जब चल रहा है composer installया अपनी फ़ाइल updateके scriptsअनुभाग में ते आदेश जोड़कर composer.json:

{
    "scripts": {
        "post-install-cmd": "patch -i build/themes.patch dev/tools/grunt/configs/themes.js",
        "post-update-cmd": "patch -i build/themes.patch dev/tools/grunt/configs/themes.js"
    }
}

(इसके अलावा आप उक्त patch ...कमांड को बैश स्क्रिप्ट में रख सकते हैं , आइए build/themes_patch.shउस स्क्रिप्ट को संगीतकार से कहते हैं और इसे पुन: प्रयोज्य या मैन्युअल रूप से निष्पादित किया जाएगा)

सुरक्षित अपग्रेड करें! : डी

यह समाधान सुरक्षित अपग्रेड है! आप मूल फ़ाइल का सम्मान किए बिना सीधे कोर फ़ाइलों को नहीं बदल रहे हैं। आप मूल Magento2 फ़ाइल में एक पैच लागू कर रहे हैं। जब वह फ़ाइल बदल जाती है क्योंकि आप उन्नयन कर रहे हैं, तो पैच विफल हो जाएगा और आप जानते हैं कि आपको नए परिवर्तनों पर करीब से नज़र डालनी है और एक नया पैच बनाना है।