2009-03-04 11 views
20

मैं चींटी का बहुत कुछ संदर्भ देखता हूं लेकिन मुझे यह बिल्कुल सही नहीं लगता है कि इसका क्या अर्थ है? जो मैंने सुना है, उससे आपकी परियोजनाओं को संकलित करने के लिए यह माना गया है, लेकिन क्या मैं इसे ग्रहण में चलाएं-> चलाएं क्लिक करके बस ऐसा नहीं कर सकता?निर्माण स्वचालन सॉफ्टवेयर क्या है (उदाहरण के लिए, चींटी)?

संपादित करें: मुझे लगता है कि मुझे अपना प्रश्न दोबारा शुरू करना चाहिए। मुझे पहले से ही पता है कि चींटी एक 'ऑटोमेशन सॉफ्टवेयर बनाएं' है, मेरा सवाल यह है कि, ऑटोमेशन का निर्माण वास्तव में क्या है? मैंने सोचा था कि आपको अपने ऐप का परीक्षण करना होगा, और जब यह चल रहा है तो आप ग्रहण में या कमांड लाइन जावा के माध्यम से 'बिल्ड' बटन पर क्लिक करें, और यह इसमें से .jar फ़ाइल बनाता है? तो आपको इस प्रक्रिया को 'स्वचालित' करने की आवश्यकता क्यों है?

+0

शीर्षक को बदल दिया गया है क्योंकि क्लिक अपवॉट सामान्य रूप से ऑटोमेशन बनाने के बारे में अधिक जानकारी के लिए और विशेष रूप से चींटी नहीं है। – Dana

+0

@ दाना: जिस तरह से आप शीर्षक बदलते हैं, यह एक बिल्कुल अलग सवाल बनाते हैं। यह "क्लिक अपवॉट" – OscarRyz

+0

के प्रारंभिक इरादे को प्रतिबिंबित नहीं करता है, ठीक है, मुझे लगता है कि यह उसके इरादे को दर्शाता है, लेकिन यदि नहीं तो वह हमेशा वापस आ सकता है। – Dana

उत्तर

20

मुझे पहले से ही पता है कि चींटी एक 'ऑटोमेशन सॉफ्टवेयर बनाएं' है, मेरा सवाल यह है कि वास्तव में स्वचालन का निर्माण क्या है? मैंने सोचा था कि आपको अपने ऐप का परीक्षण करना होगा, और जब यह चल रहा है तो आप ग्रहण में या कमांड लाइन जावा के माध्यम से 'बिल्ड' बटन पर क्लिक करें, और यह इसमें से .jar फ़ाइल बनाता है? तो आपको इस प्रक्रिया को 'स्वचालित' करने की आवश्यकता क्यों है?

नहीं सभी जावा विकास ग्रहण के माध्यम से किया जाता है और सभी जार कमांड लाइन से बनाया जा सकता है (या कमांड लाइन से बनाया जाना चाहिए)।

आपको अतिरिक्त परीक्षण मामलों, यूनिट परीक्षण, और कई अन्य प्रक्रियाओं की आवश्यकता हो सकती है।

क्या चींटी करता है, यह सब काम स्वचालित करने के लिए एक तंत्र प्रदान करता है (इसलिए आपको हर बार ऐसा करने की ज़रूरत नहीं है) और शायद आप प्रति दिन 6 पीएम पर इस चींटी स्क्रिप्ट को बुला सकते हैं।

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

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

बेशक अन्य परियोजनाओं के लिए यह अधिक है, लेकिन कुछ अन्य लोगों के लिए बहुत उपयोगी है।

5

चींटी सॉफ्टवेयर निर्माण की प्रक्रिया को स्वचालित करने के लिए है:

http://en.wikipedia.org/wiki/Apache_Ant

+11

जब कोई विकिपीडिया पर एक उत्तर पर एक लिंक पोस्ट करता है तो मुझे इससे नफरत है। क्या आपको नहीं लगता कि मैंने यहां पोस्ट करने से पहले ही जांच कर ली होगी? –

+2

@ क्लिक करें: जरूरी नहीं - निश्चित रूप से आपके मूल प्रश्न में इसका सबूत नहीं था। शीर्षक के अनुसार प्रश्न का उत्तर "निर्माण प्रक्रियाओं को स्वचालित करने के लिए" है। यह देखते हुए कि "एक बटन क्लिक करना" * स्वचालन नहीं है, मैं यह देखने में असफल रहा कि यह जवाब बिल्कुल किस तरह से खराब है। –

+0

@ क्लिक करें उपरोक्त: छोटे आश्चर्य, लेकिन मैं @ जोन स्कीट से सहमत हूं; आपका प्रश्न त्रुटिपूर्ण था और हर संकेत दिखाया कि आपने इस विषय पर बुनियादी शोध भी नहीं किया है। @regoeriopvl निश्चित रूप से अपने संक्षिप्त और सटीक उत्तर के लिए आक्रामक ध्वज के लायक नहीं है। – Randolpho

-1

ग्रहण के निर्माण के लिए चींटी का उपयोग कर, चल रहा है,, की तैनाती है ...

"चींटी एक जावा आधारित निर्माण उपकरण है में। सिद्धांत, यह मेक की तरह है, मेक की झुर्रियों के बिना और शुद्ध जावा कोड की पूर्ण पोर्टेबिलिटी के साथ। " (link text

+0

ग्रहण अधिकांश कार्यों के लिए चींटी का उपयोग नहीं करता है। Netbeans वह है जो सब कुछ के लिए चींटी का उपयोग करता है। –

16

rogeriopvl बिल्कुल सही है, लेकिन जवाब देने के लिए "क्या मैं सिर्फ रन-> ग्रहण में भागकर क्लिक करके ऐसा नहीं कर सकता?" प्रश्न: यह एक परियोजना के लिए ठीक है जिसे आप स्वयं पर काम कर रहे हैं , और कई वातावरण में एक दोहराने योग्य, स्क्रिप्ट योग्य निर्माण की आवश्यकता नहीं है।

यदि आप ओपन सोर्स प्रोजेक्ट पर काम कर रहे हैं, या पेशेवर सॉफ्टवेयर जो बिल्ड सर्वर पर निर्माण करने में सक्षम होना आवश्यक है, तो एक की आवश्यकता है विशेष आईडीई चलाना एक अच्छा विचार नहीं है।

+2

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

2

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

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

चींटी भी नियमित रूप से स्वचालित बनाता है के लिए इस्तेमाल किया जा सकता है (आप नहीं, है ना? :-) हर रात ग्रहण में चलाएँ हिट करने के लिए चाहते हो जाएगा)

0

तुम भी "" Export ant buildfile "की बात कर रहे।

आप ग्रहण के बाहर अपने आवेदन के निर्माण के लिए अपनी खुद की चींटी स्क्रिप्ट लिखने हैं, तो आप अपने खुद के लक्ष्य है कि Ant task का उपयोग उत्पन्न build.xml

इसके अलावा प्रतिनिधि को लिख सकते हैं, तो आप एक परियोजना की 'कॉन्फ़िगर कर सकते हैं बिल्डर्स ' (project properties » Builders) किसी भी स्क्रिप्ट (चींटी या अन्यथा) को चलाने के लिए जब आप प्रोजेक्ट बनाते हैं, मैन्युअल रूप से या स्वचालित रूप से चाहते हैं।

4

चींटी सीआरआईएसपी (पूर्ण, दोहराने योग्य, सूचनात्मक, शेड्यूल करने योग्य, पोर्टेबल) बनाता है। आप इस presentation में माइक क्लार्क द्वारा और Pragmatic Project Automation में अपनी पुस्तक में बहुत अच्छी जानकारी प्राप्त कर सकते हैं।

7

कई बड़ी कंपनियों (और संभवतः कुछ छोटे वाले) में, आप पाएंगे कि उत्पादन कोड उन लोगों द्वारा नहीं बनाया गया है जिन्होंने इसे विकसित किया है।इसके बजाए, डेवलपर अपने कोड को स्रोत कोड भंडार में देख सकते हैं और इसे टैग कर सकते हैं। फिर वे इस टैग को एक बिल्ड टीम को देते हैं।

बिल्ड टीम, एक अलग (साफ) क्षेत्र में - संभवतः कुछ हेडलेस सर्वर (यानी कोई जीयूआई नहीं) पर - फिर कोड को जांचकर एक बिल्ड स्क्रिप्ट चलाएगी। बिल्ड स्क्रिप्ट डेस्कटॉप वातावरण/आईडीई से पूरी तरह से स्वतंत्र होगी।

यह सुनिश्चित करता है कि किसी भी डेवलपर के कंप्यूटर पर होने वाला कुछ भी निर्माण "प्रदूषण" नहीं कर रहा है। (या, अधिक संभावना है, स्रोत नियंत्रण के बाहर कुछ भी नहीं प्रणाली काम करने के लिए आवश्यक है!)

तो सबसे सॉफ्टवेयर का उपयोग करें, कभी एक डेवलपर के डेस्कटॉप से ​​निर्माण किया जा कभी नहीं होगा।

पीएस। आप Continuous Integration

+0

यह उत्तर बहुत उपयोगी है। कुछ प्रश्न पढ़ने के दौरान मेरे दिमाग में आता है यह जवाब –

+0

जावा डेवलपर के रूप में मैं अपनी परियोजनाओं के लिए किसी भी निर्माण स्वचालन उपकरण (जैसे चींटी या मेवेन या ग्रेडल) का उपयोग नहीं करना चाहता हूं। तो स्वचालन उपकरण बनाने के लिए मुझे क्या प्रोजेमिंग भाषा सीखनी चाहिए? –

6

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

और अब लंबे उत्तर के लिए ... मुझे एक स्वतंत्र निर्माण के बिना किसी भी परियोजना में लाया गया है। एक परियोजना पर, एक ऐसा व्यक्ति था जो डेवलपर नहीं था जिसे सॉफ़्टवेयर के निर्माण और तैनाती के साथ काम किया गया था। उन्होंने प्रत्येक ईजेबी, प्रत्येक सर्वलेट और प्रत्येक क्लाइंट घटक को संकलित करने के लिए 147 अलग-अलग विंडोज बैच फाइलें बनाई थीं। इस निर्माण के लिए कोई त्रुटि जांच नहीं हुई थी। त्रुटि संदेश समेत सभी लॉग संदेश मानक आउट हो गए। इस लॉग को पढ़कर मैन्युअल रूप से पहचानने के लिए उनके ऊपर निर्भर था कि अपवाद या संदेश मुद्रित सामान्य था और कौन सा संदेश एक त्रुटि थी। उन्हें अभी भी इस सॉफ्टवेयर को तैनात करना पड़ा था। तैनाती उतनी ही जटिल थी क्योंकि कई भार-संतुलित स्तर थे। प्रत्येक मॉड्यूल को डाउनस्ट्रीम और अपस्ट्रीम टायर से मेल खाने के लिए विकल्प सेटअप के साथ मैन्युअल रूप से सही जगह पर रखा जाना था। इस सॉफ़्टवेयर को बनाने और तैनात करने से उसे इस विधि का उपयोग करके कम से कम 3 दिन लगे। बेशक, केवल तब ही कोई यह निर्धारित कर सकता है कि निर्माण "काम" करता है या नहीं। आम तौर पर, इस अवधि के बाद सभी प्रोग्रामर निर्माण को डीबग करने के लिए डरावना होगा। प्रोग्रामर कहेंगे कि मेरा मॉड्यूल मेरे आईडीई में ठीक काम करता है। मैं बस इस तरह से रन क्लिक करें, देखते हैं?

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

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

11

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

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

  • संकलित कोड
  • उपयोग संस्करण नियंत्रण नवीनतम संस्करण चेकआउट करने के लिए या संस्करण टैग करने के लिए बनाया जा रहा: चींटी भी प्रवाह नियंत्रण (यदि, आदि)

    कुछ बातें मैं चींटी करते देखा है शामिल

  • भागो एसक्यूएल स्क्रिप्ट का निर्माण या एक परीक्षण डेटाबेस
  • कॉपी फ़ाइलें एक बाहरी संसाधन से शामिल करने के लिए एक परियोजना में
  • बंडल कोड एक जार, युद्ध या कान फ़ाइल
  • में पुनर्निर्माण के लिए
  • एक आवेदन सर्वर
  • पुनरारंभ एक आवेदन सर्वर
  • के लिए वेब एप्लिकेशन तैनात एक टीम के लिए टेस्ट स्वीट
  • स्टेटिक विश्लेषण, अर्थात CheckStyle या PMD
  • संदेश ईमेल निष्पादित उन्हें एक निर्माण को सचेत करने के लिए।
  • बिल्ड से जानकारी के आधार पर फ़ाइलों को जेनरेट करें।
    • उदाहरण: मेरे पास मेरे ऐप में एक jsp है जो संस्करण/निर्माण जानकारी प्रदर्शित करने के अलावा कुछ भी नहीं करता है। जब मैं एक बिल्ड चलाता हूं तो यह चींटी द्वारा उत्पन्न होता है, और उत्पादन ऑपरेशन टीम इस पृष्ठ को जांचती है जब वे यह सुनिश्चित करने के लिए आवेदन करते हैं कि उन्होंने सही निर्माण को तैनात किया है।
2

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

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

तेज़ क्योंकि चीजें बिना किसी मानव के लिए घूमने के इंतजार किए बिना तुरंत होती हैं।

बेहतर क्योंकि कंप्यूटर हर समय एक ही तरीके से वास्तव में वास्तव में अच्छा होता है। (मनुष्य उस पर चूसने लगते हैं।)

सस्ता क्योंकि आपके पास कम गलती है और जो गलतियां होती हैं उन्हें जल्द से जल्द पकड़ा जाता है और इसलिए इसे ठीक करने के लिए सस्ता होता है।

0

जोएल (स्पॉल्स्की) में a great article "जोएल टेस्ट" पर है। उनमें से कई महत्वपूर्ण चीजें अक्सर, जल्दी और भरोसेमंद करने में सक्षम होने के आसपास घूमते हैं। उन चीजों में से एक तुम्हारा निर्माण है।

संबंधित मुद्दे