बोर्ड पर कई नेटवर्क उपकरणों वाले उपकरणों के लिए सॉफ्टवेयर संस्करण नियंत्रण के संगठन का वेरिएंट

मैं संस्करण नियंत्रण प्रणाली में रिपॉजिटरी के आयोजन के बारे में कुछ विचार साझा करना चाहता हूं। निश्चितता के लिए: हम बुध का उपयोग करते हैं, लेकिन यह इतना महत्वपूर्ण नहीं है।

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

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

डेवलपर्स व्यवसायिक यात्राओं (परीक्षणों पर) पर बहुत समय बिताते हैं, जहां उन्हें कोड बदलने और इंटरनेट पर अपडेट बदलने की आवश्यकता होती है।

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

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


तो, नियंत्रण की बहुत अवधारणा के बारे में। यह हमारे लिए एक वितरित संस्करण नियंत्रण प्रणाली (ऊपर और लंबी व्यापारिक यात्राएं देखें) का उपयोग करना मौलिक है। कई कारणों से, विकल्प बुध पर गिर गया, हालांकि गीत शायद नीचे आ गया था।

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

सर्वर पर एक संग्रहण ट्री होस्ट किया गया है। उसके क्लोन स्थानीय पीसी डेवलपर्स पर हैं। डेवलपर स्थानीय पेड़ या उसकी व्यक्तिगत शाखाओं को क्लोन करता है जैसा वह चाहता है।

संग्रहण ट्री टेम्पलेट निम्नानुसार है:

Repositories | +–.CrossplatformLib1 | +–.CrossplatformLib2 | +–... | +–Platform1 | | | +–.Platform1Lib1 | | | +–.Platform1Lib2 | | | +–... | +–Platform2 | | | +–.Platform2Lib1 | | | +–.Platform2Lib2 | | | +–... | +–... | +–Devices | | | +–.Device1 | | | +–.Device2 | | | +–... | +–Vehicles | +–Vehicle1 | +–Vehicle2 | +–... 

नाम की शुरुआत में डॉट रिपॉजिटरी को चिह्नित करता है, उदाहरण के लिए .Device1। डॉट्स के बिना नाम नियमित फ़ोल्डर हैं, उदाहरण के लिए, डिवाइसेस।

पेड़ की जड़ में (रिपॉजिटरी फ़ोल्डर की जड़ में) स्थित हैं। क्रॉसप्लेटफॉर्म लाइब्रेरी में क्रोसप्लामिट्रीलिबिक्स रिपॉजिटरी, उदाहरण के लिए, गणित, एल्गोरिदम, आदि।

PlatformX फ़ोल्डरों को उसी स्तर पर स्थित किया जाता है, जिसमें .PlatformXLibY रिपॉजिटरी होती है, जिसमें PlatformX प्लेटफॉर्म के लिए विशिष्ट पुस्तकालय होते हैं। उदाहरण के लिए, विंडोज के तहत नेटवर्क ड्राइवर।

शीर्ष-स्तरीय डिवाइस फ़ोल्डर में, ऑन-बोर्ड डिवाइसों के लिए .DeviceX सॉफ़्टवेयर के रिपॉजिटरी होते हैं जिनका उपयोग विभिन्न उपकरणों पर किया जा सकता है।

अंतिम शीर्ष-स्तरीय फ़ोल्डर वाहन है। इसमें विभिन्न वाहनएक्स उपकरणों के लिए परियोजनाएं शामिल हैं।

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


माना संरचना एक दूसरे के सापेक्ष भंडारण के स्थान को दर्शाता है। अब देखते हैं कि भंडारण की व्यवस्था खुद कैसे की जाती है।

भंडारण तंत्र का पर्याप्त उपयोग किया जाता है (जैसा कि मैं इसे समझता हूं, सभी आधुनिक संस्करण नियंत्रण प्रणालियों में ऐसे अवसर हैं)।

उदाहरण के लिए, कुछ Devices \ .DeviceX डिवाइस पर विचार करें। मान लीजिए कि डिवाइस X एक क्रॉस-प्लेटफ़ॉर्म लाइब्रेरी Y और प्लेटफ़ॉर्म Z के लिए विशेष लाइब्रेरी का उपयोग करता है। तब, डिवाइसेज \ _DeviceX फ़ोल्डर के स्तर पर, .CrossplatformLibY और PlatformZ \ .PlatformZibN के स्टोरेज क्लोन बनाए जाते हैं:।

 Repositories | +–Devices | +–.DeviceX | +–.CrossplatformLibY | +–.PlatformZLibN | +–DeviceXSpecificFolder1 | +–... 

.CrossplatformLibY और .PlatformZLibN रिपॉजिटरी के साथ, फ़ोल्डर में डिवाइस में एक्स-विशिष्ट स्रोत कोड फ़ाइलें होती हैं डिवाइस DeviceXSpecificFolderM, आदि।

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


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

 Repositories | +–Vehicles | +–.VehicleX | +–.DeviceY | +–.DeviceZ | +–DeviceM | +–... | +–Master 

नेटवर्क डिवाइस या तो सार्वभौमिक हो सकते हैं (विभिन्न उपकरणों पर उपयोग किए जाते हैं) या विशिष्ट। पहले मामले में, संबंधित स्टोर (इसे रहने दो। डाइसाइसवाई) डिवाइसेस \ _DeviceY स्टोर का एक क्लोन है। दूसरे मामले में, डिवाइस प्रोजेक्ट को एक अलग रिपॉजिटरी (.DiceiceZ) के रूप में नियंत्रित किया जा सकता है, या इसे .VhicleX स्टोरेज के एक अलग सबफ़ोल्डर के रूप में व्यवस्थित किया जा सकता है (उदाहरण के लिए, यह .Veicle2 DeviceM)। भंडारण के साथ संस्करण अधिक सुविधाजनक है कि परियोजना से अलग करना आसान है (क्लोनिंग द्वारा)।

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

.VehicleX और .DeviceY परियोजनाओं के बीच मजबूत संबंध क्यों बनाते हैं? नेटवर्क उपकरणों के कार्यान्वयन के कुछ आंतरिक विवरणों को बदलते समय सिस्टम इंटीग्रेटर (मास्टर डेवलपर) को इन परियोजनाओं को क्यों समझना और सिंक्रनाइज़ करना चाहिए?

संकेतित समस्या को दूर किया जाता है यदि संपूर्ण डिवाइस परियोजनाओं को सिंक्रनाइज़ नहीं किया जाता है, लेकिन केवल उनके इंटरफेस। ट्रैकिंग इंटरफेस के लिए एक विकल्प यह हो सकता है। डिवाइस इंटरफ़ेस फ़ाइलों का चयन करें। एक अलग रिपॉजिटरी में .DeviceY

 Repositories | +–Devices | +–.DeviceY | +–.Interface | | + +- device_y.h | +–Source | +–... 

.Interface रिपॉजिटरी में अक्सर एक एकल device_y.h हेडर फ़ाइल शामिल हो सकती है, ठीक है, रहने दो!

अब .VeicleX डिवाइस के रिपॉजिटरी में, आप संपूर्ण .DeviceY प्रोजेक्ट को ट्रैक नहीं कर सकते हैं, लेकिन केवल इसका .DeviceY \। Interface इंटरफ़ेस, जो कम भारी और अधिक स्थिर है। इसका क्लोन रिपॉजिटरी में रखा जा सकता है ।VeicleX \ Devices \ .DeviceY:

 Repositories | +–Vehicles | +–.VehicleX | +–Devices | | + +-.DeviceY | | + +-... | +–... | +–Master 

.VehicleX \ Devices फ़ोल्डर में, आप अन्य नेटवर्क उपकरणों के इंटरफेस रख सकते हैं। नेटवर्क डिवाइस के इंटरफ़ेस के लिए प्रत्येक स्टोर के रास्तों को निर्धारित नहीं करने के लिए .VehicleX \ Devices \। मास्टर कंपाइलर की सेटिंग में। आप डिवाइस के साथ। फिर मास्टर कंपाइलर के लिए यह केवल पथ .. उपकरण पंजीकृत करने के लिए पर्याप्त होगा।

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

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