आप संस्करण नियंत्रण कितनी दूर लेते हैं?

Question

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

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

टूलचैन के भंडारण ने त्वरित देनदारियों के निर्माण के दौरान तत्काल लाभ लाया। गिट, दुर्भाग्य से, बड़ी बाइनरी फाइलों से निपटने के दौरान कुछ मौलिक मुद्दे हैं।

आप सही तरीके से वीसी का उपयोग करने के लिए लाइनों को आकर्षित करते हैं और आप अधिक उचित समाधान की जांच कब शुरू करते हैं?

Answer 1

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

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

एक विशाल बाइनरी के रूप में ओएस छवि को स्वयं संस्करण करना लगभग उतना उपयोगी नहीं है। आप शाखा नहीं बना सकते आप विलय नहीं कर सकते आप diff नहीं कर सकते हैं। क्या बात है? यदि आपका वीसीएस बाइनरी डिफ्स कर सकता है तो आप स्पेस को सेव कर सकते हैं, लेकिन संभवतः सीपीयू और मेमोरी का एक टन लेता है, और यदि वे "डिस्क सस्ता है" बिंग पर हैं, तो जीवन को बचाने के लिए दर्दनाक बनाने का कोई कारण नहीं है डिस्क में जगह।

या तो वीसी में अपनी इंस्टॉल स्क्रिप्ट/लाइब्रेरी स्टोर करें और वीएम छवि को आवश्यकतानुसार पुनर्निर्माण करें, या केवल सामान्य फ़ाइलों में वीएम छवियों को स्टोर करें। मुझे वीसीएस में छवियों को रखने में कोई बात नहीं दिख रही है।

Answer 2

मैं वहाँ यहाँ आपरेशन के एक आदेश का कहना है कि चाहते हैं:

वे फ़ाइलों को संग्रहित एक फाइल सिस्टम का उपयोग करने की जरूरत है।

यदि उन्हें परिवर्तनों को ट्रैक करने की आवश्यकता है, तो संस्करण नियंत्रण का उपयोग करें।

यदि उन्हें डेटा से संबंधों को ट्रैक करने की आवश्यकता है, तो डेटाबेस का उपयोग करें।

अधिक जटिल आवश्यकताओं, समाधान को और अधिक जटिल। लेकिन अनुशासन उन लोगों के लिए है जो अधिक जटिल समाधान चाहते हैं; इन अनिश्चित काल में किसी को समय बर्बाद करने से बचना चाहिए।

Answer 3

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

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

Answer 4

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

Answer 5

आईटी फ्यूसिनेस के बजाए सामान्य ज्ञान, यह समझना चाहिए कि आप अपने टूलचेन को कैसे नियंत्रित और कॉन्फ़िगर करते हैं। यदि आपके पास मानक हार्डवेयर है और अक्सर डेवलपर जोड़ रहे हैं, तो आपके निर्मित टूलचेन को संग्रहीत करना क्योंकि छवियां समझ में आती हैं; लेकिन छवियों को संस्करण नियंत्रण के तहत होना जरूरी नहीं है। यदि आपके पास 50 डेवलपर हैं, तो आपके टूलचेन के लिए कॉन्फ़िगरेशन प्रबंधन प्रणाली ओवरहेड काट जाएगी; यदि आपके पास 5 डेवलपर्स हैं, तो यह अधिक ओवरहेड है - सीखने के लिए एक और सिस्टम।

तो क्या गिट आप जो करना चाहते हैं उसके रास्ते में हो रहा है? या आप अनुरोध प्राप्त कर रहे हैं क्योंकि उपयोगकर्ता यह कहने की कोशिश कर रहे हैं कि आपको अपने सिस्टम को और अधिक जटिल बनाना चाहिए क्योंकि आप कर सकते हैं?

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

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

Answer 6

एक चरम दृष्टिकोण के लिए Vesta देखें।

Allan Heydon, Roy Levin, Timothy Mann, Yuan Yu. The Vesta Approach to Software Configuration Management से:

वेस्टा दृष्टिकोण निम्नलिखित नींव पर आधारित है:

• अपरिवर्तनीय, अमर, संस्करणीकृत सभी स्रोतों और उपकरणों की भंडारण। ClearCASE के विपरीत, वेस्ता दृश्यों के बजाय स्पष्ट संस्करण संख्याओं का उपयोग करता है।

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

• स्वचालित व्युत्पन्न फ़ाइल प्रबंधन। व्युत्पन्न फाइलों का भंडारण और नामकरण स्वचालित रूप से वेस्ता स्टोरेज रिपोजिटरी द्वारा प्रबंधित किया जाता है, जिससे एकाधिक रिलीज बनाने या एकाधिक लक्ष्य प्लेटफ़ॉर्म के लिए भवन बनाने का बोझ आसान हो जाता है।

• सभी निर्माण कार्य की साइट-व्यापी कैशिंग। वेस्टा में एक साझा साइट-व्यापी कैश बिल्ड परिणाम प्रदान करता है ताकि डेवलपर एक-दूसरे के निर्माण से लाभ उठा सकें।

• स्वचालित निर्भरता पहचान।वेस्टा बिल्डर गतिशील रूप से पता लगाता है और सभी निर्भरताओं को रिकॉर्ड करता है, इसलिए मानव त्रुटि से कोई भी छोड़ा नहीं जा सकता है। गतिशील रूप से, हमारा मतलब है कि निर्माता यह पता लगाता है कि में कौन से स्रोत वास्तव में उपयोग किए जाते हैं, निर्माण परिणाम और रिकॉर्ड निर्भरताओं को केवल पर बनाने की प्रक्रिया का निर्माण करने की प्रक्रिया। वेस्ता का निर्भरता विश्लेषण के किसी भी ज्ञान का उपयोग नहीं करता है कि निर्माण उपकरण कैसे काम करते हैं; इस प्रकार यह अर्थशास्त्र-गनटर [7] की शब्दावली में स्वतंत्र है। उदाहरण के लिए, यदि कोई संकलक फ़ाइल foo.c को संकलित करने की प्रक्रिया में फ़ाइल foo.h पढ़ता है, तो वेस्टा मान लेगा कि कंपाइलर का आउटपुट foo.h पर पर निर्भर करता है, भले ही सी के ज्ञान वाला टूल हो foo.h में अलग-अलग आइटम ढूंढें जिन्हें संकलन के परिणाम को बदले बिना बदला जा सकता है।

Answer 7

क्या मैं हमेशा संस्करण नियंत्रण में डाल दिया:

• स्रोत कोड और makefiles: न्यूनतम इमारत binaries के लिए की जरूरत है।
• परीक्षण सुइट्स

मैं कभी नहीं संस्करण नियंत्रण में क्या रखना:

• बनाया बाइनरी: वे स्रोत नियंत्रण से निर्मित किया जा सकता है, और अगर मुझे पता है कि मैं एक विशिष्ट रिहाई तुरंत आवश्यकता हो सकती है, मैं उन्हें फ़ाइल सिस्टम में लिनक्स कर्नेल के समान तरीके से स्टोर करें।

क्या मैं इस परियोजना पर निर्भर करता है संस्करण नियंत्रण में डाल दिया:

• निर्माण श्रृंखला: मैं यह संस्करण नियंत्रण में डाल नहीं है जब मैं प्रदाता पर भरोसा या जब मैं पर्यावरण पुन: कर सकते हैं (एप्पल Xcode, ओपन-सोर्स टूल्स जैसे जीसीसी या डॉक्सिजन, ...)। मैंने इसे संस्करण नियंत्रण में रखा है जब यह विशेष रूप से प्रोजेक्ट के लिए समर्पित है (उदाहरण के लिए, घर से बना क्रॉस संकलन श्रृंखला) और जब मुझे डिलीवरी के लिए बनाया गया था तो बाइनरी को फिर से बनाने की आवश्यकता होती है (जब कोई घटक शामिल हो सकता है तो हेइज़नबग ढूंढने के लिए) ओएस या कंपाइलर के लिए कोड)।

Answer 8

मैं अपने पूरे टूलचेन के लिए स्रोत नियंत्रण का उपयोग कर रहा हूं। जैसा ऊपर बताया गया है, इसमें बहुत लाभ हैं:

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

मैंने ऑपरेटिंग सिस्टम के ऊपर कहीं रेखा खींची; मैं क्या प्रस्तुत की है में से कुछ है:

विंडोज

• प्लेटफार्म एसडीके (अब Windows SDK)
• Visual C++ Toolkit, तो बाद में विज़ुअल सी लाइसेंस प्राप्त ++, अब विंडोज एसडीके compilers भी शामिल है।

लिनक्स

• जीसीसी
• बनाने
• glibc

दोनों

• JDK

मुद्दों मैं यह करने की कोशिश करते हुए आई है में से कुछ इस प्रकार थे:

• Perl और जीसीसी की तरह लिनक्स बातों पर उनके निष्पादनयोग्य में अपने स्थापना निर्देशिका एम्बेड। इसका अर्थ यह है कि डेवलपर्स और बिल्ड मशीन में पोस्ट-चेकआउट स्क्रिप्ट है जो इन्हें बाइनरी में अपने पथ में झुकाकर अपडेट करने के लिए चलाने के लिए है।
• किसी भी प्लेटफ़ॉर्म पर आपके पास प्रत्येक शीर्षलेख और लाइब्रेरी निर्देशिका निर्दिष्ट करने के लिए एक बहुत लंबा और अधिक जटिल संकलन विकल्प सूची है; उस तरह की चीज एक "सामान्य" स्थापना के साथ स्वचालित है। उन चीजों में से एक जो स्पष्ट नहीं है कि crti.o और दोस्तों को कुछ ऐसा है जो /usr/lib में डिफ़ॉल्ट रूप से पाया जाता है और वास्तव में glibc-devel (या libc6-dev) के स्वामित्व में है, इसलिए यह glibc-devel स्थापित होने तक फाइल सिस्टम में नहीं है।
• विंडोज के लिए कंप्यूटर्स 2003 के बाद सभी साइड-बाय-साइड असेंबली का उपयोग करते हैं, इसलिए लक्ष्य मशीन पर एक इंस्टॉलेशन प्रक्रिया से बचने के लिए, मुझे उन्हें खोदना था और उन्हें स्रोत नियंत्रण में कंपाइलर एक्जिक्यूटिव के बगल में रखना था।
• कंप्यूटर्स (और सहायता/नमूने के बिना) के साथ विंडोज एसडीके v6.1 बड़ा है: 427 एमबी अगर मैं सही मानता हूं।

मैं Apache Ivy (Maven के समान) का उपयोग करने के लिए मुझे toolchain प्रबंधन में मदद करने के लिए प्रयास करने के लिए शुरू कर दिया है, लेकिन मैं अभी तक आइवी या Maven के किसी भी उदाहरण कुछ ऐसा है जो एक जावा नहीं है का प्रबंधन करने के प्रयोग किया जा रहा नहीं देखा है .jar फ़ाइल। मुझे नहीं पता कि मैं सी कंपाइलर जैसी चीज़ों को प्रबंधित करने में सक्षम हूं या नहीं।

आदर्श रूप में मैं या तो स्रोत नियंत्रण चेकआउट या आइवी या मेवेन को डेवलपर की फ़ाइल सिस्टम में उपयोग करने के लिए तैयार हर उपकरण और लाइब्रेरी का समाधान करना चाहता हूं। लेकिन मुझे लगता है कि डेवलपर को विंडोज़ एसडीके, या gcc और glibc-devel पैकेज जैसे कुछ महत्वपूर्ण चीजों को स्थापित करने की आवश्यकता है, यह इतना बुरा विचार नहीं है। जैसा ऊपर बताया गया है, यह 5 या 50 डेवलपर्स का सवाल है, और इस तरह के समाधान बनाने में शामिल समय है।