क्या Saas उत्पादों वाली कंपनियों के लिए DevOps प्रतिबंधित है?


26

DevOps का वर्णन करने वाली प्रथाएं, जैसे कि निरंतर वितरण, स्वचालन, आदि ऐसे उत्पादों के लिए प्रासंगिक हैं जो निरंतर सेवा प्रदान करते हैं, जैसे सास उत्पाद।

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

क्या DevOps उन कंपनियों पर भी लागू होता है जो एक से अधिक परियोजनाएँ विकसित करती हैं? इस मामले में देवओप्स की प्रथा क्या लागू होती है, अगर सभी पर?

जवाबों:


32

बिलकुल नहीं!

DevOps अधिक कुशल होने के लिए पारंपरिक सिलोस (विभागों) को तोड़ने के बारे में है।

टीमों के बीच बेहतर संचार, बेहतर दृश्यता और विश्वसनीय और स्वचालित प्रक्रिया एक बेहतर उत्पाद प्राप्त करने के तरीके हैं।

मैं एक बड़ी मीडिया कंपनी के लिए काम करता था जहां हम एक आंतरिक उपकरण का समर्थन करेंगे और सार्वजनिक-सामना करने वाली वेबसाइटों का विकास करेंगे।

हमारे मामले में DevOps के लाभ निम्नलिखित थे:

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

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


1
वास्तव में, DevOps को लगभग किसी भी स्व विकास संगठन पर लागू किया जा सकता है, यहां तक ​​कि प्रति वर्ष केवल मुट्ठी भर सार्वजनिक रिलीज वाले बड़े-बड़े उत्पादों के लिए - अपने विकास पाइपलाइन के अंदर निरंतर वितरण का उपयोग करके वे अभी भी कुछ DevOps लाभ प्राप्त कर सकते हैं: बेहतर गुणवत्ता, लागत में कमी। रिलीज की भविष्यवाणी, आदि
दान Cornilescu

उत्तर सास को याद दिलाता है, वास्तव में अच्छी तरह से नहीं समझाता है कि एक गैर-सास उत्पाद या सेवा इन प्रथाओं से कैसे लाभ उठा सकती है।
इवगेनी

मैं जिन उत्पादों पर काम कर रहा था, वे सास (काफी विपरीत) नहीं थे। लेकिन तर्क एक ही रहता है, इससे कोई फर्क नहीं पड़ता कि आप सास हैं या नहीं, DevOps गैर-पारंपरिक तरीकों से उत्पाद को बेहतर बनाने का प्रयास करते हैं। मुझे हमारे मूल्य निर्धारण मॉडल या पेशकश के बारे में कुछ नहीं पता था, इससे बहुत फर्क नहीं पड़ेगा।
अलेक्जेंड्रे

13

मेरी टीम और मैं "वन-ऑफ़्स" विकसित करने के लिए जिम्मेदार हैं, जो उत्पाद एक बार समाप्त होने पर क्लाइंट को रखरखाव के लिए दिए जाते हैं या कुछ मामलों में शुल्क के लिए हमारे द्वारा प्रबंधित किए जाते हैं।

हमें अभी भी यह सुनिश्चित करने के लिए अपने ग्राहकों से निरंतर प्रतिक्रिया को संभालने के लिए एक ठोस विकास पाइपलाइन को बनाए रखने की आवश्यकता है ताकि हम उन्हें विश्वसनीय और चलाने के लिए कुछ साबित कर सकें।

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

यह सुनिश्चित करने के लिए कि हमारी परिनियोजन रणनीतियाँ पूरे प्रोजेक्ट्स में समान हैं, हम अपने अनुप्रयोगों को कंटेनरीकृत करने पर ध्यान केंद्रित करते हैं। डॉकर का उपयोग करके, हम आसानी से अपने ग्राहकों को एप्लिकेशन को सौंपने में सक्षम हैं।

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


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

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

यह सिर्फ चुस्त सॉफ्टवेयर देव नहीं है?
एवगेनी

@Evgeny मैंने स्पष्ट करने के लिए अपना उत्तर अपडेट कर दिया है। हम चुस्त का उपयोग करते हैं, लेकिन इसका मतलब यह नहीं है कि हम एक DevOps मानसिकता नहीं कर सकते हैं ..
कछुए

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

3

मैंने कंपोज़िट-रैप उत्पादों के रूप में सॉफ़्टवेयर बनाने वाली कंपनियों के लिए काम किया है, पूरी तरह से स्थापित और समर्थित तैनाती और उपकरणों में एम्बेडेड कोड के रूप में। उन सभी कंपनियों में, DevOps विकास के लिए आवश्यक सहायता प्रदान करता है:

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

सभी मामलों में, ये ऐसी चीजें हैं जो व्यक्तिगत डेवलपर्स एक-बंद के रूप में कर सकते हैं, लेकिन यह डेवलपर समय का अच्छा उपयोग नहीं होगा, और न ही कॉन्फ़िगरेशन नियंत्रण का एक ही आश्वासन है कि स्वचालित बिल्ड हैं।


स्वचालन devops नहीं है। डेविड बॉक के जवाब के रूप में एक ही टिप्पणी अंत में (क्षमा करें, मेरी टिप्पणी उस समय खो गई थी जब मुझे
नीचा दिखाया

3

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

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

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

तो कार्यप्रणाली केवल सास में ही उपयोगी नहीं है।


0

हर्गिज नहीं। जबकि इस धागे पर पहले से ही महान उदाहरण हैं, मैं अपना खुद का एक किस्सा साझा करना चाहता हूं। 2001 में मुझे एक रिलीज़ के साथ एक सॉफ्टवेयर प्रोजेक्ट विरासत में मिला जिसमें एक सीडी का निर्माण शामिल था। रिलीज प्रक्रिया के लिए प्रलेखन में एक पिछले इंजीनियर द्वारा दर्ज किए गए 40 (!) चरण शामिल थे, जिसमें कुछ हास्यास्पद हाथ से लिखे गए निर्देश शामिल थे जैसे "इस कॉन्फिग फ़ाइल को खोलें और वर्जन संख्या को शामिल करने के लिए लाइन पर 41 .jar फ़ाइल का नाम बदलें। नई रिलीज "।

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

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

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


यह स्वचालन से संबंधित है, लेकिन किसी भी तरह से एक devops संगठन से संबंधित नहीं है, मुझे कहीं भी प्लुर अनुशासन टीम के बारे में कोई संदर्भ नहीं दिखता है, बस उन चीजों को स्वचालित करने का
विरोध करता है

यह 2001 था ... इससे पहले कि लंबे समय तक DevOps एक चीज थी। यह सिर्फ स्वचालन नहीं था, मेरा मानना ​​है कि इसने परियोजना के प्रबंधन को ठीक उसी तरह से सुव्यवस्थित किया जिस तरह से अंततः देव संस्कृति के 'संस्कृति' का लेबल बन गया। जैसे, यह एक सास संगठन के बाहर DevOps रवैये का एक उदाहरण है।
डेविड बॉक

DevOps स्वचालन के बारे में नहीं है, न ही परियोजना प्रबंधन। यह साइलो आधारित संगठन को जड़ से तोड़ने के बारे में है। मुझे खेद है कि मुझे ऐसा नहीं लगता कि यह उत्तर वास्तव में प्रश्न से संबंधित है (इसका मतलब यह नहीं है कि यह निर्बाध है, लेकिन सिर्फ सही जगह पर नहीं IMO, और मुझे नहीं लगता कि यह वास्तव में कहां हो सकता है, आ सकता है बाद में)
तेंसिबाई

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

यह अंतिम टिप्पणी इस प्रश्न के तहत इस उत्तर के लिए और अधिक समझ में लाती है, आपको इसे शामिल करने के लिए संपादित करना चाहिए , मुझे अभी भी लगता है कि यह इस प्रारूप में फिट नहीं है, लेकिन ऐसा लगता है कि मेरी स्थिति गलत है जब मैं इस निजी बीटा में समग्र विकास का निरीक्षण करता हूं, इसलिए ... यह आप पर निर्भर है। मैं जानकारी के लिए एक संपादन के बिना अपने
पदावनत
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.