संस्करण टू बिल्ड टूल्स और लाइब्रेरीज़ को कैसे नियंत्रित करें?

Question

अपने स्रोत नियंत्रण प्रणाली में अपने कंपाइलर, पुस्तकालयों, और अन्य उपकरणों को शामिल करने के लिए क्या सिफारिशें हैं?

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

विकल्प मैं माना जाता है में शामिल हैं:

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

यह कॉन्फ़िगरेशन प्रबंधन का एक बुनियादी विचार प्रतीत होता है, लेकिन मैं इसे कैसे करना है इसके लिए किसी भी संसाधन को ट्रैक करने में असमर्थ रहा हूं। सुझाव क्या हैं?

Answer 1

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

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

Answer 2

मुझे लगता है कि वीएम आपका सबसे अच्छा समाधान है। हम हमेशा स्थिरता प्राप्त करने के लिए समर्पित निर्माण मशीनों का इस्तेमाल करते थे। पुराने COM DLL Hell दिनों में, गैर-विकास सॉफ़्टवेयर स्थापित (Office) पर निर्भरताएं (COMCAT.DLL, किसी भी) पर निर्भर थीं। आपके पहले दो विकल्प COM घटकों को साझा करने वाले किसी भी चीज़ को हल नहीं करते हैं। यदि आपके पास कोई साझा घटक समस्या नहीं है, तो शायद वे काम करेंगे।

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

Answer 3

क्या आप अपने निर्माण करने के लिए NANT जैसे निरंतर एकीकरण (सीआई) टूल का उपयोग कर रहे हैं?

नेट उदाहरण के रूप में, आप प्रत्येक निर्माण के लिए विशिष्ट रूपरेखा निर्दिष्ट कर सकते हैं।

शायद जो कुछ भी आप विकसित कर रहे हैं उसके लिए लोकप्रिय सीआई उपकरण में विकल्प हैं जो आपको अपने संस्करण नियंत्रण प्रणाली में कई आईडीई संग्रहीत करने से बचने की अनुमति देंगे।

Answer 4

मैं निश्चित रूप से विचार के आस-पास के कानूनी/लाइसेंसिंग मुद्दों पर विचार करता हूं। क्या आपके टूलचेन के विभिन्न लाइसेंसों के अनुसार यह अनुमति होगी?

क्या आपने एक नई विकास मशीन भूत को माना है जो रिलीज बनाने में सक्षम है, अगर आपको वीएम छवि का विचार पसंद नहीं है? बेशक, हार्डवेयर परिवर्तन के रूप में चल रही उस भूतित छवि को रखने से यह अधिक मूल्यवान हो सकता है ...

Answer 5

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

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

Answer 6

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

Answer 7

मेरे अपने प्रश्न के बाद, मैं this posting पर एक और प्रश्न के उत्तर में संदर्भित आया। हालांकि एक एवर की तुलना में इस मुद्दे की अधिक चर्चा के दौरान, यह वीएम विचार का उल्लेख करता है।

Answer 8

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

एक अनुरोध दास के लिए 'उपयुक्त' है यदि उसकी टूलचैन आवश्यकताओं दास पर टूलचेन संस्करणों से मेल खाता है - जिसमें ओएस भी शामिल है, क्योंकि उत्पाद बहु-मंच है और एक निर्माण स्वचालित परीक्षण शामिल कर सकता है। आम तौर पर यह "कला की वर्तमान स्थिति" है, लेकिन यह नहीं होना चाहिए।

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

गुलामों को वीएम नहीं होना चाहिए, लेकिन आमतौर पर होते हैं। दासों की संख्या (और वे जिस भौतिक मशीनों पर चल रहे हैं) को मांग को पूरा करने के लिए स्केल किया जा सकता है। गुलामों को किसी भी समय सिस्टम में जोड़ा जा सकता है, या टूलचैन दुर्घटनाग्रस्त होने पर नियुक्त किया जा सकता है। यह वास्तव में टूलचैन की स्थिति को संग्रहीत करने के साथ आपकी समस्या के बजाय इस योजना का मुख्य बिंदु है, लेकिन मुझे लगता है कि यह लागू है।

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

Answer 9

अपने संस्करण नियंत्रण प्रणाली में पुस्तकालयों की versionning पर बस एक ध्यान दें:

• यह एक अच्छा समाधान लेकिन है यह पैकेजिंग का तात्पर्य (यानी कम से कम है कि पुस्तकालय की फ़ाइलों की संख्या को कम करने)
• यह 'कॉन्फ़िगरेशन पहलू' को हल नहीं करता है (यानी "पुस्तकालयों का मेरा विशिष्ट सेट मेरी '3.2' परियोजनाओं की आवश्यकता है?")।
  यह न भूलें कि सेट आपके प्रोजेक्ट के प्रत्येक नए संस्करण के साथ विकसित होगा। यूसीएम और इसकी 'समग्र बेसलाइन' इसके लिए उत्तर की शुरुआत दे सकती है। ,
  • आप (गतिशील दृश्य हालांकि) की तरह नेटवर्क के माध्यम से अपने पुस्तकालयों का उपयोग नहीं करना चाहते क्योंकि संकलन समय है:

  पैकेजिंग पहलू (फ़ाइलों की न्यूनतम संख्या) क्योंकि महत्वपूर्ण है जब आप स्थानीय एक्सेस लाइब्रेरी फ़ाइलों का उपयोग करते हैं तो उससे काफी लंबा।

• आप उन लाइब्रेरी को अपनी डिस्क पर प्राप्त करना चाहते हैं, जिसका अर्थ है स्नैपशॉट व्यू, जिसका अर्थ है उन फ़ाइलों को डाउनलोड करना ... और यह वह जगह है जहां आप अपने पुस्तकालयों की पैकेजिंग की सराहना कर सकते हैं: कम फ़ाइलों को डाउनलोड करना है, बेहतर आप हैं ;)