DevOps का मतलब है कि डेवलपर्स अब बुनियादी ढांचे और रिहाई की जिम्मेदारी लेते हैं - लेकिन इस बदलाव के पीछे चालक क्या हैं?

Question

DevOps का मतलब है कि डेवलपर्स अब बुनियादी ढांचे और रिहाई की जिम्मेदारी लेते हैं - लेकिन इस बदलाव के पीछे चालक क्या हैं?

मैं अपने कार्ड टेबल पर रखूँगा: मैं एक डेवलपर हूँ और दोनों "DevOps" और गैर-संस्कृतियों में काम कर रहा हूँ। बुनियादी ढांचे और रिलीज और क्यूए और संबंधित समारोह के बारे में चिंता करने के लिए अच्छा कोड लिखने से एक बड़ी व्याकुलता है।

लेकिन उद्योग इस दिशा में आगे बढ़ रहा है, तो इसके क्या कारण हैं? भूमिका विशेषज्ञता के "पुराने" मॉडल में क्या समस्याएं थीं?

Comments

क्या आप कह रहे हैं कि आपके कोड की गुणवत्ता कम हो रही है क्योंकि आप अन्य काम करते हैं, या आपके कोड की मात्रा कम हो रही है।

— कैलथ

कृपया अपने कार्ड टेबल से हटा लें । यह सिर्फ एक शिकायत की तरह है।

— svidgen

@svidgen यदि यह प्रश्न विशुद्ध रूप से एक शेख़ी था, तो यह अलग होगा, लेकिन ओपी अपनी राय व्यक्त करने के साथ-साथ पूरी तरह से वैध प्रश्न पूछने का हकदार है।

— रोबी डी

@robbie यकीन है। आप ध्यान दें कि मैंने इसका उत्तर वैसे भी दिया है ... लेकिन, इस सवाल का "राय" हिस्सा आधे से अधिक शरीर को खा जाता है, एक ही मूल प्रश्न के बीच सैंडविच होता है, और यह इस मामले में मूल प्रश्न की संभावित शुद्धता से विचलित करता है। लेकिन हां। अभी भी जवाब देने लायक ..

— svidgen

Answer 1

मुख्य कारण बादल है।

ऐसा हुआ करता था कि आपका कोड फ़्लॉपी डिस्क पर भेज दिया गया था, और फिर सीडी, और फिर यह एक सर्वर पर तैनात हो गया, और फिर इसे दो सर्वरों (रिज़ॉल्यूशन के लिए) में तैनात कर दिया गया ... और यह सभी की तैनाती मैन्युअल रूप से की जा सकती थी एक मानव द्वारा, इसलिए मानवों को इसे करने में प्रशिक्षित किया गया।

आज, आपका कोड अक्सर दर्जनों या सैकड़ों सर्वरों पर जा रहा है। उन सर्वरों में प्रोविजनिंग, कॉन्फिगरिंग और तैनाती वास्तविक रूप से मानव द्वारा नहीं की जा सकती है। जब आप अब रसोइया या उसके परिजनों का उपयोग कर रहे हैं, तो आपको उस प्रक्रिया को स्वचालित करने के लिए पर्याप्त स्क्रिप्टिंग जानने के लिए आपके sys व्यवस्थापक की आवश्यकता है। लेकिन स्पष्ट रूप से, वहाँ पर्याप्त sys व्यवस्थापक नहीं थे जो ऐसा कर सकते थे। तो देवों को ढलान लेने के लिए अंदर खींच लिया गया।

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

मुझे संदेह है कि व्यापार बंद होने के लायक है क्योंकि लोग इसे अक्सर बाहर कर देते हैं।

Comments

आपने मुझे " मुख्य कारण बट है " खो दिया ।

— tedder42

Answer 2

विभिन्न संगठनों द्वारा DevOps में जाने के कई कारण हैं।
मैं उन लोगों को सूचीबद्ध करने की कोशिश करूंगा जो अक्सर आते हैं।

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

सॉफ्टवेयर बनाम हार्डवेयर मुद्दे
कीड़े चलनेवाली कार्टून को याद रखें जहां कीड़े और डैफी बहस कर रहे हैं कि क्या यह बतख का मौसम है या खरगोश का मौसम? अब कल्पना कीजिए कि हमने इसे डेवलपर्स और संचालन के साथ बनाया है जहां डेवलपर्स का तर्क है कि यह एक हार्डवेयर मुद्दा है और संचालन तर्क देते हैं कि यह एक सॉफ्टवेयर मुद्दा है। अंत उपयोगकर्ता के लिए यह अंतर के बिना एक अंतर है। वे बस इसे तय करना चाहते हैं।
डेवलपर्स और ऑपरेशन को एक साथ लाकर उन्हें मुद्दों को ठीक करना होगा। और यह एक सॉफ्टवेयर और हार्डवेयर समस्या थी।

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

उम्मीदें / Upsides
DevOps के साथ दोनों विशिष्टताओं को पारंपरिक रूप से दूसरे द्वारा किए गए कुछ कौशल सीखेंगे। कोई भी सिस्टम प्रशासक से सॉफ्टवेयर इंजीनियर या डेवलपर बनने के लिए नेटवर्क इंजीनियर बनने की उम्मीद नहीं करेगा, लेकिन दोनों को दूसरे के कुछ उत्तरदायित्व लेने की उम्मीद है। इसका मतलब यह है कि जब आपको वास्तव में कुछ अतिरिक्त हाथों की आवश्यकता होती है, तो वे वहां होते हैं।

और डेवलपर्स के लिए कुछ निश्चित निर्णय हैं: अब आपके पास अपने परीक्षण वातावरण पर अधिक नियंत्रण है, आपको उपयोगकर्ताओं के लिए सॉफ्टवेयर तैनात करना आसान होगा और आपके संगठन में शिल्प के अपने प्यार को साझा करने के लिए अधिक लोग होंगे।

Comments

+1 - क्योंकि यह अंतिम उपयोगकर्ता के बारे में है, न कि केवल कोड के बारे में।

— जेफो

Answer 3

गुणवत्ता कोड लिखना पर्याप्त नहीं है। आप समस्या का हिस्सा हैं या समाधान का हिस्सा हैं।

कई प्रोग्रामर के लिए, आप ऐसे सॉफ़्टवेयर लिख रहे हैं जिनका भुगतान कुछ अंतिम उपयोगकर्ता कर रहे हैं। क्वालिटी कोड लिखना एक अच्छी बात है, लेकिन यह भी कुछ क्लाइंट्स / मैनेजर मानते हैं कि आपको हमेशा काम करना चाहिए और तेजी से करना चाहिए। यह कहना है कि एक बढ़ई बोर्ड को सही ढंग से काट रहा है, लेकिन क्या आप वास्तव में किसी के लिए भुगतान करना चाहते हैं?

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

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

Comments

मुझे यकीन है कि आप जानते हैं कि अच्छा सॉफ्टवेयर देवों को काम पर रखना कितना कठिन है। और अब हमें उन्हें अच्छे व्यवसाय विश्लेषकों, क्यूए समारोह में रुचि रखने और रिलीज प्रक्रियाओं के बारे में चिंता करने की आवश्यकता है। नए बार से मिलने वालों की संख्या गायब हो जाएगी।

— बेन

@ बान: कोई "और अब" नहीं है; इन चीजों को अच्छे डेवलपर्स दशकों पहले कर रहे थे किसी ने सोचा था कि DevOps एक नई चीज थी और इस शब्द को गढ़ा। एक डेवलपर के रूप में आपका काम उन समस्याओं को हल करना है जो किसी के समाधान के लिए किसी की ज़रूरत से लेकर उन लोगों को सुनिश्चित करने के लिए हैं, जिन्हें आपने लिखा है कि आपके पास एक कठिन समय नहीं है। इसमें से किसी पर भी कंजूसी करें और किसी को परवाह नहीं होगी कि आपके चौकोर खूंटे को कितनी खूबसूरती से उकेरा गया है अगर उन्हें गोल छेद में चलाने के लिए दस पाउंड के स्लेज की जरूरत है।

— ब्लरफ्ल

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

— रिचर्ड टिंगल

@RichardTingle: किसी के कहने से आपको सब कुछ नहीं समझना होगा, लेकिन आपको उन चीजों को समझना होगा, जिनका इस्तेमाल करने पर आपका उत्पाद छू जाएगा। एक प्लंबर को यह जानना होता है कि इलेक्ट्रीशियन क्या करते हैं - या कम से कम एक के साथ काम करने के लिए - यह जानने के लिए कि ब्रेकर बॉक्स के माध्यम से ठंडे पानी के पाइप को चलाने के लिए असुरक्षित है, हालांकि इसे करने के लिए नॉकआउट उपलब्ध हैं।

— ब्लरफुल

सवाल का जवाब देने की कोशिश भी परेशान नहीं करता है। -1

— रबरडक

Answer 4

यह एक ऐसी चीज है जो एजाइल और स्क्रैम के साथ हाथ से चली गई है। अब स्पष्ट रूप से परिभाषित नौकरी की भूमिकाएं नहीं हैं - हर कोई "डेवलपर" है।

और यह सिर्फ ऑप्स नहीं है। डेवलपर्स को अक्सर व्यापार विश्लेषण, परीक्षण, डेटाबेस प्रशासन लेना होता है और प्रबंधक भूमिकाएं बनानी होती हैं - सूची आगे बढ़ती है।

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

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

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

Comments

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

— एंडी

@ और मैं आपको सुझाव दूंगा कि आप स्क्रैम गाइड को फिर से पढ़ें : स्क्रम डेवलपर के अलावा अन्य विकास टीम के सदस्यों के लिए कोई शीर्षक नहीं पहचानता है, भले ही उस व्यक्ति द्वारा किए जा रहे काम की परवाह किए बिना; इस नियम के कोई अपवाद नहीं हैं । लोग बेशक विशेषज्ञ हैं, लेकिन इसकी प्रकृति से, यह एक आत्म-आयोजन इकाई माना जाता है।

— रॉबी डी

किसी ऐसे व्यक्ति को कॉल करना जिसकी विशेषता फ़ोटोशॉप में ग्राफिक्स बना रही है, या कोई है जो भूमिका निभा रहा है, एक डेवलपर सॉफ्टवेयर परियोजनाओं में डेवलपर के रूप में गुमराह कर रहा है जिसे सार्वभौमिक रूप से सॉफ्टवेयर डेवलपर समझा जाता है। उस स्टेटमेंट में स्क्रैम गाइड बस गलत है।

— एंडी

Answer 5

मुझे यकीन है कि डेवलपर्स द्वारा संचालन और गुणवत्ता नियंत्रण (कभी-कभी) का प्रबंधन करने के लिए कुछ अच्छे कारणों से अधिक हैं । यहाँ उनमें से तीन हैं:

• ब्याज
  कुछ डेवलपर्स वास्तव में उत्पाद के सभी पहलुओं पर काम करना चाहते हैं । यदि वे इसमें अच्छे हैं , और यदि वे टीम में एक शून्य भर रहे हैं या अन्य भूमिकाओं में मौजूदा टीम के सदस्यों को अच्छा समर्थन प्रदान कर रहे हैं, तो उन्हें रोकने का कोई कारण नहीं हो सकता है।
• लागत
  बड़ी कंपनियां विशिष्ट कर्मचारियों को वहन कर सकती हैं। छोटी कंपनियां कभी-कभी नहीं कर सकती हैं। इनमें से कुछ जगहें 1 या शायद 2 या 3 डेवलपर्स को किराए पर ले सकती हैं, जिन्हें बस दरवाजे से बाहर काम करने में सक्षम होना चाहिए।
• परियोजना का आकार
  प्रत्येक परियोजना एक कई-व्यक्ति परियोजना नहीं है। यदि आप एक "छोटा" एप्लिकेशन बना रहे हैं, तो इसे पूरा करने के लिए 1 से अधिक व्यक्ति के काम करने में बस ओवरकिल हो सकता है। इसके लिए, विशिष्ट भूमिकाएँ निभाने वाले कई व्यक्तियों के साथ छोटी परियोजनाएँ डरावनी हैं । किसी के पास करने के लिए पर्याप्त काम नहीं है - भले ही आप उन्हें 6 महीने तक अपने अंगूठे को मोड़ने के लिए चारों ओर रख सकते हैं , अच्छे लोग नहीं रहेंगे। यदि वे ऊब नहीं हैं, तो वे डर जाएंगे, या आपको एहसास होगा कि आप कुछ नहीं के लिए काफी भुगतान कर रहे हैं। किसी भी तरह से, आपके अच्छे कर्मचारी आपको छोड़कर सभी को आपसे दूर रहने के लिए कह रहे होंगे।

... और अन्य कारण, मुझे यकीन है।

Answer 6

"बुनियादी ढांचे और रिलीज और क्यूए और संबंधित समारोह के बारे में चिंता करने के लिए अच्छा कोड लिखने से एक बड़ी व्याकुलता है"

मेरे दिल में, मुझे लगता है कि DevOps का कहना है कि बुनियादी ढांचे और रिलीज के बारे में चिंता करना और क्यूए आईएस अच्छा कोड लिखना है।

पिछली भूमिकाओं में गैर- DevOps संस्कृतियों में काम करते हुए, मेरे पास कई मुद्दे हैं, जो यकीनन, एक DevOps संस्कृति को रोक सकते थे; गैर-प्रतिनिधि प्लेटफार्मों पर विकसित कोड से संबंधित प्रदर्शन के मुद्दे, चरित्र-एन्कोडिंग मुद्दे जहां डेवलपर्स एक ग्राहक द्वारा उपयोग किए गए चरित्र-एनकोडिंग के बारे में अनभिज्ञ थे, परिनियोजन निर्देश जो कुछ हद तक अनुमान के बिना ऑप्स टीम के लिए हाथ से कोडित और अपर्याप्त थे -काम।

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

Answer 7

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

से विकिपीडिया :

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

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

Buzzwords के साथ अक्सर ऐसा होता है , एक शब्दार्थ प्रसार होता है, और अचानक लोगों को लगता है कि "हम देवों को भी Ops करते हैं, और मुझे लगता है कि हम पैसे बचा सकते हैं ..."