किसी आईडीई के हिस्से के रूप में शामिल किए गए निर्माण प्रणाली का उपयोग क्यों करना चाहिए?

Question

मैंने सुना है कि एक से अधिक व्यक्ति कहते हैं कि यदि आपकी बिल्ड प्रक्रिया बिल्ड बटन पर क्लिक कर रही है, तो आपकी बिल्ड प्रक्रिया टूट गई है। अक्सर make, cmake, nmake, MSBuild, आदि जैसी चीजों का उपयोग करने के लिए सलाह के साथ सलाह दी जाती है। इन औजारों में वास्तव में एक अलग कॉन्फ़िगरेशन फ़ाइल को बनाए रखने का औचित्य क्या है?

संपादित करें: मुझे उन उत्तरों में सबसे अधिक दिलचस्पी है जो ~ 20k लाइन सी ++ प्रोजेक्ट पर काम कर रहे एक डेवलपर पर लागू होंगे, लेकिन मुझे सामान्य मामले में भी रूचि है।

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

Answer 1

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

सचमुच, जब तक कि आपके पास अपने स्रोत नियंत्रण प्रणाली पर बहुत से डेवलपर नहीं हैं, या साझा पुस्तकालयों पर भरोसा करने वाले बहुत सारे सिस्टम या एप्लिकेशन हैं और सीआई करने की आवश्यकता है, तो बिल्ड स्क्रिप्ट का उपयोग करना संभवतः सरल विकल्पों की तुलना में अधिक है। लेकिन यदि आप उन उपरोक्त स्थितियों में से एक हैं, तो एक समर्पित बिल्ड सर्वर जो स्रोत नियंत्रण से खींचता है और स्वचालित बनाता है, आपकी टीम के शस्त्रागार का एक अनिवार्य हिस्सा होना चाहिए, और एक सेट अप करने का सबसे आसान तरीका make, MSBuild, Ant का उपयोग करना है , आदि

Answer 2

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

Answer 3

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

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

यहां एक और अच्छी चीज भी है। हमारी प्रक्रिया सभी एसक्यूएल स्क्रिप्ट्स का परीक्षण करने के लिए भी सेट है। बिल्ड बटन दबाकर ऐसा नहीं कर सकता। यह उन सभी डेटाबेसों के स्नैपशॉट को पुनः लोड करता है जिन्हें पैच लागू करने की आवश्यकता होती है और यह सुनिश्चित करने के लिए उन्हें चलाया जाता है कि वे सभी काम करते हैं, और क्रम में चलाए जाते हैं। बिल्ड सर्वर सभी यूनिट परीक्षण/स्वचालन परीक्षण चलाने और परिणामों को वापस करने के लिए पर्याप्त स्मार्ट है। यह सुनिश्चित करना कि यह संकलित हो सकता है ठीक है, लेकिन एक स्वचालन सर्वर के साथ, यह स्वचालित रूप से कई चरणों को संभाल सकता है जो एक व्यक्ति को शायद एक घंटे का समय लगेगा।

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

Answer 4

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

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

तो आप स्क्रिप्ट तैयार करते हैं जो आपके आईडीई बिल्ड का विस्तार करते हैं और अतिरिक्त करते हैं।

Answer 5

आईडीई-प्रबंधित बिल्ड विवरण हमेशा आदर्श नहीं होते हैं संस्करण नियंत्रण और अन्य डेवलपर्स (यानी विलय) द्वारा किए गए परिवर्तनों के साथ एकीकृत करने की आवश्यकता के साथ एक व्यावहारिक कारण है।

यदि आपका आईडीई एक एकल फ्लैट फ़ाइल का उपयोग करता है, तो यह दो परियोजना फ़ाइलों को एक में विलय करने के लिए बहुत कठिन (यदि असंभव नहीं है) हो सकता है। यह एक टेक्स्ट-आधारित प्रारूप का उपयोग कर सकता है, जैसे कि एक्सएमएल, लेकिन एक्सएमएल यह मानक diff/मर्ज टूल्स के साथ कुख्यात रूप से कठिन है। सिर्फ तथ्य यह है कि लोग संपादन करने के लिए जीयूआई का उपयोग कर रहे हैं, यह संभावना है कि आप परियोजना फ़ाइलों में अनावश्यक परिवर्तनों को समाप्त कर दें।

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

Answer 6

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

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

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

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