गिट + ड्रूपल वर्कफ़्लो

Question

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

1. एक दोस्त ने एक बार मुझसे कहा कि यह सबसे अच्छा स्थानीय होस्ट पर कि बल्कि लाइव सर्वर पर काम करने के लिए था पर्यावरण विशिष्ट समस्याओं में घिर गए बचने के लिए। यह सच?

2. मैं अपने सभी Drupal साइटों के लिए एक ही आधार विषय का उपयोग करता हूं। जब मैं एक में परिवर्तन करता हूं, तो मुझे वर्तमान में इसे लगभग 10 अन्य स्थानों पर कॉपी और पेस्ट करने की आवश्यकता होती है। क्या इस आधार विषय को एक ही स्थान पर रखने का कोई तरीका है और अन्य साइटें इससे आकर्षित होती हैं? शायद गितब?

3. यदि मैं कोडबेस और डेटाबेस का 'पूर्ण' बैकअप करना चाहता हूं - ऐसा करने का एकमात्र तरीका डेटाबेस को एसक्यूएल फ़ाइल के रूप में निर्यात करना और पूरी चीज करना है?

सहायता के लिए धन्यवाद!

टेरी

Answer 1

1. सामान्य तौर पर, आप एक सर्वर के रूप में संभव के रूप में उत्पादन सर्वर के करीब है, लेकिन न कि वास्तविक लाइव सर्वर पर परीक्षण चलाने के रूप में है कि परीक्षण के दौरान एक जीवित साइट निकाल लेंगे चाहिए। चूंकि ड्रूपल को विभिन्न सर्वरों पर अच्छी तरह से चलाने के लिए डिज़ाइन किया गया है, समान सर्वरों का उपयोग करना उतना प्रासंगिक नहीं है।

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

3. डेटाबेस में इतनी अधिक कॉन्फ़िगरेशन जानकारी संग्रहीत करने और सिंक किए जाने के लिए ड्रूपल का कोई अच्छा समाधान नहीं है। अपने पूरे डेटाबेस को सिंक करना एक दृष्टिकोण है। कई मॉड्यूल में निर्यातक भी होते हैं, जो मूल रूप से डेटाबेस से डेटा को कोड में सहेजते हैं ताकि आप इसे अपने शेष कोड के साथ सिंक कर सकें। Features शायद निर्यात करने योग्य मॉडल के साथ प्रयोग करने का सबसे आसान तरीका है और देखें कि यह आपके लिए काम करता है या नहीं।

Answer 2

1. मैं अपने दोस्त के दृष्टिकोण समझते हैं, लेकिन मुझे पूरा एक उत्पादन सर्वर पर टूट विकास कोड चलाने (शायद संभावित, अरे,) से असहमत हैं। बेहतर, वर्चुअलबॉक्स डाउनलोड करें और उसी कॉन्फ़िगरेशन के साथ एक वीएम सेट करें जिस सर्वर पर आप तैनात हैं। आपके द्वारा तैनात प्रत्येक संस्करण के लिए "टैग" बनाने के लिए गिट का उपयोग करें ताकि आपके पास अपनी वेबसाइट के "संस्करण" के लिए उपयोगी संदर्भ बिंदु हो।
2. "गिट submodules" पर देखो। आपको लगभग यह जानने की ज़रूरत है कि ये क्या हैं, लेकिन यदि आप एक विवर्तन पृष्ठभूमि से आए हैं तो आप शायद उन्हें बहुत भ्रमित कर पाएंगे। सबमोड्यूल मूल रूप से अन्य भंडारों के संदर्भ हैं, इसलिए आपके मुख्य प्रोजेक्ट के अंदर किसी अन्य प्रोजेक्ट के लिए सॉफ्ट-लिंक है। हालांकि उन्हें निर्देशिका में आत्मनिर्भर होना है।
3. मैं व्यक्तिगत रूप से एक स्कीमा.sql फ़ाइल को अपने भंडार में रखना चाहता हूं (केवल एक खाली स्कीमा, जो एसक्यूएल में लिखा गया है) लेकिन मुझे नहीं लगता कि भंडार में अपना पूरा डेटाबेस बैकअप रखना एक बुद्धिमान बात होगी, भले ही आप ऐसा कर सकते हैं। उनको अलग रखें।

यदि आप संस्करण नियंत्रण प्रणाली के पूरे विचार के लिए नए हैं, तो आप शायद दोनों पैरों के साथ कूदने से बेहतर हो सकते हैं। जब आप जाते हैं तो यह सब समझने लगेगा। और निश्चित रूप से, अपनी प्रकृति से आप किसी भी स्थायी क्षति की संभावना नहीं है क्योंकि आप आगे और पीछे रोल कर सकते हैं।

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

Answer 3

एक Drupal db नियमित रूप से डंपिंग के लिए मैं का उपयोग

क) "db" नाम की एक रिक्त, असंबद्ध शाखा बनाने के लिए एक Git उर्फ ​​ पर http://gist.github.com/360294

ख उर्फ ​​लगता है) खाली करने के लिए महान मातकिट टूल्स का उपयोग करके निम्नलिखित आदेशों का पालन करें, कुछ अनिच्छुक तालिकाओं और अलग-अलग फ़ाइलों में डीबी को डंप करें, टिप्पणियों के बिना

mk-find DBNAME --tbllike "cache%" --exec "TRUNCATE %D.%N"; 
mk-find DBNAME --tbllike "watchdog" --exec "TRUNCATE %D.%N"; 
git checkout db && \ 
cd /GITROOT/db && rm -rf * && \ 
mk-parallel-dump -d DBNAME -- mysqldump --skip-extended-insert --skip-comments --skip-lock-tables '%D' '%N' \> '%N.sql' 

Answer 4

1. सामान्य रूप से, आपके वातावरण एक-दूसरे के करीब बेहतर होते हैं। मुद्दों का निदान और ट्रैक करने का प्रयास करते समय यह विशेष रूप से महत्वपूर्ण हो जाता है। ऐसा नहीं है कि आपके प्रत्येक वातावरण (देव, क्यूए, प्रोड, इत्यादि) में अलग-अलग सेटअप होना संभव नहीं है लेकिन मैं निश्चित रूप से कहूंगा कि यदि संभव हो तो यह सुसंगत होना बेहतर है।

2. किसी साझा विषय के लिए गिट रिपॉजिटरी सेट करना आपके परिवर्तनों को कॉपी/पेस्ट करने के साथ विरासत के मुद्दों को हटाने का एक अच्छा विचार है। चाहे आप अपने सर्वर पर गिट रिपॉजिटरी सेट अप करें या जीथब जैसी सेवा का उपयोग करना व्यक्तिगत वरीयता का मामला है।

3. हां, बैकअप में बिल्कुल सबकुछ प्राप्त करने के लिए आपको अपने कोड भंडार के अलावा डेटाबेस का एक sqldump करने की आवश्यकता है। कहा जा रहा है, Features मॉड्यूल का उदार उपयोग करें और जितना संभव हो सके कोड में अपनी अधिकांश कॉन्फ़िगरेशन प्राप्त करें। यह पर्यावरण के बीच आगे बढ़ने के साथ-साथ आपके शेष कोड के साथ आपके परिवर्तनों के संस्करणों को ट्रैक करने में सक्षम होने में भी मदद करता है। सबसे महत्वपूर्ण वस्तुओं में से कुछ अपने सुविधाओं को जोड़ने के लिए सामग्री प्रकार, विचार, अनुमतियाँ, चर (Strongarm के माध्यम से), ब्लॉक प्लेसमेंट (Context के माध्यम से), जबाब स्कॉट के लिए मेनू आदि