आज, दो प्रकार के संस्करण नियंत्रण प्रणालियां हैं: क्लाइंट-सर्वर और वितरित। लेकिन उनके बीच भारी अंतर के बावजूद, हम अभी भी टीम के सदस्यों के बीच काम को सिंक्रनाइज़ करने के लिए केंद्रीय सर्वर का उपयोग करना जारी रखते हैं।
और अगर एक दिन केंद्रीय सर्वर जल जाए तो क्या होगा?
इसकी चर्चा करते हैं
ग्राहक सर्वर वास्तुकला
संस्करण नियंत्रण प्रणालियों की इस श्रेणी में सीवीएस, एसवीएन जैसे शामिल हैं। ऐसे सिस्टम के साथ काम करते समय, आपके पास एक सर्वर होना चाहिए जिस पर वर्जनिंग के साथ काम करने के लिए विशेष सॉफ्टवेयर इंस्टॉल किया जाएगा। और हर बार जब आप स्रोत कोड को अपडेट प्राप्त करते हैं या परिवर्तन करते हैं, तो आप इस केंद्रीय सर्वर की ओर रुख करते हैं। यदि यह ढह जाता है, तो आप परिवर्तनों के पूरे इतिहास को खो देंगे, जो, अफसोस, बहाल नहीं किया जा सकता है। इस पाठ्यक्रम को बैकअप द्वारा हल किया जा सकता है। नतीजतन, आप केवल उस भाग को खो देंगे जो अंतिम बैकअप बनाने के बाद बनाया गया था।
इस मॉडल के विपरीत, वितरित संस्करण नियंत्रण प्रणाली के समर्थक उन्हें विज्ञापन देते हैं, यह दर्शाता है कि उन्हें केंद्रीय सर्वर की आवश्यकता नहीं है और यह कि यह मॉडल केंद्रीय सर्वर क्रैश की स्थिति में समस्याओं से अधिक सुरक्षित है।
वितरित वास्तुकला
लेकिन क्या आपने कभी देखा है कि जिन टीमों में समान गिट या मर्क्यूरियल का उपयोग किया जाता है, वे केंद्रीय सर्वर के बिना काम करते हैं? मैं ईमानदारी से कभी नहीं है। लेकिन डीवीसीएस के अनुयायी अभी भी सही हैं। जब आपको केंद्रीय सर्वर रिपॉजिटरी से कोड मिलता है, तो आपको न केवल नवीनतम संस्करण मिलता है, बल्कि परिवर्तनों का इतिहास भी होता है, परिणामस्वरूप, संपूर्ण रिपॉजिटरी आपके पास आती है। आप, बदले में, किसी अन्य टीम के सदस्य के लिए केंद्रीय सर्वर के रूप में भी कार्य कर सकते हैं। लेकिन अगर यह टीम का सदस्य आपके रिपॉजिटरी में अपने परिवर्तन अपलोड करेगा, तो आपको इन परिवर्तनों को केंद्रीय सर्वर पर आगे बढ़ाना होगा ताकि सभी टीम सदस्यों के पास नवीनतम कोड हो। और हमारे पास क्या है? आप केंद्रीय सर्वर के बिना नहीं कर सकते हैं, लेकिन इसके पतन की स्थिति में, आप इतिहास और बाकी सभी चीजों को पुनर्स्थापित कर सकते हैं। और बैकअप इतनी महत्वपूर्ण भूमिका नहीं निभाते हैं।
समतुल्य वास्तुकला
अब ऐसी प्रणाली बनाने के बारे में सोचें जहां आपको सर्वर को सिंक्रोनाइज़ेशन के लिए नहीं रखना होगा, लेकिन टीम के सभी सदस्यों के पास हमेशा कोड का नवीनतम संस्करण होगा। मैं इस प्रणाली को निम्न रूप में देखता हूं: सभी स्रोत कोड सभी टीम के सदस्यों द्वारा संग्रहीत किए जाते हैं, लेकिन जब एक टीम का सदस्य अपने परिवर्तन करता है, तो वे संचरित होते हैं, उदाहरण के लिए, दो सहयोगियों के लिए, और वे, बदले में, दो और, और इतने पर पूरी टीम वर्तमान संस्करण नहीं होगी। गलती सहिष्णुता के मामले में, यह प्रणाली एकदम सही लगती है। कोई केंद्रीय सर्वर नहीं है, इस बात की कोई संभावना नहीं है कि इसके पतन के दौरान डेटा हानि होगी, और न ही आपको सर्वर क्रैश के बाद खोए हुए डेटा को पुनर्प्राप्त करने के लिए समय बिताने की आवश्यकता होगी। लेकिन इस विचार में भी खामियां हैं, अर्थात् यदि किसी टीम में कम संख्या में प्रतिभागी (1-2 लोग) शामिल हैं, तो डेटा हानि की संभावना बहुत अधिक है। इस समस्या का एक समाधान सब के बाद, एक सर्वर का उपयोग करना हो सकता है। दूसरी ओर, यह संभव है, उदाहरण के लिए, इस उत्पाद को विकसित करने वाली टीम के सदस्यों के बीच न केवल प्रोग्राम रिपॉजिटरी वितरित करने के लिए, बल्कि उन अन्य लोगों के बीच भी जिनके पास यह वीसीएस स्थापित है। बेशक, इस उत्पाद के विकास से संबंधित अन्य लोगों के लिए, डिलीवरी से पहले कोड को एन्क्रिप्ट किया जाना चाहिए।
इसलिए, तकनीकी दृष्टिकोण से, प्रणाली के काम करने के लिए, एक सेवा को ऑपरेटिंग सिस्टम में स्थापित किया जाना चाहिए जो सहकर्मियों से परिवर्तनों को स्वीकार करेगा, इसे स्थानीय रिपॉजिटरी में अपलोड करेगा और प्राप्त डेटा को अन्य टीम के सदस्यों के लिए पुनर्निर्देशित करेगा। जब डेवलपर को अपग्रेड करने की आवश्यकता होती है, तो वह स्थानीय रिपॉजिटरी से कोड प्राप्त करेगा।
इस मामले में परिवर्तन करने का तंत्र इस प्रकार है: डेवलपर परिवर्तन करने के लिए कमांड निष्पादित करता है, ये परिवर्तन मुख्य रूप से स्थानीय रिपॉजिटरी में आते हैं, और इस रिपॉजिटरी की सेवा टीम के बीच प्राप्त और वितरित करती है।
खैर, यह विचार बहुत सरल है। और लगता है कि जोड़ने के लिए कुछ भी नहीं है।
और मैं यह लेख क्यों लिख रहा हूँ? और इसके अलावा, मैं एक समान प्रणाली लिखना चाहूंगा और बस अपने विचारों को समुदाय के साथ साझा करूंगा। और अचानक ऐसे लोग हैं जो खुशी से इसके आभारी उपयोगकर्ता होंगे।
आपका ध्यान देने के लिए धन्यवाद।