कंटीन्यूअस इंटीग्रेशन (CI) क्या है और यह कैसे उपयोगी है? [बन्द है]

Question

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

Comments

इस youtube वीडियो ने वास्तव में मुझे इस अवधारणा पर बूटस्ट्रैप किया: youtube.com/watch?v=4sANX9AhM8c

— lwm

मार्टिन फाउलर का इस विषय पर एक उत्कृष्ट लेख है ।

— मार्को-फिसेट

वास्तविक समस्याओं के आधार पर व्यावहारिक, उत्तर देने योग्य प्रश्न क्या हैं जिनका आप यहाँ सामना करते हैं? क्या आपने गुगली करने की कोशिश की ?

— मार्क बूथ

Answer 1

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

जब भी कुछ गलत होता है, टीम को एक सूचना मिलती है। आमतौर पर उस समय सभी काम रुके होते हैं और सभी प्रयास यह सुनिश्चित करने पर केंद्रित होते हैं कि उत्पाद स्थिर तरीके से हो। सिस्टम के हरे न होने पर रिपॉजिटरी पर कोई पुश और कमिट नहीं होता है।

CI यह सुनिश्चित करता है कि उत्पाद हमेशा एक स्थिर स्थिति में हो और संभावित रूप से किसी भी समय पहुंचाया जा सके। कृपया ध्यान दें कि स्थिर का मतलब सुविधा पूर्ण नहीं है। इसमें आधी-कार्यान्वित विशेषताएं भी हो सकती हैं, लेकिन सिस्टम स्थिर हो सकता है।

CI आमतौर पर एजाइल कार्यप्रणाली से जुड़ा हुआ है, हालांकि मैं व्यक्तिगत रूप से CI के सटीक इतिहास को नहीं जानता हूं।

Comments

अंतिम वाक्य के बारे में: जबकि सीआई अक्सर एजाइल से जुड़ा होता है, मैं बहुत तर्क देता हूं कि गैर-फुर्तीली विकास (हाँ, जो अभी भी होता है; ;-)) अच्छी तरह से लागू सीआई से भी काफी लाभ उठा सकता है।

— जोकिम सॉर

@ जोचिम सही।

— पटकोस सेबा

@ जोकिम सौर: मैं कहूंगा कि सीआई एक ऐसी चीज है जो किसी भी परियोजना को अधिक चुस्त बनाती है कि वह इसके बिना होगी।

— माइकल बोर्गवर्ड्ट

Answer 2

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

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

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

CI के बिना, ये सभी त्रुटियां एक ही समय में एकीकरण चरण के दौरान एक साथ उभरती हैं, जो उन्हें ठीक करने के लिए बेहद कठिन बनाता है।

Answer 3

आपके पास विकास में एक निश्चित शैली हो सकती है : आप चेकआउट, कोड, संकलन, चेक, शाप, परिवर्तन, संकलन, जयकार, प्रतिबद्ध। आप केवल काम करने वाले कोड को कम करते हैं, शायद कम दानेदार अंदाज में भी जैसे आप काम के दिन या किसी फीचर के पूरा होने पर। जब भी आप API लाइब्रेरी आयात करते हैं तो आप अपनी निर्भरता को सत्यापित करते हैं।

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

इसलिए जब आप दोनों में से कोई एक बदलाव करते हैं, तो दोनों परियोजनाओं को एक साथ बनाया और परीक्षण किया जाना चाहिए, यानी एक दूसरे के एपीआई के खिलाफ चलाना, नए पुस्तकालय के साथ बनाया और परीक्षण करना, आदि ऐसे परीक्षण, आपके कोड और किसी और के, एकीकरण परीक्षण कहलाते हैं।

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

Answer 4

निरंतर एकीकरण के दो पहलू हैं।

1. विकास स्रोत नियंत्रण रणनीति यह सुनिश्चित करती है कि डेवलपर्स अपने चल रहे काम को अन्य डेवलपर्स स्थिर कोड के साथ लगातार एकीकृत करने में सक्षम हैं।
2. स्रोत नियंत्रण के लिए प्रतिबद्ध द्वारा स्रोत कोड का स्वत: निर्माण और परीक्षण शुरू हो गया

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

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

यह कितना उपयोगी है?

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

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

Answer 5

सीआई उपयोगी है, जब आपके पास है:

• कोड संकलन
• परीक्षण का वास्तविक सेट
• स्रोत कोड (कोड कवरेज, कोड मानकों की हिंसा, आदि) के आधार पर रिपोर्टें
• रूटीन जिसे आप समय-समय पर करते हैं, कोड सफलतापूर्वक संकलित करने के बाद

सूची जारी रखी जा सकती है ।।