नाइटली बिल्ड: मुझे ऐसा क्यों करना चाहिए?

Question

मुझे क्यों नाइटली बिल्ड करना चाहिए?

Answer 1

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

यदि आपके पास एक छोटी परियोजना है तो आपका निर्माण और परीक्षण का समय छोटा होगा ताकि आप शायद अधिक नियमित निर्माण कर सकें।

Answer 2

अच्छा ... मुझे लगता है कि यह आपके प्रोजेक्ट पर बहुत निर्भर करता है। यदि यह सिर्फ आपकी शौक परियोजना है, बिना रिलीज़, कोई निर्भरता, और कोई भी नहीं, लेकिन आप कोड सबमिट करते हैं, तो यह अधिक हो सकता है।

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

निश्चित रूप से अन्य संभावित लाभ हैं, मुझे यकीन है कि अन्य उन्हें आपूर्ति करेंगे। :)

Answer 3

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

Answer 4

मुझे लगता है कि वे विशेष रूप से 1 से अधिक व्यक्तियों के साथ परियोजनाओं पर बहुत महत्वपूर्ण हैं। टीम यथाशीघ्र पता करने के लिए अगर किसी की जरूरत है: एक बुरा फ़ाइल में

• चेकों
• एक फ़ाइल
• में जांच नहीं करता है ...

Answer 5

आप हर रात को क्या करना चाहिए यह सुनिश्चित करें कि बनाता है आपका कोडबेस स्वस्थ रहता है।

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

स्वचालित बनाता निम्न समस्याओं को ढूँढने में अच्छे हैं:

• किसी ने कुछ ऐसा है जो सामान टूट जाता है में जाँच की।
• कोई आवश्यक फ़ाइल या परिवर्तन में चेक करना भूल गया।
• आपकी बिल्ड स्क्रिप्ट अब काम नहीं करती हैं।
• आपकी बिल्ड मशीन टूटा हुआ है।

इस रात ऐसा करने से यह सुनिश्चित होता है कि जब आप होते हैं तो 24 घंटे के भीतर आप ऐसी समस्याओं को पकड़ते हैं। सॉफ़्टवेयर वितरित करने से 24 घंटे पहले सभी समस्याओं को ढूंढना बेहतर है।

आपको निश्चित रूप से स्वचालित इकाई परीक्षण भी करना चाहिए जो प्रत्येक रात के निर्माण के लिए चलाए जाते हैं।

Answer 6

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

Answer 7

मैं व्यक्तिगत रूप से निरंतर एकीकरण पाया है रात की तुलना में बेहतर होने के लिए सिर्फ इतना है कि आप जानते हैं कि सब कुछ है कि बनाता है:
http://en.wikipedia.org/wiki/Continuous_integration

मैं इसे एक व्यक्ति परियोजनाओं पर भी उपयोग करता हूं, यह आश्चर्यजनक है कि आप मुद्दों का पर्दाफाश कैसे कर सकते हैं और वहां उनकी देखभाल कर सकते हैं।

Answer 8

आप वास्तव में नहीं चाहते हैं कि आपको क्या करना चाहिए, निरंतर एकीकरण और स्वचालित परीक्षण (जो रात के निर्माण से एक कदम आगे है)।

यदि आपको कोई संदेह है तो आपको this article by Martin Fowler about Continuous Integration पढ़ना चाहिए।

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

Answer 9

मैं वास्तव में हर बार जांच करने की सलाह देता हूं। दूसरे शब्दों में, मैं एक निरंतर एकीकरण प्रणाली स्थापित करने की सिफारिश करता हूं।

ऐसी प्रणाली और अन्य विवरणों के फायदे in Fowler's article और on the Wikipedia entry अन्य स्थानों के साथ मिल सकते हैं।

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

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

Answer 10

किसी भी निर्माण स्वचालन, मैं पसंद नहीं निर्माण स्वचालन :-)

व्यक्तिगत रूप से बेहतर है दैनिक बनाता है - इस तरह से करता है, तो निर्माण तो काम नहीं करता है हर कोई यह मिल तय करने के लिए चारों ओर है।

असल में, यदि संभव हो तो निरंतर एकीकरण का निर्माण करने का तरीका है (यानी प्रत्येक चेक-इन पर निर्माण) क्योंकि यह निर्माण के बीच परिवर्तन की मात्रा को कम करता है और इसलिए यह बताने में आसान बनाता है कि किसने तोड़ दिया निर्माण और निर्माण को ठीक करने में भी आसान है।

Answer 11

इसके कई कारण हैं, कुछ दूसरों की तुलना में अधिक लागू होगा

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

Answer 12

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

Answer 13

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

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

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

Answer 14

मैं 16 वर्षों के लिए निर्माण इंजीनियरिंग (अन्य चीजों के साथ) कर रहा हूं। मैं निर्माण-प्रारंभिक, निर्माण-अक्सर, निरंतर एकीकरण में एक मजबूत आस्तिक हूं। तो एक परियोजना के साथ पहली चीज यह है कि यह कैसे बनाया जाएगा (जावा: Ant या Maven; .NET: NAnt या MSBuild) और यह कैसे प्रबंधित किया जाएगा (Subversion या कुछ अन्य संस्करण नियंत्रण)। फिर मैं प्लेटफार्म के आधार पर निरंतर एकीकरण (CruiseControl या CruiseControl.NET) जोड़ूंगा, फिर अन्य डेवलपर्स को ढीला कर दें।

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

है यही कारण है कि मैं क्या कर - यहाँ क्यों मुझे क्या करना है यह (और क्यों आपको चाहिए भी):

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

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

Answer 15

आपके उत्पाद की निरंतरता की जटिलता के आधार पर निरंतर एकीकरण पूर्ण परीक्षण सूट चला सकता है या नहीं भी हो सकता है।

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

Answer 16

जब मैंने यह प्रश्न देखा, तो मैंने पहले Joel Spolsky's उत्तर खोजा। बिट निराश, इसलिए मैंने इसे यहां जोड़ने की योजना बनाई।

आशा है कि सभी को Joel Test on Careers के बारे में पता है।

The Joel Test: 12 Steps to Better Code

3. अपने ब्लॉग से आप दैनिक बनाता है बनाने के लिए?

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

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

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

हालांकि मुझे दैनिक निर्माण करने का अवसर नहीं मिला है, इसलिए मैं इसका एक बड़ा प्रशंसक हूं।

अब भी आश्वस्त नहीं? Daily Builds Are Your Friend!!