22

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

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

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

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

— Gigatron
स्रोत

3

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

— रामहाउंड 15

en.wikipedia.org/wiki/Continuous_integration

— SK-logic

5

निर्माण उपकरण उस पल के लिए फायदेमंद हो जाते हैं, जब आपके पास सौदा करने के लिए "सभी नवीनतम कोडों से मिलकर नवीनतम संस्करण" से अधिक है। आप अभी तक वहाँ नहीं हैं - जिस क्षण आप करते हैं, अपने निर्माण को वश में करते हैं।

8

यदि आप अभी क्या काम कर रहे हैं और आपको कोई समस्या नहीं है - तो बस आगे बढ़ें। "प्रीमेच्योर फ़िक्सिंग" शायद "प्रीमेच्योर ऑप्टिमाइज़ेशन" की तुलना में अधिक समस्याएं पैदा करता है। इसके अलावा आपके आईडीई शायद कवर के नीचे चींटी का उपयोग कर रहे हैं।

— जेम्स एंडरसन

1

बहुत ही वैध प्रश्न

— मधुर आहूजा '

11

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

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

किसी भी तरह, मैं इस मैनुअल ड्रगरी से छुटकारा पाने के लिए क्या करता हूं कि मैं अपनी परियोजना को मावेन के साथ बनाने के लिए कॉन्फ़िगर करता हूं, और मैं अपनी pom.xmlफ़ाइल को एक जावा वेब-ऐप के मामले में आवश्यक सभी जानकारी के साथ कॉन्फ़िगर और डाउनलोड करता हूं । Tomcat का सही संस्करण, इसे स्थानीय रूप से स्थापित करें, सही Tomcat कॉन्फ़िगरेशन फ़ाइलों को सेट करें, किसी भी प्रोजेक्ट निर्भरता और प्रोजेक्ट WAR फ़ाइल को स्वयं परिनियोजित करें, और तब Tomcat प्रारंभ करें। फिर मैं एक सरल शेल स्क्रिप्ट बनाता हूं (और .batविंडोज के लिए एक संस्करण भी ) जो सर्वर बनाने और शुरू करने के लिए मावेन का उपयोग करता है:

mvn clean install cargo:start -Dcargo.maven.wait=true

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

./startServer.sh #or startServer.bat for Windows

और उत्पादन वातावरण के लिए एक अद्यतन तैनात करने के लिए प्रक्रिया बस है:

चल रहे सर्वर उदाहरण को रोकें, यदि कोई हो।
भागो svn update -r<target_release_revision>।
भागो ./startServer.sh।

यह आसान है, याद रखना आसान है, और ऐसा करने के लिए बिल्कुल भी संभव नहीं है अगर मुझे मेरे लिए तैनाती योग्य बनाने के लिए अपनी आईडीई का उपयोग करने पर भरोसा करना था। यह अंतिम-ज्ञात अच्छे परिनियोजन को स्नैप करने के लिए पुन: प्रस्तुत करता है, कभी भी रोलबैक आवश्यक होना चाहिए।

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

और हां, आपके प्रश्न का एक और उत्तर स्वचालित निर्भरता प्रबंधन है, लेकिन मेरा मानना है कि यह पहले से ही अन्य उत्तरों द्वारा कवर किया गया है।

— aroth
स्रोत

1

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

— गीगाट्रॉन

7

जब तक आपका कोड स्रोत नियंत्रण में है, तब तक आपके वितरण को बनाने के लिए IDE का उपयोग करना ठीक है।

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

— नैट
स्रोत

7

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

— अरौथ

मैं सहमत हूँ कि एक व्यक्ति की दुकान पर ध्यान केंद्रित करने की आवश्यकता है। मैं आपके आधार पर असहमत हूं, हालांकि निर्माण उपकरण लंबी अवधि में समय बचा सकते हैं, दोनों को नई परियोजनाओं के लिए स्थापित करने और मौजूदा बनाए रखने या यहां तक कि ग्राहकों की मांग पर डिलिवरेबल्स का उत्पादन करने के लिए।

— हेयर स्टाइल

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

1

@ ओर्थ, लेकिन ओपी किसी भी समय "मैनुअल परिनियोजन / कॉन्फ़िगरेशन प्रबंधन" करने में कोई खर्च नहीं करता है, वह सिर्फ अपनी आईडीई में एक बटन दबाता है। तो यह किसी भी समय नहीं बचा होगा।

— एट्बी

1

आईडीई एक बिल्ड सिस्टम है। वरना मैं इसका इस्तेमाल नहीं करता।

— अर्ने एवरटसन

5

जब आप अकेले काम कर रहे हों, तो निश्चित रूप से, इसके लाभों को देखना कठिन है। व्यक्तिगत रूप से, मैंने बहुत सारी एकल परियोजनाओं पर काम किया है और न केवल मैं एक निर्माण स्क्रिप्ट लिखूंगा, मैं एक CI सर्वर (जैसे जेनकिंस) स्थापित करने की परेशानी से गुजरता हूं।

वहाँ निश्चित रूप से उपरि है, यह इसके लायक क्यों होगा?

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

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

मैंने इसे स्थापित करने में समय लिया (बिल्ड स्क्रिप्ट शायद 300 लाइनें हैं, इसे महीनों में नहीं छुआ है) और कह सकते हैं कि यह इसके लायक है, यहां तक कि एक व्यक्ति के लिए भी। एक से अधिक लोगों के लिए, यह आवश्यक है। बिल्ड / परिनियोजन प्रक्रिया में मेरी भागीदारी "hg प्रतिबद्ध" और "hg पुश" आदेशों के होते हैं।

— Kryptic
स्रोत

वास्तव में। असली बात यह है कि इस डेवलपर को विचार करना चाहिए एक अच्छा सीआई समाधान है, और एक निर्माण स्क्रिप्ट उन्हें वहां लाने में मदद कर सकती है।

— बिल माइकल

4

बिल्ड टूल्स के लाभ

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

वे आपके विकास के जीवन चक्र को सुविधाजनक बनाते हैं और जैसा कि वे आपको अनुमति देते हैं:

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

अगर हम इसे मावेन पर लागू करते हैं ...

जावा दुनिया में आप में से उन लोगों के लिए और जो मावेन का उपयोग करते हैं , इसे पढ़कर आप स्वाभाविक रूप से प्रत्येक बिंदु से जुड़े:

मावेन की संरचित परियोजना सम्मेलन
मावेन आर्केचेप्स
SCM और रिएक्टर से एक परियोजना का निर्माण
जेनकिंस / हडसन / बांस / अन्य समर्थन + एकीकरण परीक्षण प्रथाओं के लिए मावेन का समर्थन
m2eclipse, देशी IntelliJ या NetBeans समर्थन - या कमांड लाइन के लिए mvnsh
संस्करणों-Maven-प्लगइन
मावेन-रिलीज़-प्लगइन, बिल्डनंबर-मावेन-प्लगइन प्लगइन और संस्करण-मावेन-प्लगइन

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

सब कुछ सापेक्ष:

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

— haylem
स्रोत

3

निर्माण उपकरण का उपयोग करने के लिए मेरे शीर्ष 4 कारण यहां दिए गए हैं:

निर्भरता से निपटने (त्रुटियों से बचें)
परीक्षण (आपके परिवर्तन से अन्य मॉड्यूल नहीं टूटे - परीक्षण करने में बहुत आसान)
सुरक्षित है
स्थानीय वितरण योग्य तैनात करने में आसान (अपनी परियोजना और इसकी निर्भरता बनाने के लिए बिल्डर की प्रतीक्षा करने के लिए QA env में किसी के पास समय नहीं है)

1

विशेष रूप से निर्भरता से निपटने। मैं बाहरी पुस्तकालयों को डाउनलोड करने और जोड़ने के लिए बहुत आलसी हूं। बहुत सरल बस एक निर्भरता के रूप में उन्हें जोड़ने के लिए। "गलत संस्करण? कॉन्फ़िगरेशन में संस्करण बदलें और पुनर्निर्माण करें!"

हां, लेकिन वास्तव में सभी निर्माण उपकरणों के लिए पूर्व-निर्भरता से निपटने की निर्भरता नहीं। मावेन, ग्रैडल, आइवी इसका समर्थन करते हैं। चींटी, मेक, आदि ... नहीं।

— केश विन्यास

2

प्रैगमैटिक प्रोग्रामर की किताब में एंड्रयू हंट और डेविड थॉमस कहते हैं कि 'चेकआउट-बिल्ड-टेस्ट-परिनियोजन' के लिए एक ही कमांड होना चाहिए। (अध्याय: प्रैग्मैटिक प्रोजेक्ट्स)। आप ने लिखा..

मेरे पास संभावित निवेशक भी हैं और अगले कुछ हफ्तों में उन्हें बीटा संस्करण दिखाने की योजना है

फिर, मुझे यकीन है कि आपकी टीम बढ़ने जा रही है .. स्वचालित परीक्षण-परिनियोजन क्षमताओं का होना और भी महत्वपूर्ण है।

आपके द्वारा देखा गया बड़ा XML (स्क्रिप्ट), आमतौर पर एक बार का काम है। अधिकांश समय, एक ही स्क्रिप्ट का उपयोग कई परियोजनाओं में किया जा सकता है।

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

— जयन
स्रोत

1

मेरा तर्क है कि, एक अकेला डेवलपर के लिए, स्क्रिप्टेड बिल्ड जैसी अच्छी प्रक्रिया और संरचना होना बहुत महत्वपूर्ण है जब आप किसी टीम में हों। जब आप कोनों को काटते हैं, तो आपको टीम से बाहर करने का कारण नहीं होता। आपके निर्माण की स्क्रिप्ट चलाने वाला एक CI सर्वर आपको ईमानदार बनाए रखने के लिए एक शानदार समझौता करने वाला बनाता है।

— व्याट बार्नेट
स्रोत

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

— इलियास

0

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

— tripleee
स्रोत

1

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

0

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

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

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

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

हालांकि अंतिम कारण यह है कि यह कुछ ऐसा है जिसे मैन्युअल रूप से करने की आवश्यकता नहीं है, इसलिए इसे मैन्युअल रूप से न करें। बाकी सब उसी से निकलता है।

— रिकी क्लार्कसन
स्रोत

IDE वन-क्लिक बिल्ड के बजाय एक अलग बिल्ड टूल का उपयोग करने के लिए एक अकेला डेवलपर को मनाएं

बिल्ड टूल्स के लाभ

अगर हम इसे मावेन पर लागू करते हैं ...