दैनिक बिल्ड कितना महत्वपूर्ण हैं? [बन्द है]

Question

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

Comments

जोएल को इसे "डेली बिल्ड एंड ऑटोमेटेड टेस्ट"

— पॉल

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

— व्याट बार्नेट

@WyattBarnett मैं पूरी तरह सहमत हूँ =) मैंने एक प्रोजेक्ट पर काम किया है जो कोड को हर 15 मिनट में बनाता है (जब तक कि गतिविधि की जाँच नहीं हो रही थी) और यह बहुत बढ़िया था।

— पैट्रिक ह्यूजेस

Answer 1

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

लक्ष्य यह पता लगाना है कि अंतिम परीक्षण चरण से पहले कोई निर्माण कब टूट जाए, उन्हें जल्द से जल्द ढूंढ लिया जाए।

बस अपनी मुख्य विकास शाखा (तों) के निर्माण के लिए इसे स्थापित करें।

हम इसे काम पर उपयोग करते हैं (हालांकि हम प्रति घंटा निर्माण करते हैं), और अक्सर जब हम इसे सेट-अप करना भूल जाते हैं तो हम रिलीज होने से कुछ घंटे पहले समस्याओं के बारे में पाते हैं।

Comments

दैनिक निर्माण और परीक्षण करें ।

— पॉल

@Paul: केवल अगर आप इसे अधिक बार नहीं कर सकते। हर कमिट पर ऐसा करना (अच्छी तरह से, कुछ हिस्टैरिसीस समय के साथ) अच्छा है।

— डोनल फेलो

Answer 2

इसमें थोड़ा सा जोड़ना होगा (और @GoodEnoughs):

लेकिन यह केवल वितरित संस्करण नियंत्रण के लिए एक मामूली उपद्रव की तरह लगता है।

सशर्त रूप से नहीं - एक "सर्वर" क्या करता है आपको बताता है कि आपका ट्रंक स्वच्छ से अधिक या कम समय में अपने परीक्षणों का निर्माण और उत्तीर्ण करेगा (कम से कम आपके पर्यावरण के लिए आवश्यक कॉन्फ़िगरेशन की मात्रा है)।

मैं डीवीसीएस पर स्विच करने पर विचार कर रहा हूं, लेकिन यहां तक ​​कि ऐसा करने से आप मेरे ठंडे मृत हाथों से मेरे निरंतर एकीकरण को खींच लेंगे।

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

दैनिक बिल्ड महत्वपूर्ण नहीं हैं। दैनिक बनाता है कि हमेशा सफल होते हैं (या जहां यह केवल एक घंटे के लिए टूट जाता है)। CI होने के बाद जब निर्माण टूट जाता है 70% समय बहुत उपयोगी नहीं होता है, क्योंकि अगर बात ज्यादातर टूट जाती है तो यह आपको एक त्रुटि की पहचान करने में मदद नहीं करता है।

Answer 7

मुझे लगता है कि स्टेजिंग सर्वर के लिए इसका दैनिक निर्माण, परीक्षण और तैनाती होनी चाहिए।

'डेली बिल्ड' के पीछे का विचार हमेशा कुछ तैयार करना होता है जो परीक्षक और परियोजना प्रबंधक चला सकते हैं ताकि सभी को इस बात का अंदाजा हो जाए कि परियोजना की वास्तविक स्थिति क्या है।

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