निरंतर वितरण / वितरण के लिए निरंतर एकीकरण कैसे संबंधित है?

20

यहां निरंतर-एकीकरण की वर्तमान सामग्री का एक उद्धरण है :

... एकीकरण समस्याओं को रोकने या कम करने के लिए डेवलपर के कामकाजी कोड प्रतियों को अक्सर एक साझा कोडबेस में विलय करने की प्रक्रिया।

ठीक है, मैं समझ गया। लेकिन फिर भी निरंतर-वितरण और निरंतर-परिनियोजन है , और यही वह जगह है जहां मैं लगातार थोड़ा खो जाता हूं :

कैसे करता है निरंतर एकीकरण से संबंधित निरंतर वितरण और / या निरंतर तैनाती , रेखा (रों) के साथ है कि कहीं यह सोचते हैं के माध्यम से integrationआप अंत deliveringलक्ष्य पर्यावरण जहां सब कुछ हो जाएगा में deployed।
निरंतर वितरण और निरंतर तैनाती के बीच अंतर क्या है ?

इन दिनों में, इससे पहले कि DevOps को DevOps कहा जाता था, हमने शब्दावली का उपयोग किया, जो संभवतः इन नए DevOps शब्दों को समझने में मदद कर सकते हैं, जैसे:

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

— Pierre.Vriens
स्रोत

बहुत अधिक टैग मार्कडाउन को पढ़ना मुश्किल हो जाता है। यही कारण है कि प्रश्न में अधिक संदर्भ नहीं लाती तो मुझे लगता है ords एक द्वारा पर बल दिया जा सकता है रेखांकन _markdown_ पढ़ने को कम करने

— Tensibai

1

मेरा मतलब है कि संपादन एक दर्द है :) उत्तर ब्लॉग के

— wp-

संबंधित

— स्टैकऑवरफ्लो

मेरा संबंधित उत्तर: softwareengineering.stackexchange.com/a/358551/3385

— Nakilon

23

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

निरंतर एकीकरण, सतत वितरण और निरंतर तैनाती के बीच अंतर। Codeproject.com से कॉपी की गई तस्वीर

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

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

— THelper
स्रोत

अच्छा! लेकिन ... समाधान (आपका जवाब) एक समस्या (मेरे सवाल का), के लिए समस्या परिवर्तन ... अधिक पढ़ सकते हैं ...

— Pierre.Vriens

4

निरंतर वितरण और निरंतर तैनाती (सीडी) कमोबेश एक ही बात है *। हर बार जब बदलाव को 'जाने के लिए अच्छा' (परीक्षण / सत्यापित) माना जाता है, तो इसे तुरंत जारी किया जाना चाहिए। आप इसे दिन में कई बार कर सकते हैं क्योंकि काम पूरा हो गया है।

निरंतर एकीकरण (CI) केवल एक साथ विलय कोड को संदर्भित करता है ताकि यह सुनिश्चित किया जा सके कि फीचर शाखाएं आपकी मुख्य 'मास्टर' शाखा से बहुत दूर नहीं हैं, और यह भी कि आप बहुत जल्दी जानते हैं कि क्या कोड से कोई समस्या है एकीकरण परिप्रेक्ष्य - यानी क्या आपने सामान बदलते समय किसी भी कार्यक्षमता को तोड़ दिया।

जहां तक वे एक-दूसरे से संबंधित हैं, सीआई कोड को सत्यापित करने में बहुत मदद करते हैं ताकि इसे जल्दी (सीडी) जारी किया जा सके। आप अभी भी CI (और इसके विपरीत) के बिना सीडी प्राप्त कर सकते हैं, लेकिन आप पाएंगे कि अक्सर यह आपके कोड को जल्दी से एकीकृत करने के लिए जीवन को बहुत आसान बनाता है और अक्सर समस्याओं को जल्दी खोजने के लिए, जो बदले में आपको उक्त समस्याओं को जल्दी ठीक करने की अनुमति देगा, और अंत में। अपनी सुविधाओं को जल्दी पहुंचाएं!

* संपादित करें: यहाँ अंतर पर चर्चा करने वाला एक लेख है। https://puppet.com/blog/continuous-delivery-vs-continuous-deployment-what-s-diff सतत डिलीवरी का मतलब वास्तव में हर समय उत्पादन के लिए तैनात करना नहीं है, बल्कि इसका मतलब है कि उत्पादन जैसे वातावरण में निरंतर तैनाती इस विश्वास के साथ कि व्यापार के तैयार होने के बाद वे परिवर्तन किसी भी समय उत्पादन में जा सकते हैं। व्यवहार में, अधिकांश लोग इन शर्तों को स्वीकार करते हैं।

— tayworm
स्रोत

merci! लेकिन अपने "कम या ज्यादा एक ही बात" के अनुसार, वास्तव में? क्या आप ऐसी किसी भी चीज के बारे में सोच सकते हैं जो किसी बारीकियों को स्पष्ट करती हो?

— Pierre.Vriens

मैंने अपनी पोस्ट को अंतरों के बारे में एक नोट के साथ अपडेट किया है, हालांकि मेरा मानना है कि सामान्य बातचीत में ज्यादातर लोग इन शब्दों का परस्पर उपयोग करेंगे।

— tayworm

2

किसी सॉफ़्टवेयर उत्पाद का एक निश्चित संस्करण पहले अपने एकीकरण चरण को पूरा करना चाहिए, इससे पहले कि इसे वितरित या तैनात किया जा सके।

के लिए सतत वितरण / तैनाती निरंतर एकीकरण जरूरी है। अन्यथा, यदि एकीकरण पूर्ण होने वाली घटनाएं "निरंतर" विशेषता के लिए अर्हता प्राप्त करने के लिए बहुत दूर हैं, तो संभावित प्रसव / तैनाती हैं (केवल एकीकृत संस्करणों का एक सबसेट आमतौर पर प्रसव / तैनाती के लिए योग्य हैं)।

अद्यतन: मेरा उत्तर केवल सीआई और (दोनों) सीडी के बीच निर्भरता (संबंध) को रेखांकित करता है, शब्दावली बहुत अच्छी तरह से थेलर के उत्तर द्वारा कवर की गई है।

एकमात्र टिप्पणी जो मेरे पास है, वह (अतिभारित) उपयोग के बारे में है deployment। गैर-उत्पादन वातावरण में तैनाती एक वास्तविक चीज है। वे अक्सर भी पर्याप्त-हो सकते हैं - उदाहरण के लिए, निरंतर वितरण के दौरान विभिन्न परीक्षण चरणों के भाग के रूप में। लेकिन वह ऐसी तैनाती नहीं करता है continuous deployments। निरंतर तैनाती विशेष रूप से उत्पादन वातावरण में तैनाती को संदर्भित करती है।

— डैन कॉर्निल्स्कु
स्रोत

ठीक है, यह सब मदद करता है, लेकिन शायद आप अपने जवाब का विस्तार कर सकते हैं कि आप वितरण और तैनाती का वर्णन कैसे करेंगे?

— Pierre.Vriens

1

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

— DevOps जेडी
स्रोत