एक इंटरनेट परियोजना के टीम विकास का संगठन (Git और 1C-Bitrix का उपयोग करके)

मुझे याद है कि 90 के दशक में एक ऐसा पेशा (या व्यवसाय) था - एक वेबमास्टर। यह उस व्यक्ति का नाम है जो इंटरनेट साइटों के विकास में शामिल था: डिजाइनर, लेआउट डिजाइनर, प्रोग्रामर और सामग्री प्रबंधक - सभी एक में लुढ़का। समय बदल रहा है। आधुनिक इंटरनेट परियोजनाएं अक्सर 5 से 10 लोगों के काम का फल होती हैं। टीम का काम



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



टीम में इस तरह के संघर्ष की संभावना को एक संस्करण नियंत्रण प्रणाली के उपयोग के माध्यम से शून्य तक कम किया जा सकता है। इस लेख में मैं 1C-Bitrix सामग्री प्रबंधन प्रणाली के लिए टीम के विकास के लिए github.com सेवा का उपयोग करके Git संस्करण नियंत्रण प्रणाली स्थापित करने में अपना अनुभव साझा करना चाहता हूं। मैं आपको परियोजना प्रबंधक के दृष्टिकोण से बताऊंगा, न कि सर्वर प्रशासक से।





परियोजना पर टीम के संगठन के सबसे सरल संस्करण में, हमें चाहिए - सर्वर पर एक मुख्य साइट - हम इसे उत्पादन कहेंगे, परीक्षण के लिए एक साइट (विकास स्थल) - इसके आगे सर्वर (देव स्थल) पर + प्रत्येक डेवलपर की साइट की स्थानीय प्रति के लिए। (सर्वर पर कई विकास साइटें हो सकती हैं, लेकिन अतिरिक्त देव साइटों के बारे में, आपको पहले लाइसेंस समझौते के दृष्टिकोण से ऐसी प्रणाली की वैधता के बारे में बिट्रिक्स तकनीकी सहायता से परामर्श करना होगा)।



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



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



तो, हमारे पास एक समर्पित सर्वर है, दो कॉन्फ़िगर किए गए वर्चुअल होस्ट और इंस्टॉल किए गए गिट सर्वर सॉफ़्टवेयर - यह, एक नियम के रूप में, हमारे लिए होस्टिंग के कर्मचारियों द्वारा किया जा सकता है जिस पर हम सर्वर खरीदते हैं।



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



हम github.com पर कॉर्पोरेट टैरिफ पंजीकृत करते हैं । इस लेख में चर्चा की गई प्रणाली के लिए, हमारे पास प्रति माह $ 25 के लिए पर्याप्त टैरिफ होगा। हम एक निजी रिपॉजिटरी बनाते हैं, मौजूदा githab उपयोगकर्ताओं को संगठन में जोड़ते हैं (या नए उपयोगकर्ता बनाते हैं) - यह सब बहुत पारदर्शी और सुविधाजनक तरीके से किया जाता है, इसलिए हम इस बिंदु पर विस्तार से ध्यान केंद्रित नहीं करेंगे।



कॉरपोरेट प्राइवेट रिपॉजिटरी शुरू होने के बाद, हमें इसके लिए पहला कमिटमेंट बनाने की जरूरत है।



हम एक सर्वर के रूप में हमारे सर्वर पर जाते हैं, जिसमें साइटों के फ़ोल्डरों के लिए लिखने की अनुमति है, उस निर्देशिका पर जाएं जिसमें हम रिपॉजिटरी शुरू करने का इरादा रखते हैं।



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



मुख्य साइट के लिए एक रिपॉजिटरी शुरू करने से पहले, आपको यह तय करने की जरूरत है कि आप रिपॉजिटरी में कौन से फोल्डर और फाइल को शामिल करना चाहते हैं, और जो नहीं हैं - एक .ignignore फाइल बनाने के लिए।



उदाहरण के लिए .Cignignore फ़ाइल 1C-Bitrix के मामले के लिए जब रिपॉजिटरी साइट डायरेक्टरी में शुरू की जाती है:

/bitrix/backup /bitrix/cache /bitrix/crontab /bitrix/managed_cache /bitrix/managed_flags /bitrix/modules/*.log /bitrix/php_interface/crontab /bitrix/php_interface/dbconn.php /bitrix/stack_cache /logs /upload /.gitignore /.htaccess /urlrewrite.php /*.log /*.sql /*.txt /*.xml /*.dt
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

उदाहरण के लिए .Cignignore फ़ाइल 1C-Bitrix के मामले के लिए जब रिपॉजिटरी को एक उपनिर्देशिका में शुरू किया जाता है:

 /httpfiles/bitrix/backup /httpfiles/bitrix/cache /httpfiles/bitrix/crontab /httpfiles/bitrix/managed_cache /httpfiles/bitrix/managed_flags /httpfiles/bitrix/modules/*.log /httpfiles/bitrix/php_interface/crontab /httpfiles/bitrix/php_interface/dbconn.php /httpfiles/bitrix/stack_cache /httpfiles/logs /httpfiles/upload /httpfiles/.htaccess /httpfiles/urlrewrite.php /httpfiles/*.log /httpfiles/*.sql /httpfiles/*.txt /httpfiles/*.xml /httpfiles/*.dt
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

यही है, हम बैकअप फ़ोल्डर (/ बिट्रिक्स / बैकअप), कैश फ़ोल्डर (/ बिट्रिक्स / कैश, / बिट्रिक्स / मैनेज_कैच, / बिट्रिक्स / मैनेज_फ्लैग, / बिट्रिक्स / स्टैक_केच), क्राउन जॉब्स (/ बिट्रिक्स / कोंटैब) वाले फ़ोल्डर में बदलावों को नियंत्रित नहीं करेंगे। ), लॉग्स (/ लॉग्स) के साथ एक फ़ोल्डर, डाउनलोड्स (/ अपलोड) के साथ एक फ़ोल्डर।

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



हम कमांड के साथ विकास स्थल की निर्देशिका / देव / - रूट निर्देशिका में एक प्रतीकात्मक लिंक बनाते हैं

 ln -s /path/to/www/upload
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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



फ़ाइल /bitrix/php_interface/dbconn.php में ऐसी सेटिंग्स होती हैं जो प्रत्येक वर्चुअल होस्ट (विशेष रूप से, डेटाबेस से कनेक्ट करने के लिए सेटिंग्स) के लिए अलग-अलग होती हैं, इसलिए हम इस फ़ाइल को अपवादों को जोड़ने के लिए जोड़ते हैं।



फ़ाइल /urlrewrite.php Bitrix सीएनसी पतों को संसाधित करने के नियमों के साथ एक फ़ाइल है - यह इंजन द्वारा स्वयं को ओवरराइट (सॉर्ट किया गया) हो सकता है, इसलिए हम इसे बाहर कर देंगे।



.Itignignore और .htaccess फाइलें भी अपवादों में होनी चाहिए। अपवाद के रूप में, यह लॉग फ़ाइलों, पाठ फ़ाइलों, xml फ़ाइलों को जोड़ने के लायक भी है - यह सब प्रोग्राम कोड पर सीधे लागू नहीं होता है।



हमने .gitignore की सामग्री पर फैसला कर लिया है और भविष्य की रिपॉजिटरी की निर्देशिका में .gitignore फ़ाइल बनाई है, हम उत्पादन साइट के लिए रिपॉजिटरी आरंभ कर सकते हैं। ऐसा करने के लिए, हमें सबसे पहले अपने सर्वर ssh-user को githab पर अधिकृत करने की आवश्यकता है - इसके लिए एक कुंजी तैयार करें।



आदेश निष्पादित करें

 ssh-keygen -t rsa -C "bitrix@."
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ईमेल किसी को भी दर्ज किया जा सकता है, लेकिन बिट्रिक्स@site.site के एक ईमेल के साथ जीथब पर कुंजी को पहचानना आसान है।



हम github.com/settings/ssh पर जाते हैं और एक नई कुंजी जोड़ते हैं - हम फ़ाइल /path/to/.ssh/id_rsa.pub से कुंजी का डेटा लेते हैं



कनेक्शन की जाँच करें:

 ssh-T git@github.com
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

हम मुख्य साइट (या उपनिर्देशिका) की निर्देशिका में रिपॉजिटरी शुरू करते हैं:

/ पथ / / / www / पर जाएं और कमांड निष्पादित करें:

 git add README.md git commit -m "first commit" git remote add origin git@github.com:/_.git git push -u origin master
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

मुख्य साइट के लिए रिपॉजिटरी शुरू होने के बाद, सभी प्रोजेक्ट फाइलों को गीथब रिपॉजिटरी में अपलोड करें:

 git add . git commit -m “second commit” git push
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

अब हम रिपॉजिटरी को विकास स्थल की निर्देशिका में क्लोन करते हैं:

 cd git clone git@github.com:/_.git dev
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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



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



उसके बाद, आप आराम कर सकते हैं और टीम वर्क का आनंद ले सकते हैं, झगड़े और विवादों के बिना सहकर्मियों के साथ मैत्रीपूर्ण संबंध बना सकते हैं, जल्दी से गलत परिवर्तनों को वापस ला सकते हैं - बिना दोषी लोगों को खोजे।



संबंधित लिंक:

- Git संस्करण नियंत्रण प्रणाली

- प्रतीकात्मक लिंक क्या हैं

- स्थापना और विन्यास गाइड 1C-Bitrix