कठिन अनुभव ने मुझे सिखाया है कि लगभग सब कुछ स्रोत नियंत्रण में है। (यहां मेरी टिप्पणी एक दशक और मालिकाना हार्डवेयर के साथ एम्बेडेड / टेलीकॉम सिस्टम के लिए विकसित होने वाले डेढ़ दशक के दौरान रंगी हुई है, और कभी-कभी उपकरण खोजने के लिए कठिन है।)
यहाँ कुछ उत्तर कहते हैं कि "बायनेरिज़ को स्रोत नियंत्रण में न रखें"। यह गलत है। जब आप तीसरे पक्ष के कोड और विक्रेताओं से बहुत सारे बाइनरी लाइब्रेरी वाले उत्पाद पर काम कर रहे होते हैं, तो आप बाइनरी लाइब्रेरी में जांचते हैं । क्योंकि, यदि आप नहीं करते हैं, तो कुछ बिंदु पर आप अपग्रेड करने जा रहे हैं और आप परेशानी में पड़ जाएंगे: बिल्ड टूट जाता है क्योंकि बिल्ड मशीन में नवीनतम संस्करण नहीं है; कोई नया आदमी पुरानी सीडी को इंस्टॉल करने के लिए देता है; क्या संस्करण स्थापित करने के बारे में परियोजना विकी के बासी निर्देश हैं; वगैरह अभी भी, अगर आपको किसी विशेष मुद्दे को हल करने के लिए विक्रेता के साथ मिलकर काम करना है और वे आपको एक हफ्ते में पांच सेट लाइब्रेरी भेजते हैं, तो आपको अवश्य करना चाहिएट्रैक करने में सक्षम हो सकता है कि बायनेरिज़ के किस सेट ने किस व्यवहार का प्रदर्शन किया। स्रोत नियंत्रण प्रणाली एक उपकरण है जो उस समस्या को हल करता है।
यहाँ कुछ उत्तर कहते हैं कि "टूलचैन को स्रोत नियंत्रण में न रखें"। मैं यह नहीं कहूंगा कि यह गलत है, लेकिन टूलचैन को स्रोत नियंत्रण में रखना सबसे अच्छा है जब तक कि आपके पास इसके लिए एक ठोस ठोस कॉन्फ़िगरेशन प्रबंधन (CM) प्रणाली न हो । फिर से, ऊपर बताए अनुसार नवीनीकरण समस्या पर विचार करें। इससे भी बदतर, मैंने एक ऐसी परियोजना पर काम किया, जहां टूलचिन के चार अलग-अलग स्वाद थे जब मुझे काम पर रखा गया था - वे सभी सक्रिय उपयोग में थे ! मेरे द्वारा किए गए पहले कामों में से एक (मैं काम करने के लिए एक निर्माण प्राप्त करने में कामयाब होने के बाद) टूलचिन को स्रोत नियंत्रण में रखा गया था। (ठोस मुख्यमंत्री प्रणाली का विचार आशा से परे था।)
और क्या होता है जब विभिन्न परियोजनाओं के लिए अलग-अलग टूलचिन की आवश्यकता होती है? बिंदु में मामला: कुछ वर्षों के बाद, परियोजनाओं में से एक को एक विक्रेता से अपग्रेड मिला और सभी मेकफाइल्स टूट गए। पता चला कि वे GNU मेक के नए संस्करण पर निर्भर थे। इसलिए हम सब अपग्रेड हुए। वूप्स, एक और प्रोजेक्ट का मेकफाइल्स सब टूट गया। पाठ: जीएनयू के दोनों संस्करण बनाते हैं, और उस संस्करण को चलाते हैं जो आपके प्रोजेक्ट चेकआउट के साथ आता है।
या, यदि आप एक ऐसी जगह पर काम करते हैं जहाँ बाकी सब कुछ बेतहाशा नियंत्रण से बाहर है, तो आपके पास वार्तालाप है, "अरे, आज नया आदमी शुरू हो रहा है, जहां संकलक के लिए सीडी है?" "डननो, जैक के जाने के बाद से उन्हें नहीं देखा, वह सीडी का संरक्षक था।" "उह, क्या हम दूसरी मंजिल से आगे बढ़ने से पहले नहीं थे?" "शायद वे एक बॉक्स या कुछ और में हैं।" और चूंकि उपकरण तीन साल पुराने हैं, इसलिए विक्रेता से उस पुरानी सीडी को प्राप्त करने की कोई उम्मीद नहीं है।
आपकी सभी निर्मित स्क्रिप्ट स्रोत नियंत्रण में हैं। सब कुछ! पर्यावरण चर के लिए सभी तरह से नीचे। आपकी बिल्ड मशीन प्रोजेक्ट की जड़ में किसी एक स्क्रिप्ट को निष्पादित करके आपकी किसी भी परियोजना का निर्माण चलाने में सक्षम होनी चाहिए। ( ./buildएक उचित मानक है; ./configure; makeलगभग उतना ही अच्छा है।) स्क्रिप्ट को पर्यावरण को आवश्यकतानुसार सेट करना चाहिए और फिर जो भी उपकरण उत्पाद बनाते हैं उसे लॉन्च करें (मेक, एंट, आदि)।
अगर आपको लगता है कि यह बहुत अधिक काम है, तो यह नहीं है। यह वास्तव में काम का एक टन बचाता है। आप समय की शुरुआत में एक बार फाइल करते हैं और फिर जब भी आप अपग्रेड करते हैं। कोई भी अकेला भेड़िया अपनी मशीन को अपग्रेड नहीं कर सकता है और किसी अन्य उपकरण के नवीनतम संस्करण पर निर्भर स्रोत कोड का एक गुच्छा बना सकता है, जो निर्माण को हर किसी के लिए तोड़ देता है। जब आप नए डेवलपर्स को नियुक्त करते हैं, तो आप उन्हें प्रोजेक्ट की जांच करने और चलाने के लिए कह सकते हैं ./build। जब संस्करण 1.8 में बहुत अधिक प्रदर्शन ट्यूनिंग होती है, और आप कोड, कंपाइलर झंडे और पर्यावरण चर को ट्विक करते हैं, तो आप यह सुनिश्चित करना चाहते हैं कि नए संकलक झंडे गलती से संस्करण 1.7 पैच बिल्ड पर लागू न हों, क्योंकि उन्हें वास्तव में कोड की आवश्यकता है परिवर्तन जो उनके साथ जाते हैं या आप कुछ बालों की दौड़ की स्थिति देखते हैं।
सबसे अच्छा , यह किसी दिन आपके गधे को बचाएगा: कल्पना करें कि आप सोमवार को अपने उत्पाद का संस्करण 3.0.2 शिप करते हैं। हुर्रे, जश्न। मंगलवार की सुबह, एक वीआईपी ग्राहक ने समर्थन हॉटलाइन पर कॉल किया, जो इस सुपरक्रिटिकल, तत्काल बग के बारे में शिकायत करता है 2.2.6 संस्करण में जिसे आपने 18 महीने पहले भेज दिया था। और आपको अभी भी संविदात्मक रूप से इसका समर्थन करना है, और वे अपग्रेड करने से इनकार करते हैं जब तक कि आप इस बात की पुष्टि नहीं कर सकते कि बग नए कोड में तय किया गया है, और वे आपको नृत्य करने के लिए पर्याप्त बड़े हैं। दो समानांतर ब्रह्मांड हैं:
ब्रह्मांड में जहां आपके पास लाइब्रेरी, टूलचैन नहीं है, और स्रोत नियंत्रण में स्क्रिप्ट का निर्माण करते हैं, और आपके पास रॉक-सॉलिड सीएम सिस्टम नहीं है .... आप कोड के सही संस्करण की जांच कर सकते हैं, लेकिन यह देता है जब आप निर्माण करने का प्रयास करते हैं तो आप सभी प्रकार की त्रुटियां। आइए देखें, क्या हमने मई में उपकरणों को अपग्रेड किया था? नहीं, वह पुस्तकालय था। ठीक है, पुराने पुस्तकालयों में वापस जाओ - रुको, क्या दो उन्नयन थे? आह हाँ, यह थोड़ा बेहतर लग रहा है। लेकिन अब यह अजीब लिंकर दुर्घटना परिचित लग रहा है। ओह, ऐसा इसलिए है क्योंकि पुराने पुस्तकालयों ने नए टूलचैन के साथ काम नहीं किया, इसीलिए हमें अपग्रेड करना पड़ा, है ना? (मैं आपको शेष प्रयास की पीड़ा को छोड़ दूंगा। इसमें दो सप्ताह लगते हैं और कोई भी इसके अंत में खुश नहीं है, आप नहीं, प्रबंधन नहीं, ग्राहक नहीं।)
ब्रह्मांड में जहां सब कुछ स्रोत नियंत्रण में है, आप 2.2.6 टैग की जांच करते हैं, एक या एक घंटे में डिबग बिल्ड तैयार करते हैं, एक या दो दिन "वीआईपी बग" को फिर से बनाते हैं, कारण को ट्रैक करते हैं, इसे ठीक करते हैं वर्तमान रिलीज़, और ग्राहक को उन्नत करने के लिए मना लें। तनावपूर्ण, लेकिन लगभग उतना बुरा नहीं है जितना कि अन्य ब्रह्मांड जहां आपका हेयरलाइन 3cm अधिक है।
उस ने कहा, आप इसे बहुत दूर ले जा सकते हैं:
- आपके पास एक मानक ओएस स्थापित होना चाहिए जो आपके पास "सोने की नकल" हो। यह दस्तावेज़, शायद एक README में है जो स्रोत नियंत्रण में है, ताकि आने वाली पीढ़ियों को पता हो कि संस्करण 2.2.6 और पहले केवल RHEL 5.3 और 2.3.0 पर बनाया गया था और बाद में केवल Ubuntu 11.04 पर बनाया गया था। यदि आपके लिए टूलचैन को इस तरह से प्रबंधित करना आसान है, तो इसके लिए जाएं, बस सुनिश्चित करें कि यह एक विश्वसनीय प्रणाली है।
- स्रोत नियंत्रण प्रणाली में बनाए रखने के लिए प्रोजेक्ट प्रलेखन बोझिल है। प्रोजेक्ट डॉक्स हमेशा कोड के आगे होते हैं, और वर्तमान संस्करण के लिए कोड पर काम करते समय अगले संस्करण के लिए प्रलेखन पर काम करना असामान्य नहीं है। खासकर यदि आपके सभी प्रोजेक्ट डॉक्स बाइनरी डॉक्स हैं जिन्हें आप अलग नहीं कर सकते हैं या मर्ज नहीं कर सकते हैं।
- यदि आपके पास एक सिस्टम है जो बिल्ड में उपयोग की जाने वाली सभी चीजों के संस्करणों को नियंत्रित करता है, तो इसका उपयोग करें ! बस यह सुनिश्चित करें कि पूरी टीम में सिंक करना आसान है, ताकि सभी (बिल्ड मशीन सहित) एक ही उपकरण के सेट से खींच रहे हों। (मैं डेबियन के पिल्डर जैसी प्रणालियों के बारे में सोच रहा हूं और अजगर के वर्चुअन का जिम्मेदार उपयोग करता हूं।)