हमने एक जटिल परियोजना में एसवीएन का उपयोग कैसे किया

शुरुआत

लगभग एक साल पहले, उद्यम में एक नई परियोजना शुरू की गई थी, और जो पहले ही पूरी हो चुकी है। इसे मुझे और मेरे सहयोगी को ले जाने के लिए सौंपा गया।



क्यूटी लाइब्रेरी को विकास के आधार के रूप में चुना गया था। चूंकि उद्यम में सभी परियोजनाओं को डेल्फी में किया गया था, इसलिए हम इस शक्तिशाली उपकरण के अग्रणी बन गए। इससे पहले, हम में से कोई भी क्यूटी पुस्तकालय का उपयोग करके वाणिज्यिक उत्पादों को विकसित नहीं कर रहा था।



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



नीचे वर्णित सब कुछ आधुनिक व्यावसायिक वास्तविकताओं के मिश्रण के साथ Qt परियोजनाओं में SVN का उपयोग करने के व्यावहारिक अनुभव को संदर्भित करता है।

भंडार संरचना का विकास (भंडारण)

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

समस्याओं की शुरुआत

एक महीने के विकास के बाद, हमारे पास पहले से ही सर्वर पर कई स्टोरेज थे। मुख्य परियोजना के लिए एक प्रमुख। इसमें दो मुख्य कार्यक्रम रखे गए थे जिनमें कई सामान्य घटक होते हैं। बाकी बनाए गए टूल, बड़े सबसिस्टम के लिए बनाए गए थे, जिन्हें अन्य परियोजनाओं में इस्तेमाल किया जाना था।



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



तथ्य यह है कि मुझे दूसरे कमरे में जाना पड़ा। और यह आईपी-एड्रेस का एक परिवर्तन है। भंडारण के लिए, यह न केवल कुख्यात स्थानांतरित है, बल्कि svn: externals वाले फ़ोल्डरों के सभी गुणों का संपादन भी है। यह थोड़ा उपद्रव जल्दी से हार गया और काम जारी रहा। मेरी मशीन पर भंडारण रहता है।



निर्णय: भंडारण के लिए एक अलग सर्वर को व्यवस्थित करना आवश्यक है।

आगे और भी

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



निर्णय: यदि आप एक परियोजना - एक रिपॉजिटरी के दृष्टिकोण का उपयोग करते हैं, तो ट्रंक, टैग, शाखा फ़ोल्डर को केवल रिपॉजिटरी की जड़ में रखा जाता है।



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



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



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



दूसरे, हमने उस फ़ोल्डर की जड़ में बनाया है, जिसमें शामिल और काम करने वाले फ़ोल्डरों की सबसे महत्वपूर्ण समर्थक फाइलें थीं। शामिल फ़ोल्डर में, हमने शीर्ष लेख फ़ाइलों को बिना एक्सटेंशन के लगभग एक पंक्ति में रखना शुरू कर दिया है: #include "../modude1/src/modile1.h"। यह काम करने के लिए हेडर फ़ाइलों के साथ केवल एक निर्देशिका को शामिल करने की अनुमति देता है और यह चिंता नहीं करता है कि आवश्यक फाइलें कहां हैं। और लिबर फोल्डर में सबप्रोजेक्ट से एकत्रित सभी लाइब्रेरी को रखा गया था। इस प्रकार, रास्ते में सिर्फ एक निर्देशिका पंजीकृत होने के बाद, हमने सभी पुस्तकालय निर्भरताओं को बाहर कर दिया।



निर्णय: यह सिद्धांत बनाए रखने के लिए अत्यंत महत्वपूर्ण है: भंडार से विलय और समस्याओं के बिना एकत्र किया गया।



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



निर्णय: कोड को संग्रहीत करने के लिए न केवल एक अलग सर्वर होना आवश्यक है, बल्कि इसके संग्रह को कॉन्फ़िगर करना भी महत्वपूर्ण है।



सर्वर बनाने के सर्जक को नियंत्रित करने के बाद, मुझे अभिलेखागार और सर्वर के प्रदर्शन की निगरानी के लिए जवाब देना होगा।



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



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



फैसला: आपको यह सीखना होगा कि पैच के साथ कैसे काम करें और क्या करें।

लगभग अंत

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



निर्णय: मैंने कार्य पर काम शुरू किया - इसे मुख्य रूप से भंडार में रखने के लिए।

निष्कर्ष

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