व्याख्या की गई भाषाओं के लिए CI का उपयोग कैसे किया जा सकता है?

Question

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

मैं यह नहीं देखता कि अगर मेरे पास बिल्ड स्टेप नहीं है तो CI मेरे लिए किस तरह का होगा। मैं CI को एक परीक्षण वातावरण के रूप में सोच सकता हूं जो इकाई परीक्षण चलाएगा। क्या मैं कुछ भूल रहा हूँ?

Comments

"ये बातें orthogonal रहे हैं ..."

— कुटकी

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

— क्रिस हेस

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

— पीटर - अनबन रॉबर्ट हार्वे

Answer 1

एक शब्द के रूप में निरंतर एकीकरण दो अलग-अलग विचारों को संदर्भित करता है।

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

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

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

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

Comments

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

— user253751

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

— आमोन

@ वामन असत्य अंतिम समय में बदलाव करना और फिर कमिट करने से पहले संकलन का परीक्षण करना विशेष रूप से असामान्य नहीं है। यह उन समस्याओं को भी पकड़ता है जब आप किसी ऐसी चीज पर निर्भरता जोड़ते हैं जिसे आपने वैश्विक रूप से स्थापित किया है लेकिन कहीं और स्थापित नहीं किया है।

— jpmc26

Answer 2

सच है, आपको बिल्ड करने और यह जाँचने के लिए CI सिस्टम की विशेष आवश्यकता नहीं है कि वे बिल्ड सही हैं, लेकिन यह सीआई के बारे में केवल एक हिस्सा है।

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

Comments

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

— रीइन्टीरियरपोस्ट

Answer 3

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

कुछ अन्य कार्य जो मैं ऑफ-हैंड के बारे में सोच सकता हूं कि एक निरंतर एकीकरण पाइपलाइन अक्सर प्रदर्शन करती है:

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

"निरंतर एकीकरण" की सीमा रेखा से थोड़ा आगे बढ़कर एक सख्त अर्थ में, आप ये भी कर सकते हैं:

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

मुद्दा बस यह है: ऐसे कार्य हैं जिन्हें आपको समय-समय पर सॉफ़्टवेयर को विकसित करने की प्रक्रिया में करना चाहिए और कोड लिखने के अलावा। इन कार्यों को स्वचालित करके और उन्हें एक सर्वर पर चलाने से, आपको मिलता है

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

और शायद कुछ अन्य लाभ जो भी दिमाग में नहीं आ रहे हैं।

Comments

जवाब के लिए धन्यवाद। उदाहरण महान हैं। मेरी इच्छा है कि मैं एक से अधिक उत्तरों को स्वीकार कर

— सकूं

@LordLoh। कोई चिंता नहीं। मुझे खुशी है कि मैं मदद कर सका। =) मुझे बताने के लिए धन्यवाद।

— jpmc26

उत्कीर्ण, उत्कृष्ट उत्तर। किसी भी चीज की तरह, अगर खराब तरीके से किया गया हो तो आप विज्ञापित लाभों को प्राप्त नहीं कर सकते हैं। ईजी स्थिरता, प्रक्रिया ज्ञान, सादगी सभी पीड़ित हो सकते हैं यदि आप पुनर्निर्माण करते हैं। तो ... अपनी आवश्यकताओं का वास्तविक रूप से मूल्यांकन करें और Godspeed!

— brian_o

Answer 4

आपको समाधानों को संकलित करने की आवश्यकता नहीं हो सकती है, लेकिन CI अभी भी कॉन्फिग फाइल्स / फोल्डर पाथ आदि को बदलकर आपकी मदद कर सकता है और यदि आप किसी टीम में हैं- तो ठेस स्थिति में बदलाव को बढ़ावा देना और उन्हें तैनात करना।

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