हमारे पास DevOps हैं। आइए सभी परीक्षकों को आग दें

क्या कुछ भी स्वचालित करना संभव है? फिर हम निश्चित रूप से सभी परीक्षकों को आग लगा देंगे। अब उनकी आवश्यकता क्यों है, कोई "मैनुअल" परीक्षण नहीं बचा है। सब के बाद सही?

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



यह सामग्री BarF jbaruch Sadogursky, JFrog में डेवलपर एडवोकेट द्वारा रिपोर्ट की एक प्रतिलेख पर आधारित है। रिपोर्ट का पाठ संस्करण और वीडियो कट के नीचे है।



सभी को नमस्कार! ऊपर की तस्वीर में शेक्सपियर का एक उद्धरण देखें? यह हेनरी VI है, सभी वकीलों को मारने का प्रस्ताव। आप समझते हैं, तब से हमारे पास गलत व्यवसायों से छुटकारा पाने के लिए अधिक शाकाहारी तरीके हैं। हम किसी को नहीं मारेंगे, बस इसे ले लो और सभी को आग लगा दो।

अधिक सटीक रूप से, ऐसा अवसर है। हम किसी को आग देंगे? बात करते हैं।



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

* अस्वीकरण: नेटफ्लिक्स अक्सर इस लेख में DevOps के अप्राप्य आदर्श के रूप में उपयोग किया जाता है। यह प्रयोग एक घरेलू शब्द है।

नेटफ्लिक्स वास्तव में सही DevOps है की एक चर्चा इस लेख के दायरे से परे है (सबसे अधिक संभावना है, वैसे, नहीं)।

वे स्पिनंकर स्थापित करते हैं, फिर कैओस बंदर लॉन्च करते हैं, और सब कुछ स्वचालित है। और हम ऐसा करेंगे और बहुत प्रभावी होंगे।

बॉस पूछता है, परीक्षकों का क्या। “और यहाँ, जैसा कि नेटफ्लिक्स में है - स्वतंत्रता और जिम्मेदारी । डेवलपर्स खुद परीक्षण लिखेंगे। ”

और फिर वासा बीमार हो जाता है, क्योंकि वह अपने व्यवसाय कार्ड को देखता है, और वहां ...



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

लेकिन, निश्चित रूप से, तब वासना जाग उठती है।



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

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

मैं खुद एक परीक्षक नहीं हूं, इसलिए, शायद, मैं कुछ बकवास बताऊंगा। सम्मेलन के कार्यक्रम में, जिस पर यह रिपोर्ट मूल रूप से पढ़ी गई थी, एक विशेष पदनाम है - एक मोलोटोव कॉकटेल के साथ एक तस्वीर। तो, स्पीकर कुछ प्रकार की विधर्मियों को ले जाने वाला है, और दर्शक जलेंगे। यह मेरे बारे में है। ट्विटर पर, मैं @jbaruch हूं। जैसा कि आप पहले से ही समझ चुके हैं, मैं बहुत हंसमुख आदमी हूं, मुझे तुरंत पालन करने की जरूरत है।

मेरे पास आपके लिए समाचार हैं: 80% डेवलपर्स परीक्षण लिखते हैं। डेवलपर्स सभी प्रकार के चुनावों से संतुष्ट हैं। खैर, JetBrains बहुत अच्छी स्टेट ऑफ डेवलपर इकोसिस्टम रिपोर्ट से खुश है। वे पूछते हैं कि यूनिट टेस्ट कौन लिखता है।

• 59% अपने दम पर लिखते हैं
• 11% यूनिट कोड अपने कोड में देखते हैं और यह नहीं जानते कि वे कहाँ से आते हैं।

कुल में, 70% डेवलपर्स यूनिट परीक्षणों का उपयोग करते हैं। यह कमाल है।

डेवलपर्स की मदद से परीक्षण के बारे में हबस्टाफ द्वारा अधिक गहन अध्ययन किया गया है, यह थोड़ा पुराना है - 2014। उनके अनुसार:

• 85% डेवलपर्स इकाई परीक्षण लिखते हैं,
• 15% नहीं;
• परीक्षण-संचालित विकास पद्धति के अनुसार 40% काम;
• अच्छा कवरेज - डेवलपर्स के 31% के बीच 34 और 66 के बीच।

डेवलपर्स के विशाल बहुमत का दावा है कि वे पेन के साथ भी कुछ परीक्षण करते हैं। वे निश्चित रूप से झूठ बोलते हैं, लेकिन आंकड़े इस प्रकार हैं।

2011 से, हमारी पसंदीदा बोली है: "हर कंपनी एक सॉफ्टवेयर कंपनी है" । सहित, ज़ाहिर है, ओम्स्क मांस का कारखाना, जिस पर वासा काम करता है। हर जगह सॉफ्टवेयर है और इस सॉफ्टवेयर पर हर कोई पैसा बनाने की कोशिश कर रहा है। कंपनियां क्या चाहती हैं? फावड़ा लेकर लूटपाट रो। पैसा कहां से आता है? संतुष्ट ग्राहकों से। ग्राहक क्या चाहते हैं? नई सुविधाएँ। और वे नई सुविधाएँ कब चाहते हैं? अब!

कॉमिक बुक के सीईओ दिलबर्ट वासिया के बॉस प्रमुख हैं। उन्होंने सभी प्रकार की रोचक रिपोर्टों को भी सुना। उनका मानना ​​है कि यदि ग्राहक नई सुविधाएँ चाहते हैं, तो उन्हें अधिक बार नई सुविधाएँ जारी करने की आवश्यकता है। तार्किक है। ऐसा करने के लिए, टीमों में घर्षण कम करें।

क्या मुझे अधिक बार रिलीज करना चाहिए? उदाहरण के लिए, 2017 में, जावा ने अधिक लगातार रिलीज़ पर स्विच किया, क्योंकि हर कोई सुविधाएँ चाहता है और, ऐसा प्रतीत होता है, उन्हें तेजी से रिलीज़ करने की आवश्यकता है। हर छह महीने में एक नया जावा निकलता है। लेकिन कोई इसका उपयोग नहीं करता है।

हमारे पास हाल ही में जोकर था, हमने उस पर जावा पज़लर्स की मेजबानी की। शुरुआत में, हम हमेशा पूछते हैं कि कौन से जावा में है, यह समझने के लिए कि किस पहेली टुकड़े को पूछना है।

चित्र नहीं बदला है: 80%, या इससे भी अधिक, अभी भी जावा 8 पर बैठे हैं, जो सौ साल पहले जारी किया गया था। न तो कोई नौवा लेता है, न ही दसवां, या ग्यारहवाँ।



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

हम अपडेट कैसे डालते हैं

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

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

पहले Apple के साथ कोई समस्या नहीं थी: एक नया ऑपरेटिंग सिस्टम है - चलो इसे लेते हैं। यह पहले था, और अब हम अद्यतन होने से डरते हैं, कोई पूर्व विश्वास नहीं है। अगर हमें भरोसा है - कोई बात नहीं, हम अपडेट कर रहे हैं। यदि हमें भरोसा नहीं है, तो आपको परीक्षण करने की आवश्यकता है।

हम वही करते हैं जिसे स्वीकृति परीक्षण कहा जाता है। यहां वे हमें बताते हैं: एक नया जावा बाहर आया है, और उदाहरण के लिए, हम Baidu हैं। हाईलोड, हर जगह 100,500 सर्वर, क्लाउड, जेवीएम। हम सर्वर का कुछ हिस्सा लेते हैं, जावा को बदलना शुरू करते हैं। इंजीनियरों के एक झुंड को कुछ करना पड़ता है और इसे सभी की जांच करनी होती है। हर तीन साल में एक बार यह सामान्य है, लेकिन हर छह महीने में एक बार ... क्या आप गड़बड़ हैं? हम केवल छह महीने तक इसकी जांच करेंगे। बेशक, हम इसे आपके नए जावा नहीं लेंगे।

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

समस्या भरोसे में है। अगर हम भरोसा नहीं करते हैं, तो अपडेट करना मुश्किल होगा। यदि विश्वास समस्या हल हो गई है, तो अपडेट के साथ कोई समस्या नहीं है। या तो हमारे पास एक सुविधा है, या हम लानत नहीं देते हैं।

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



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

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

भरोसे का सवाल आलोचनात्मक है। हम इसे कैसे हल करेंगे? "हम" शब्द का अर्थ है जेफ्रॉग के दो सह-संस्थापक, फ्रेड साइमन (फ्रेड साइमन), योव लैंडमैन (योव लैंडमैन) और आपका विनम्र सेवक। हमने एक किताब लिखी है जिसमें सलाह दी गई है कि इस समस्या को कैसे हल किया जाए।

मान लीजिए कि हमने अपने सीईओ को मना लिया, उन्होंने लिक्विड सॉफ्टवेयर पढ़ा, और अब उन्हें समझ में आया कि उन्हें अपडेट की आवश्यकता क्यों है। वह सलाहकार से पूछता है कि हम और अधिक बार कैसे अपडेट करेंगे। चंचल! DevOps! DevOps क्या है?

DevOps

देवोप्स क्या है, इसका थोड़ा सिद्धांत बताती हूं, क्योंकि हम इस पर पैसा कमाते हैं। तस्वीर पर एक नज़र डालें, हमारे पास ये समूह, दल, विभाग हैं:


डेवलपर्स हैं, वहाँ ऑप्स - सिसाडमिन हैं जो डेवलपर्स को लिखते हैं और उन्हें ठेस पर फेंक देते हैं। और ओपीएस डेवलपर्स के बीच में, क्यूए हैं जो परीक्षण कर रहे हैं। यही है, डेवलपर्स बैठ गए, लिखा, फिर इसे परीक्षकों के पास ले गए, इसका परीक्षण किया, इसे सिस्टम प्रशासकों को सौंपा, और उन्होंने इसे ठेस पर अपलोड किया। इसके लिए हमारे पास अलग विभाग थे।

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

स्वाभाविक रूप से, बाल्टी में। यही है, हमारे पास ऐसे "काम की बाल्टी" हैं। डेवलपर्स ने कुएं में कुछ लिखा, हमने इसे बाल्टी में लोड किया, इसे कुएं से बाहर निकाला, बाल्टी को परीक्षकों तक पहुंचाया, और इसे कुएं में उतारा।

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

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

यह मेरी गलती नहीं है! मैंने सिर्फ तीन मूल रंगों को लिया, उन्हें एक दूसरे के ऊपर रखा, और यह रंग निकला। अब हम सब कुछ करते हैं। हमारे पास ऐसे इंजीनियर हैं जो श्वेत, और रेपर्स, और डयूरस दोनों हैं। ये देव, क्यूए और ऑप्स हैं। उन्होंने कोड को लिखा और परीक्षण किया, और फिर उन्होंने इसे सभी उत्पादन पर रखा - ऐसा गेंडा।

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

मिश्रण

हमारे पास एक सामान्य संस्कृति है, सामान्य लक्ष्य हैं। हमने कुओं को छोड़ दिया, हम सभी अब एक साथ हैं, लेकिन हमारे पास अभी भी गहरी विशेषज्ञता है। एक डेवलपर अभी भी Ops की तुलना में अधिक डेवलपर है, और एक परीक्षक डेवलपर की तुलना में अधिक परीक्षक है। फिर भी, वे सब कुछ समझते हैं। वे समझते हैं कि वे क्या कर रहे हैं, वे क्यों कर रहे हैं और यह कैसे काम करता है।

यही है, हमारे पास टी-आकार के लोग हैं, "अक्षर टी के आकार के लोग"।

उनके पास एक गहरी विशेषज्ञता है, वे अच्छी तरह से जानते हैं कि वे क्या कर रहे हैं। वे काफी अच्छी तरह से जानते हैं और बाकी सब भी। उदाहरण के लिए, डेवलपर्स को थोड़ा समझ में आता है कि सही तरीके से कैसे परीक्षण किया जाए, कैसे आउटिंग की प्रक्रिया को ठेस और इतने पर।

DevOps है:

• हमारे पास अब जो लक्ष्य हैं, उनकी संस्कृति, हम समझते हैं कि हम एक साथ क्या करते हैं।
• अधिक बार जारी करने के लिए स्वचालन।

गति और गुणवत्ता

चलो इस धारणा के बारे में बात करते हैं कि गति और गुणवत्ता के बीच एक व्युत्क्रम संबंध है। मोटे तौर पर, हम जितनी तेज़ी से जारी करते हैं, गुणवत्ता उतनी ही खराब होती है। और इसके विपरीत: अगर हम जल्दी में नहीं हैं, तो हमारे पास हर चीज को अच्छी तरह से परखने का समय होगा। हम एक व्यापार बंद है!

यह समझने के लिए कि क्या यह निर्भरता वास्तव में मौजूद है, आइए हम वैज्ञानिक पत्रों की ओर रुख करें और डोरिया संगठन से स्टेट ऑफ़ देवऑप्स रिपोर्ट के बारे में बात करें। मैं आपको इस रिपोर्ट पर एक अच्छी नज़र डालने की सलाह देता हूं।

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

इसके अलावा, निकोल फोर्सग्रेन, जो हमारे विपरीत DORA के प्रमुख हैं, एक वैज्ञानिक हैं, इसलिए वहां सब कुछ गंभीर है। आइए देखें कि DORA हमें इस व्युत्क्रम सहसंबंध के बारे में क्या बताता है।

सबसे पहले, उन्होंने सभी उत्तरदाताओं को तीन समूहों में विभाजित किया: निम्न कलाकार, मध्यम कलाकार और उच्च कलाकार।

इसके अलावा, अभिजात वर्ग है। यह नेटफ्लिक्स है (वास्तव में नहीं, ऊपर अस्वीकरण देखें)।



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

यह किसी तरह अजीब है। यह पता चला है कि मध्यम को कम से अधिक हैंडल के साथ परीक्षण किया जा रहा है। क्यों? हां, क्योंकि लो कुछ भी परीक्षण नहीं करता है।



उनके पास एक प्रवृत्ति है, जे-वक्र नामक एक ग्राफ, जो गति और गुणवत्ता के बीच बहुत सहसंबंध या व्युत्क्रम सहसंबंध दिखाता है। और यहाँ सब कुछ बहुत अजीब है। कुछ बिंदु पर, हम इस व्युत्क्रम सहसंबंध की पुष्टि देखते हैं। यही है, हम जितनी तेज़ी से जारी करते हैं, गुणवत्ता कम होती है।

लेकिन फिर सहसंबंध न केवल व्युत्क्रम है, यह प्रत्यक्ष है। हम जितनी तेज़ी से जारी करते हैं, हमारी गुणवत्ता उतनी ही बेहतर होती है। मान लें कि हम मध्यम हैं और पेन से परीक्षण करते हैं। सब कुछ बुरा नहीं है, लेकिन धीरे-धीरे, क्योंकि हम मानते हैं कि अगर हम जल्दी में नहीं हैं, तो हम सब कुछ बेहतर परीक्षण करेंगे। तब DevOps का एक सलाहकार आता है और कहता है: “यह बात है, अब हम इसे स्वचालित कर रहे हैं। और हमें परीक्षकों की आवश्यकता नहीं है। सब कुछ ठीक है। ”

लेकिन परीक्षण के बिना, यह एक प्रकार की बकवास है। जब हमने महसूस किया कि आखिरकार कुछ का परीक्षण करने की आवश्यकता है, और इसे सही ढंग से स्वचालित करने के लिए आवश्यक है, तो हम सही ढंग से स्वचालित करना शुरू करते हैं और आकाश-उच्च ऊंचाइयों के लिए प्रयास करना जारी रखते हैं।



यह विफलता, जहां कई कीड़े हैं, को सही ढंग से दूर किया जाना चाहिए। इसमें कैसे आना है, मुझे लगता है कि कोई सवाल नहीं है। सवाल यह है कि इससे कैसे बाहर निकला जाए।

हमें मैन्युअल परीक्षण के बिना कैसे रहना है, इस सवाल का जवाब देने की आवश्यकता है। उत्तर यह है कि सर्वर सेट किए बिना कैसे जीना है। जाहिर है कि संभव है। क्या बदल रहा है?

पहले, हमारे पास एक सिस्टम एडमिनिस्ट्रेटर था, जो प्रोडक्ट के लिए प्रोडक्ट तैयार करता था। वह बैठ गया और डेवलपर्स के लिखने का इंतजार कर रहा था। उसके बाद, वह इस उत्पाद को ले गया और सीडी-रोम डालने और तारों को छड़ी करने के लिए चला गया। इस समय अन्य सभी के साथ क्या होता है? बाकी सब इंतजार कर रहे हैं। यह एक अड़चन है, प्लग।



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

परीक्षण के साथ एक ही बात। हमारे पास परीक्षक हैं जो उत्पाद का परीक्षण करते हैं। वे एक उत्पाद लिखने तक इंतजार करते हैं। लिखा - यह परीक्षण करने का समय है। परीक्षण करते समय बाकी सभी क्या करते हैं? वे कुछ नहीं करते, वे प्रतीक्षा कर रहे हैं। हम इसे कैसे हल करेंगे?


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

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

यह सब कुछ स्वचालित करने के लिए रहता है। वास्तव में, हम परीक्षण को स्वचालित कर सकते हैं। समस्या यह है कि आप एक निश्चित भाग को स्वचालित कर सकते हैं।


आप सभी इस चुटकुले को जानते हैं कि कैसे एक परीक्षक बार में प्रवेश करता है, बीयर का ऑर्डर करता है, 0 बियर का ऑर्डर करता है, 99999999999 बीयर का ऑर्डर करता है, एक छिपकली का ऑर्डर करता है, -1 बीयर और ऑर्डर करता है ... यह एक बग है, क्योंकि यह asdfgh होना चाहिए, और यह एक नहीं कचरा।

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



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

, , , . DevOps. , . T- — , .

, - . « », , . , , , . , Selenium . , .

, .



— . , , . . , , Ops- , , , , , , , .



Developers in test — , , . , . , ; — , ; TDD , , , , . , , .



« ». , , , , , — . , , , , , , , , , , Continuous Testing .

end-to-end , . , , DevOps, .

, - , . , 70- : « DevOps, ». , , .

. -, , , , , . : ( EVP Engineering, SignalFx) , , .

70- . . , , . , . , , , , . , , , , — , netflix .

, , , , , , , , , . . , .

, . . « , », — , , .



«, — . — : , , , . , , , , , . . , - , . ? Artifactory , ?!».

, — , . , . ? !



DORA: , , , .



New Work. , New Work Low — 30%, Medium — 40%, High Elite — 50%. ( , Low) , , .

.

Heisenbug 2018 Moscow, — 17-18 Heisenbug. , . , ( ).