क्या मेरे संगठन को एजाइल सॉफ्ट को अपनाने की आवश्यकता है। देव। DevOps अपनाने से पहले?

Question

चुस्त सॉफ्टवेयर विकास आज सॉफ्टवेयर की दुकानों के लिए पसंद की पद्धति है। लेकिन अभी भी ऐसे संगठन हैं जो अपने सॉफ्टवेयर विकास में एजाइल का अभ्यास नहीं कर रहे हैं, जो शायद देवो को अपनाने में रुचि रखते हैं।

जब मैं Agile Software Development कहता हूं, तो मेरा मतलब है कि Agile Software Development के लिए Manifesto से निकला कोई वंश । जैसे एक्सट्रीम प्रोग्रामिंग , स्क्रम , लीन सॉफ्टवेयर डेवलपमेंट और अन्य।

चुस्त सॉफ्टवेयर विकास एक संगठन स्तर पर DevOps को अपनाने के लिए एक अनिवार्य शर्त है?

Comments

यह प्रश्न devops.stackexchange.com/questions/73/… के रूप में बनाया गया था और इसे बहुत व्यापक माना गया था।

— एवगेनी

यह एक बहुत अच्छा और बहुत ही मान्य प्रश्न है

— अलेक्जेंड्रे

क्यों चंचल काम करते हैं और कैसे DevOps फिट नहीं करता है में चित्र को पोस्ट किया गया था पर बहुत प्रासंगिक लेख hackernoon.com/why-isnt-agile-working-d7127af1c552

— एव्जेनी

Answer 1

Agile Software Development को DevOps करने की आवश्यकता नहीं है , लेकिन मेरा मानना ​​है कि तर्क दिया जा सकता है कि DevOps के लिए मूल्य का प्रस्ताव अक्सर Agile के बिना बहुत कम है।

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

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

एक यह भी तर्क दे सकता है कि यदि आप देवो को अपनाने जा रहे हैं, तो आप भी चंचल को क्यों नहीं अपनाएंगे? सिद्धांत जो उन्हें दोनों काम करते हैं, एक साथ अच्छी तरह से काम करते हैं। Agile के बिना खुद से DevOps का अभ्यास करना, Ops और Dev के बीच असंतुलन पैदा कर सकता है, जिसमें Ops सेवा वितरण के लिए Dev को बेहतर बना रहा है।

Answer 2

नहीं

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

हालाँकि, मेरा मानना ​​है कि यह स्पष्ट करना बहुत महत्वपूर्ण है कि किसी संगठन को अपनी DevOps संस्कृति और बुनियादी ढांचे के निर्माण से पहले उनकी चुस्त प्रक्रिया को अपनाने की आवश्यकता नहीं है। वास्तव में, मैं तर्क दूंगा कि आपकी कंपनी में काम करने वाले कुछ बुनियादी DevOps होने के बाद Agile को अपनाना वास्तव में आसान है। एजाइल देवओप्स के लिए एक शर्त होने के बजाय, मैं सुझाव दूंगा कि देवो का उपयोग आपके चुस्त कार्यान्वयन को आगे बढ़ाने में मदद करने के लिए किया जाए।

Answer 3

एजाइल 2008 सम्मेलन में, एंड्रयू क्ले शफर और पैट्रिक डेबिस ने "एजाइल इन्फ्रास्ट्रक्चर" पर चर्चा की । यह DevOps आंदोलन की शुरुआत थी।

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

Answer 4

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

Answer 5

IMHO इसे करने की आवश्यकता नहीं है।

से DevOps (जोर मेरा):

DevOps ("सॉफ्टवेयर DEVelopment" और "सूचना प्रौद्योगिकी OPerationS" का एक मिश्रित यौगिक) एक शब्द है जिसका उपयोग प्रथाओं के एक सेट को संदर्भित करने के लिए किया जाता है, जो सॉफ्टवेयर डेवलपर्स और सूचना प्रौद्योगिकी (आईटी) पेशेवरों के सहयोग और संचार पर जोर देता है, जो प्रक्रिया को स्वचालित बनाता है सॉफ्टवेयर वितरण और बुनियादी ढांचे में परिवर्तन। 1 [2] यह है, जहां निर्माण का परीक्षण, और सॉफ्टवेयर जारी एक संस्कृति और पर्यावरण की स्थापना करना है हो सकता है तेजी से, अक्सर, और अधिक मज़बूती से।

मैंने हाइलाइट किया can happenजैसा कि यह नहीं है must happen।

उपरोक्त विवरण में कुछ भी नहीं वास्तव में एक चुस्त विकास पद्धति की आवश्यकता है ।

लेकिन मुझे संदेह है कि अक्सर DevOps की ओर संक्रमण होता है, अक्सर विकास प्रक्रिया में फुर्तीली कार्यप्रणाली का समावेश होता है क्योंकि वे वास्तव में एक साथ अच्छी तरह से फिट होते हैं।

Answer 6

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