एक छोटी वितरित टीम के लिए सबसे अच्छा अभ्यास क्या है जो ड्रूपल परियोजना पर काम करेगा? कुछ शोध के बाद

Question

, हमने अपनी अगली परियोजना पर ड्रूपल के साथ काम करने का विकल्प चुना और हम एक वितरित टीम हैं।

ड्रूपल स्टोर्स (जो हमने अभी तक देखा है, उसके आधार पर) यह डेटाबेस पर मौजूद है, हम एक वितरित टीम के रूप में इस परियोजना पर कैसे काम कर सकते हैं? हमें क्या सर्वोत्तम अभ्यास करना चाहिए?

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

Answer 1

जेरेमी का उत्तर (+1) पहले से ही काफी व्यापक है। कुछ अतिरिक्त व्यावहारिक उन्मुख सलाह में कोई विशेष आदेश में निम्नानुसार है।

अस्वीकरण: यह सामान मेरे लिए काम करता है। दूसरों के पास अन्य सुझाव हो सकता है या असहमत भी हो सकता है। अगर ऐसा होता है तो मैं फीडबैक और वैकल्पिक/बेहतर प्रस्ताव सुनकर बहुत खुश हूं!

1. एक मुद्दा यह है कि हर टीम के सदस्य कोड और डेटाबेस अद्यतन द्वारा उसकी/उसके सत्र शुरू कर देना चाहिए बनाओ। आप ssh और rsync कमांड के संयोजन के साथ आसानी से उन सभी को स्क्रिप्ट कर सकते हैं। मैं कभी-कभी एक स्क्रिप्ट (update-project.sh) बनाता हूं जो भंडार से कोड अपडेट करता है और एक बार में मास्टर सर्वर से नवीनतम डीबी डाउनलोड और आयात करता है।

2. हर बार जब आप कोड अपडेट करते हैं तो http://example.com/update.php पर कॉल करना न भूलें। प्रत्येक स्टेजिंग साइट पर, प्रत्येक प्रतिबद्धता के बाद, और प्रत्येक अपडेट/पुल/चेकआउट के बाद अपनी स्थानीय मशीन पर यह आदेश चलाएं।

3. जीयूआई के बजाए एसक्यूएल क्वेरी के माध्यम से डीबी में कोई भी बदलाव करें। इस तरह आपको बस yourmodule.install फ़ाइल में उस क्वेरी को hook_update_N() कार्यान्वयन में लपेटना होगा, और आप सुरक्षित और ध्वनि (यदि आप # 2 इंगित करने के लिए पालन करते हैं!) [कुछ gui टूल आउटपुट समकक्ष ... यह भी आसान है!]।

4. जब भी संभव हो, hook_update_N() में भी मॉड्यूल सेटिंग्स में परिवर्तन शामिल हैं। यह हर समय संभव नहीं है। जब संभव नहीं है: बिंदु # 7 और # 8 देखें।

5. कोई दृश्य बनाते या संशोधित करते समय, इसे समाप्त होने पर फ़ाइल में निर्यात करें। वही सिद्धांत जो # 3 इंगित करता है लेकिन विचारों पर लागू होता है। इस दृष्टिकोण में आकस्मिक रूप से रोलबैक तंत्र प्रदान करने का लाभ भी है यदि आप बाद में महसूस करते हैं कि आपने गलती की है।

6. एक मास्टर रिपोजिटरी का उपयोग करें। एक बहुत अधिक वितरित संस्करण प्रणाली के लिए मत जाओ। अपने कोड को हमेशा उसी केंद्रीय रेपो से खींचें और दबाएं।

7. हमेशा अपनी प्रतिबद्धता में एक टिप्पणी शामिल करें। विशेष रूप से यदि कुछ कोड परिवर्तन कुछ कार्यक्षमता/एपीआई/सामान्य तर्क बदलते हैं, तो अपने प्रतिबद्ध संदेश में चेतावनी शामिल करने के लिए एक बिंदु बनाएं। यदि आवश्यक हो, तो विस्तृत जानकारी changelog.txt फ़ाइल में रखी जा सकती है।

8. काम करते समय, तुरंत मास्टर डीबी पर पुन: पेश करें, किसी भी हाथ से बने डीबी परिवर्तन जो आपने अपने hook_update_N() कार्यान्वयन में शामिल नहीं किया है। यह जरूरी है कि आपकी टीम के सदस्य # 1 में वर्णित जैसे सत्र शुरू करें।

9. जो आपने संस्करण के तहत रखा है उसमें चयन करें। उदाहरण के लिए: sites/default/settings.php को बाहर निकालें लेकिन मूल्यांकन करें कि (यदि कुछ भी है) को sites/default/files (संस्करण के लिए आवश्यक छवियां हैं? और अनुलग्नक?) से संस्करणित करने की आवश्यकता है।

10. कुछ उपयोगी योगदान मॉड्यूल हैं जो मदद कर सकते हैं।import/export की तरह, जो आपको अपने सीसीके और दृश्यों या node export को एक संग्रह में प्रबंधित करने की अनुमति देता है जो आपको नोड्स निर्यात करने की अनुमति देता है और फिर उन्हें किसी अन्य ड्रोपल स्थापना में आयात करता है।

11. बड़े पैमाने पर simpletest module का उपयोग करें। यह अच्छा किसी भी तरह का विचार है, लेकिन टीम में काम करते समय महान विचार: इस तरह से आप सुनिश्चित होंगे कि आपके परिवर्तनों ने किसी और के काम को तोड़ दिया नहीं है।

12. मज़े करो! मुझे टीम में काम करना अच्छा लगता है और मुझे विश्वास है कि हर बार ऐसा करने की कोशिश करनी चाहिए। यह अधिक मजेदार, अधिक सीखने और सब से ऊपर है ... बेहतर कोड!:)

बोनस बिंदु (विशेष रूप से विकास दल का उल्लेख नहीं करता):

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

Answer 2

सबसे पहले, सर्वोत्तम प्रथाओं।

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

आपको अपना कोड साझा करने के लिए एक संस्करण नियंत्रण प्रणाली का उपयोग करना चाहिए, ताकि आप सभी एक ही कोडबेस से काम कर रहे हों लेकिन कोड को मर्ज करने के दौरान नियंत्रण रखें।

डेवलपर्स के बीच डेटाबेस साझा करना, या डेवलपर्स के बीच कोडेबेस साझा करना भ्रम पैदा करेगा और इससे बचा जाना चाहिए।

अब कुछ और राय आधारित विचारों आपकी साइट के लिए

सामग्री बनाया है और लाइव सर्वर पर संपादित किया जाना चाहिए।

आपको कोड को प्रबंधित, दोहराने योग्य तरीके से जारी करना चाहिए। आदर्श रूप से आपके पास लाइव होने से पहले कोड का परीक्षण करने के लिए एक स्टेजिंग सर्वर होना चाहिए।

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

Answer 3

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

कुछ अच्छी समस्या ट्रैकर और/या परियोजना प्रबंधन सॉफ्टवेयर सभी परियोजनाओं को केंद्रीकृत रख सकते हैं और डेवलपर्स के बीच संचार की सुविधा। विकी भी अच्छी है। प्रोजेक्ट मैनेजर्स और व्यक्तिगत डेवलपर्स के बीच ईमेल सभी को लूप में नहीं रखता है और शोर ईमेल वातावरण में समय में खो सकता है।

मुझे वितरित परियोजनाओं के लिए डेवलपर चैट रूम पसंद हैं। वास्तविक समय में चैट करना बहुत आसान है। कुछ संस्करण नियंत्रण चैट रूम में प्रतिबद्ध संदेश लिख सकते हैं।

बैकअप_मिगेट मॉड्यूल उत्पादन सर्वर से नवीनतम डीबी स्थिरता को पकड़ने के लिए आसान है। बेशक आप mysqldump आदि के माध्यम से निर्यात कर सकते हैं लेकिन यह छोटा मॉड्यूल कोई ब्रेनर नहीं है।

डॉक्सिजन भी देखें। अपने डेवलपर्स को उस प्रारूप में लिखने के लिए मजबूर करें। और ड्रूपल कोडिंग मानकों पर ध्यान दें। इसे जांचने के बजाय "कोडर" नामक एक मॉड्यूल है।

Answer 4

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