यदि आप एक एकल परियोजना कर रहे हैं - तो क्या आप रिपॉजिटरी से निर्माण के लिए CI टूल्स का उपयोग करेंगे? मैंने एक टीम के माहौल में हडसन और क्रूज़ कंट्रोल का उपयोग किया है, जहां किसी को भी कुछ भी चेक करने के लिए जल्द से जल्द निर्माण करना आवश्यक है।
मुझे लगता है कि संस्करण नियंत्रण का मूल्य अभी भी स्पष्ट है, लेकिन क्या मुझे हर प्रतिबद्ध के बाद निर्माण करने की आवश्यकता है, जैसा कि मैंने अभी अपने स्थानीय मशीन पर बनाया होगा, और कोई और नहीं कर रहा है?
जवाबों:
वैसे मैं एक परियोजना पर एक निरंतर एकीकरण उपकरण का उपयोग करने की योजना बना रहा हूं और मैं अद्वितीय डेवलपर हूं। जरूरत इसीलिए आती है
क्रॉस-प्लेटफॉर्म और टीम-वर्क तैयारी के अलावा, मुझे इसकी आवश्यकता नहीं है। मुख्य बात यह है कि कुछ प्रकार के स्रोत नियंत्रण सॉफ़्टवेयर हैं और बैकअप रखने के लिए कई भंडार हैं। यह आपको जरूरत पड़ने पर इसके आसपास उपकरण बनाने में मदद करेगा।
बिल्ड टाइमिंग के बारे में, मैं मर्क्यूरियल का उपयोग कर रहा हूं और एक एकीकरण रिपॉजिटरी स्थापित कर रहा हूं जो टीमवर्क रिपॉजिटरी नहीं है। इसलिए, जब तक मुझे लगता है कि एकीकरण प्रणाली बनाने का प्रयास करने का समय है, तब तक टीमवर्क रेपो में बदलावों को आगे बढ़ाएं। फिर मैं टीमवर्क रेपो से एकीकरण रेपो तक धक्का देता हूं और इससे बिल्ड को ट्रिगर किया जाएगा। फिर मैं एक स्क्रिप्ट भी जोड़ता हूं, जो एक दिन में एक बार एकीकरण रेपो में टीमवर्क रेपो खींचेगा।
यहां मैं मान रहा हूं कि मैं अपने प्रोजेक्ट पर लगभग पूरे दिन काम करता हूं लेकिन यह हमेशा सच नहीं होता। आपको एक बिल्ड टाइमिंग सेट करना होगा जो कि कितनी बार बिल्ड की आवश्यकता के सापेक्ष है। एक गेम कंपनी में, जिस पर मैंने पहले काम किया था, हमने क्रूज़कंट्रोल का इस्तेमाल किया और इसने प्रत्येक घंटे में एक पूर्ण निर्माण किया। हम जब चाहे तब एक निर्माण को बाध्य कर सकते थे।
एक घर परियोजना के लिए, दिन में एक बार पहले से ही "अक्सर" हो सकता है। मुख्य आवश्यकता उपयोगकर्ता को आसानी से बिल्ड लॉन्च करने के लिए बाध्य करने की होगी।
एक संक्षिप्त चिंतन के बाद मैं सुझाव दूंगा कि यह एक टीम के लिए एकल डेवलपर के लिए और भी महत्वपूर्ण हो सकता है ।
सबसे बुनियादी स्तर पर एक सीआई सर्वर दर्शाता है कि आप अपने आवेदन को प्रतिबद्ध स्रोत से खरोंच से बना सकते हैं - परीक्षणों के एक सभ्य सेट के साथ संयुक्त यह प्रदर्शित करना चाहिए कि आप खरोंच से निर्माण और चला सकते हैं।
चूंकि मैं जिन चीजों को करने की कोशिश करता हूं उनमें से एक यह सुनिश्चित करना है कि मेरे निर्माण में एक तैनाती योग्य पैकेज शामिल है जिसे आप यह भी जानते हैं कि आप तैनाती के लिए कुछ प्राप्त कर सकते हैं (स्वच्छ और ज्ञात राज्य / संस्करण से)।
वास्तव में अब, जब आप फ़ाइल करते हैं। नई परियोजना आपको संभवतः अपने भंडार को बनाना या जोड़ना और अपने CI बिल्ड स्क्रिप्ट और परिनियोजन सेटअप को स्थापित करना चाहिए (भले ही वह केवल xcopy परिनियोजन के लिए सामग्री के ढेर को ज़िप करने के लिए हो)
परिशिष्ट (2016) - आजकल मेरी सीआई प्रणाली भी मेरी तैनाती प्रक्रिया का एक अभिन्न अंग होगी, इसलिए इसका मूल्य बढ़ गया है और मैं इसके बिना कोई भी वितरण योग्य परियोजना नहीं चलाऊंगा। स्वचालित पुश बटन परिनियोजन प्रक्रिया से बहुत अधिक तनाव लेता है और किसी तरह, बिल्ड सर्वर का आकार या रूप उस से अभिन्न रूप से जुड़ा होता है।
जब मैं केवल एक ही कमिटिंग करता हूं, तो मैं वास्तव में कमिट करने से पहले निर्माण और परीक्षण करता हूं । मैं आमतौर पर मेकफाइल लक्ष्य का उपयोग करता हूं जैसे:
make sense
यह विन्यास, निर्माण, सभी परीक्षण चलाता है (जागरूक के बारे में), रन वगैरह, आदि। जैसा कि मुझे पता है कि मैं केवल एक धक्का दूंगा, मुझे वास्तव में हडसन जैसी किसी चीज की शक्ति की आवश्यकता नहीं है।
इसके अतिरिक्त, ऐसे वातावरण में जहां आपकी कई शाखाएं मुख्य भंडार को खिलाती हैं, अगर हर कोई आपके द्वारा किए गए या धक्का देने से पहले हमेशा पुल का अनुसरण करता है, तो सीआई सर्वर थोड़ा खत्म हो सकता है। एक अच्छी तरह से लिखा नियम है कि जो भी लेखक ने पिछले बिल्ड को तोड़ दिया है, वह शुक्रवार को पिज्जा खरीदता है, आमतौर पर चीजें बहुत आसानी से चलती रहती हैं :)
यदि यह एक ऐसी स्थिति में हो जाता है जहां एक परियोजना को स्पष्ट रूप से उप प्रणालियों में विभाजित किया जाता है जिसमें अपने स्वयं के नेता होते हैं, तो आपको वास्तव में हडसन जैसी चीज का उपयोग करने पर विचार करने की आवश्यकता होती है। कोई स्थानीय रूप से परीक्षण कर सकता है, किसी अन्य उप प्रणाली के साथ दौड़ हार सकता है और कुछ विषाक्त को धक्का दे सकता है।
इसके अलावा, यदि आप एक तेज गति से चलने वाले प्रोजेक्ट का कांटा बना रहे हैं (उदाहरण के लिए, लिनक्स कर्नेल को पैच का अपना सेट), तो आपको वास्तव में हडसन जैसी किसी चीज का उपयोग करने पर विचार करना चाहिए, भले ही आप उस प्रोजेक्ट पर 'सोलो' हों। यह विशेष रूप से सच है यदि आप मेनलाइन से सीधे ब्रांच / री-बेस करते हैं।
make: don't know how to make sense. Stop। अरे!
मैं यह नहीं कहूंगा कि यह सिर्फ एक अच्छा बोनस है, मैं कहूंगा कि यह हमारे लिए उच्च गुणवत्ता वाले सॉफ्टवेयर इंजीनियरिंग के लिए महत्वपूर्ण है। हम में से अधिकांश उनके गुणवत्ता मानकों को थोड़ा और खिसकने देंगे, यदि वे जल्दबाज़ी में ऐसा सोचते हैं कि बाद में ठीक करना आसान है। यदि आप उस स्थिति में सॉफ़्टवेयर बनाते हैं, तो आपके पास अनिवार्य रूप से एक बेकार कोडबेस है जो आपके स्रोत नियंत्रण में संग्रहीत है।
यदि आपको सही तरीके से पालन किया जाता है (अर्थात, आप परीक्षणों को छोड़ते नहीं हैं और आप यह सुनिश्चित करते हैं कि यह हर बार आपके द्वारा किए जाने वाले निर्माण को पूरा करता है) CI आपको उच्च गुणवत्ता के मानक का पालन करने के लिए मजबूर करता है यदि आप अभी भी इसे वैसे भी प्रतिबद्ध करेंगे।
यह महत्वपूर्ण है कि क्या आप अपने इंतजार के समय को कम करना चाहते हैं या नहीं यह देखने के लिए कि क्या अभी भी सब कुछ ठीक चल रहा है। यद्यपि आप जैसे ही बचत करते हैं, आप अपने आईडीई को आपके लिए सामान संकलित कर सकते हैं, यह स्वचालित रूप से इकाई परीक्षण नहीं चलाता है, इसलिए मेरे पास मेरा सीआई सर्वर इकाई परीक्षण और परीक्षण मामले की कवरेज रिपोर्ट और मेरे कोड के अन्य गुणवत्ता विश्लेषण जैसे ही हैं मैं इसे धक्का देता हूं।
मुझे जो एकमात्र ट्रिगर करना है, वह मेरे वर्तमान परिवर्तनों को संस्करण नियंत्रण पर धकेल रहा है और मैं कोडिंग पर वापस जा सकता हूं। और जब मैं कोडिंग के बारे में सोच रहा हूं, तो सीआई सिस्टम लंबी घुमावदार गुणवत्ता वाली रिपोर्ट करने में व्यस्त है, जिसे मैं एक बार में देखूंगा जब मेरा दिमाग एक खामोशी में चला जाएगा।
मेरे पास एक ही लैपटॉप पर एक अलग VMWare मशीन है जो कोड के लिए बिल्ड बनाता है जिसे मैं पुश करता हूं। ऐसा करने के लिए मुझे बस एक टर्नकी लिनक्स VMWare छवि मिलती है और apt-get का उपयोग करके जेनकींस स्थापित करते हैं और कुछ मामूली कॉन्फ़िगरेशन परिवर्तन करते हैं।