देव -> चरण -> उत्पादन से माइग्रेट (सीएमआई) विन्यास के लिए सुझाए गए वर्कफ़्लो क्या है?

Question

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

कमरे में हम सबसे अच्छी तरह से पता लगाने में सक्षम थे (DrupalCon पोर्टलैंड में प्रस्तुति के आधार पर आंशिक रूप से):

• सक्रिय कॉन्फ़िगरेशन निर्देशिका को अनदेखा करने के लिए संस्करण नियंत्रण बताएं।
• स्टेजिंग निर्देशिका और संस्करण नियंत्रण के लिए प्रतिबद्ध सभी कॉन्फ़िगरेशन को कॉपी करें।

और 2 वातावरण के बीच सक्रिय / मंचन निर्देशिका को उलटने के लिए settings.php का उपयोग करें। हालाँकि, एक सर्वर से दूसरे परिनियोजन वर्कफ़्लो का पता लगाना जटिल था, लेकिन उल्लेखनीय है, कई स्थानीय परिवेशों (यानी कई डेवलपर्स) से (या एक दूसरे के बीच) में सुझाए गए वर्कफ़्लो क्या है - एक संभावित मुद्दा हर टीम का सदस्य होगा समान या समान वातावरण साझा करना होगा ताकि टीम के साथी की मशीन पर बदलाव कैसे आए?

Comments

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

— mpdonadio

सहमत, यह बहुत अच्छा सवाल है। मेरा मानना ​​है कि महत्वपूर्ण कार्य drupal.org/node/1703168 इस और अन्य विषयों के बारे में है और अभी तक पूरी तरह से हल नहीं हुआ है, इसलिए यहां एक उत्तर उस मुद्दे को आगे बढ़ाने में मदद कर सकता है।

— बर्दिर

अगर मेरा सवाल सीएमआई पहल (जो मेरा इरादा नहीं था) के प्रति नकारात्मक होने के कारण माफी मांगता हूं। मैंने प्रश्न को अपडेट किया है इसलिए यह अधिक तटस्थ लगता है।

— btmash

मैं लगभग यह कहने जा रहा था कि "क्या आपने सुविधाओं की कोशिश की है"। शायद सवाल शीर्षक में "डी 8" जाना चाहिए? "8" टैग थोड़ा अदृश्य है।

— 13

शीर्षक को संशोधित किया गया है, इसलिए प्रश्न को टैग या शीर्षक के माध्यम से देखा जा सकता है :)

— btmash

Answer 1

CMI अनुरक्षकों के साथ थोड़ी बात करने के बाद, सबसे अच्छा तरीका क्या है पर चर्चा समाप्त नहीं हुई है, लेकिन निम्नलिखित वह है जो इस समय सबसे अधिक समझ में आता है।

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

तो, पहले, तथ्य ...

• जैसा कि पहले ही उल्लेख किया गया है, सक्रिय और मंचन निर्देशिका है। सक्रिय को पूरी तरह से Drupal द्वारा प्रबंधित किया जाता है, वहां सीधे परिवर्तन करना (किसी अलग स्थान पर स्विच करके प्रत्यक्ष या अप्रत्यक्ष) समर्थित नहीं है।
• मंचन वह जगह है जहां Drupal आयात और डो के लिए कॉन्फ़िगरेशन की तलाश करता है अन्यथा इसके बारे में परवाह नहीं है।
• आयात प्रक्रिया महत्वपूर्ण है, कॉन्फ़िगरेशन परिवर्तन साइट को एक निश्चित तरीके से प्रभावित कर सकते हैं और वैधता के लिए जाँच की जानी चाहिए। आप टेक्स्ट फ़ील्ड के फ़ील्ड प्रकार को इकाई संदर्भ में नहीं बदल सकते, उदाहरण के लिए, यह सिर्फ काम नहीं करता है।
• कॉन्फ़िगरेशन आयात को हमेशा सभी कॉन्फ़िगरेशन पर चलने की आवश्यकता होती है, आप किसी एकल दृश्य या नोड प्रकार को आयात नहीं कर सकते। यह कोशिश की गई थी, लेकिन निर्भरता, हटाने / नाम बदलने और इतने जटिल प्रणाली के परिणामस्वरूप सामना करने की कोशिश की गई और यह काम नहीं किया।
• डिफ़ॉल्ट कॉन्फ़िगरेशन को फिर से स्थापित करने का एकमात्र तरीका, उस मॉड्यूल को फिर से स्थापित करना है। जिसका अर्थ है कि यह पहले सभी कॉन्फ़िगरेशन (जैसे फ़ील्ड) को निकालने का प्रयास करेगा । तो यह वास्तव में एक विकल्प नहीं है। अद्यतन कार्यों में मैन्युअल, विशिष्ट परिवर्तन संभव हैं, लेकिन मुझे लगता है कि इसके लिए बहुत कठिन है।
• जैसा कि सुविधाओं के मॉड्यूल का वर्णन है, यह कॉन्फ़िगरेशन की निरंतर तैनाती नहीं, बल्कि पुन: प्रयोज्य कार्यक्षमता प्रदान करने पर केंद्रित होगा। यह वह है जिसे पहली बार में डिजाइन किया गया था।

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

Comments

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

— btmash

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

— बरदीर

ठीक है, अब और भी सवाल (2 टिप्पणियों में विभाजित) :) सबसे पहले, आप मॉड्यूल का उल्लेख कर रहे हैं विन्यास। यहां तक ​​कि अगर एक मॉड्यूल को रेपो में जोड़ा जाता है और सक्षम / अक्षम नहीं किया जाता है, तो इसे बस वहां बैठने के लिए स्थापित / अनइंस्टॉल करना होगा?

— btmash

और फॉलोअप: (ए) क्या सक्रिय निर्देशिका से परिवर्तनों को कॉपी करने के लिए एक तंत्र होगा -> मंचन (इन घटकों के लिए कॉन्फ़िगरेशन निर्देशिका में जा रहे व्यक्ति को सरल बनाने के लिए - संभवतः कुछ चर बनाने के लिए एक तरीका)। (बी) क्या स्टेजिंग निर्देशिका को स्टेजिंग से सिंक किए जाने के बाद खाली कर दिया जाता है -> सक्रिय? (बी १) यदि ऐसा है, तो डेपिट्स की दृष्टि से रणनीति उस निर्देशिका को रीसेट करने के लिए है, जो एक गिट्ट पुल से पहले है? (बी 2) यदि नहीं, तो यह मान लेना सही है कि स्टेजिंग करते समय-> सक्रिय सिंक होता है, कॉन्फ़िगरेशन पर कोई प्रभाव नहीं होना चाहिए जो नहीं बदला है?

— btmash

मॉड्यूल इंस्टॉलेशन स्थिति कॉन्फ़िगरेशन है। मॉड्यूल ही नहीं :) यह वही है जो आप तैनात करते हैं। क) सक्रिय निर्देशिका के एक tar.gz को डाउनलोड करने के लिए एक यूआई है, एक ने कहा कि टारिंग निर्देशिका में tar.gz अपलोड करें और एक वास्तव में आयात, अवलोकन और परिवर्तनों के अंतर के साथ करना है। बी) मेरा मानना ​​है कि अभी इसे खाली कर दिया गया है, लेकिन मुझे लगता है कि आप इसे आसानी से वापस ले सकते हैं। यकीन नहीं होता, जांचना आसान है। वह सब सामान प्लग करने योग्य है, इसलिए थोड़ा अलग कार्यान्वयन हो सकता है जो नष्ट नहीं करता है। बी 2) मुझे यह नहीं मिलता है लेकिन मुझे लगता है कि हाँ।

— बेरदीर

Answer 2

अब तक महान जवाब दिया। आप सब का धन्यवाद!

हमने हाल ही में एक Drupal 8 परियोजना शुरू की और निम्नलिखित वर्कफ़्लो को लागू किया।

हमारे पास तीन फ़ोल्डर्स सक्रिय हैं, मचान और निर्यात करते हैं। डेवलपर्स ने निर्यात करने के लिए डंप किया। मैं इसे स्टेजिंग में नहीं रखना चाहता। मुझे लगता है कि जब साझा कॉन्फ़िगरेशन सीधे मंचन फ़ोल्डर में संग्रहीत नहीं होता है, तो इसके साथ काम करना आसान होता है। यह सिर्फ एक मैं इस पर कोई मुश्किल तथ्य है ...

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

• परियोजना का खाका: https://github.com/webflo/d8-project-template
• अतिरिक्त ड्रश कमांड: https://github.com/webflo/d8-project-template/blob/master/public/drush/cmi.drush.inc

Comments

अब तक, मैं इस दृष्टिकोण से सहमत हूं। मैंने इस पोस्ट के लिंक से लेकर Drush config-export और config-import कमांड्स तक सभी सुविधाएँ जोड़ी हैं। मुझे उम्मीद है कि अन्य लोग इस 3 निर्देशिका समाधान की खोज में मेरे और @florian के साथ जुड़ेंगे।

— मोशे वेत्ज़मैन

आप sites/default/files/config_HASHएक हैश प्रत्यय वाले कॉन्फ़िगर फ़ोल्डर से कैसे निपटते हैं, उदाहरण के लिए config_wNOLcmycPFZCrXJ9wis9dCdSR4lpYILdBsFxSWuK5Hzhdr

— therobyouknow

@therobyouknow इन फ़ोल्डरों के स्थान को ओवरराइड करना संभव है। बस "साइट कॉन्फ़िगरेशन फ़ाइलों का स्थान" देखें। settings.php में मैं निम्नलिखित स्निपेट का उपयोग करता हूं। इसका मतलब है, यह विन्यास Drupals root dir के बाहर संग्रहीत है। $ config_directories = सरणी ('सक्रिय' => '../config/active', 'मंचन' => '../config/staging');

— वेबफ्लो

धन्यवाद @webflo मैंने यह देखा। एक कोड आधार और एक विन्यास को अलग से प्रबंधित करने से क्या लाभ होगा? मुझे लगता है कि यह अलगाव थोड़ा कृत्रिम है क्योंकि दोनों कोड और कॉन्फ़िगरेशन (याम्ल में) व्यवहार को निर्धारित करते हैं और एक दूसरे पर निर्भर हैं। Drupal 7 में, कॉन्फ़िगरेशन-इन-कोड (या Git द्वारा ट्रैक करने योग्य) सुविधाओं के साथ किया गया था जिसमें प्रत्येक विशेष कॉन्फ़िगरेशन के लिए एक मॉड्यूल बनाया गया था जिसे कोड में ट्रैक करना आवश्यक था। Drupal 8 में, फीचर्स 3.x है जो जैसा कि मैं इसे समझता हूं, वही करता है लेकिन कॉन्फ़िगरेशन को स्टोर करने के लिए YAML का उपयोग करता है और उत्पन्न मॉड्यूल फ़ीचर मॉड्यूल पर निर्भर नहीं होते हैं।

— इसके बाद

मुझे लगता है कि आपने मुझे गलत समझा, कॉन्फिग डाइर अभी भी गिट में है, लेकिन मेरा ड्रुपल साइट गिट रेपो रूट में नहीं है। साइट संग्रहीत / वेब है। इसलिए / कॉन्फिग और / वेब एक ही स्तर पर हैं।

— वेबफ्लो

Answer 3

मैंने अभी तक यह कोशिश नहीं की है, लेकिन मेरी योजना एक कस्टम मॉड्यूल बनाने की है जिसमें "डिफ़ॉल्ट" कॉन्फ़िगर फाइलें हैं, जिनमें केवल उस कॉन्फ़िगरेशन की परवाह है जिसकी मुझे परवाह है। मेरा मानना ​​है कि अन्य मॉड्यूल में अन्य मॉड्यूल को ओवरराइड करने वाले कॉन्फ़िगरेशन हो सकते हैं। (यदि यह संभव नहीं किया जाना चाहिए)।

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

कस्टम मॉड्यूल में कॉन्फिगर करना इसे आपके मुख्य कोडबेस का हिस्सा बनाता है।

तैनाती प्रक्रिया होगी:

1. नई फाइलें प्राप्त करने के लिए पुल या जो कुछ भी हो।
2. साफ कैश।
3. डिफ़ॉल्ट कॉन्फ़िगरेशन रीसेट करें। (आपके कस्टम मॉड्यूल की फ़ाइलों से)

यदि आप चाहें तो आप प्रत्येक वातावरण के लिए कस्टम मॉड्यूल बना सकते हैं (यह स्वयं का कॉन्फ़िगरेशन है)।

Comments

यह सुविधाओं की तरह एक महान सौदा लगता है, है ना? या क्या कोई महत्वपूर्ण अंतर है जो मुझे याद आ रहा है?

— लेटेरियन

इसका एक दिलचस्प तरीका है और मुझे यह विचार पसंद आया। हालांकि, सीएमआई पहल के हिस्से के रूप में उल्लिखित सबसे बड़े लाभों में से एक कॉन्फ़िगरेशन निर्देशिकाओं से कॉन्फ़िगरेशन को स्थानांतरित करने की क्षमता है। और जो मैं देख रहा हूं, उसमें से settings.php फ़ाइल आपको यह निर्धारित करने की अनुमति देती है कि सक्रिय / मंचन निर्देशिकाएं कहां हैं (यानी उन्हें ऑटो-जनरेटेड पथ होने की आवश्यकता नहीं है)। इसलिए, मुझे लगता है कि @Letharion उल्लेख के रूप में एक सुविधा बनाने की आवश्यकता के बिना वर्तमान कॉन्फिग के साथ एक वर्कफ़्लो संभव होना चाहिए।

— btmash

Answer 4

नोट: मैं सराहना करता हूं कि यह प्रश्न के संबंध में सबसे सख्त अर्थों में एक उत्तर नहीं है, लेकिन मैंने इसे यहां वैसे भी रखा है और एक बार 8.x रिलीज होने और धूल होने पर मैं इसे फिर से संपादित / हटा दूंगा थोड़ा और बस गया। यह सिर्फ एक टिप्पणी के लिए बहुत बड़ा था और मैं अपना £ 0.02 :-) में लेना चाहता था

फीचर्स के एक बड़े प्रशंसक के रूप में , मेरा सुझाव है कि फीचर्स मॉड्यूल के डी 8 अवतार पर नजर रखें ।

प्रोजेक्ट पेज से लिया गया

नई कॉन्फ़िगरेशन प्रबंधन प्रणाली के साथ एकीकृत करने के लिए Drupal 8 के लिए 3.x संस्करण की योजना बनाई गई है। यदि आपको केवल सरल साइट कॉन्फ़िगरेशन को निर्यात करने की आवश्यकता है, तो डी 8 कॉन्फ़िगरेशन प्रबंधन प्रणाली का उपयोग सुविधाओं के बजाय किया जाना चाहिए। आप बंडल कार्यक्षमता (जैसे "फोटो गैलरी सुविधा") निर्यात करने के लिए D8 में सुविधाओं का उपयोग करेंगे।

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

मैं मदद नहीं कर सकता, लेकिन हाँ सोचता हूँ, CMI कमाल है; लेकिन मेरी अधिकांश साइटें अभी भी फ़ीचर मॉड्यूल के साथ समाप्त हो जाएंगी (भले ही कम मात्रा में हर तरह की सामग्री, अनुमति आदि का निर्यात न करने के कारण)

Comments

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

— btmash

... डी 7 सुविधाओं की तैनाती प्रक्रिया में डेटाबेस में डेटास्टोर और फाइलों में डेटास्टोर शामिल है। हम दोनों फाइलों में बदल रहे हैं और यह सुनिश्चित करने की आवश्यकता है कि वर्कफ़्लो में बदलाव को कैसे प्रभावित किया जाए।

— btmash

ध्यान दें कि सुविधाओं में वास्तव में सक्रिय और डेटास्टोर / स्टेजिंग की अवधारणा नहीं है। या कम से कम सुसंगत नहीं है, यह सब विशिष्ट हुक / चीज पर निर्भर करता है जो इसके साथ एकीकृत है। डिफ़ॉल्ट दृश्य कोड में रहते हैं, उदाहरण के लिए, परिवर्तन तुरंत सक्रिय होते हैं (कैशिंग के अलावा), सुविधाओं के साथ कोई नियंत्रित परिनियोजन प्रक्रिया नहीं है। हमेशा तैनाती के लिए सुविधाओं का उपयोग करते समय एक बड़ी समस्या रही है।

— बेर्डिर

आप सही हे। मुझे नहीं पता कि मुझे D7 के लिए कॉन्फ़िगरेशन मॉड्यूल कैसे मिला, जो कि फीचर्स के साथ मिश्रित थे, लेकिन मैंने किया।

— btmash