परीक्षण वातावरण में निरंतर एकीकरण-कारण अस्थिरताओं से कैसे बचें?


19

मान लें कि आप निरंतर एकीकरण प्रक्रियाओं का उपयोग कर रहे हैं, जो अक्सर कुछ लक्षित वातावरणों को अपडेट करते हैं, ताकि हर बार कुछ बदलाव "आप" तुरंत आपके परिवर्तनों का परीक्षण कर सकें। यह सीआई के लक्ष्यों का हिस्सा है, नहीं?

लेकिन, यह भी मान लें कि आपके पास आपके परीक्षण चक्र में शामिल अन्य लोग हैं, जैसे प्रबंधक या ग्राहक। आपके आगामी परिवर्तनों की समीक्षा (विच्छेद) करने की कोशिश में शामिल अन्य लोगों को पाने के लिए समझ में आता है, नहीं?

लेकिन अगर आप लगातार उस माहौल में बदलाव लाते रहते हैं जिसमें वे अन्य लोग हैं, गंभीरता से, उन्हें परखने की कोशिश कर रहे हैं, तो कई समस्याएँ पैदा हो सकती हैं, जैसे:

  • they उन समस्याओं को रिपोर्ट करने में अपना समय बर्बाद कर सकते हैं, जब तक वे (गहराई से) रिपोर्ट को सहेजते हैं, तब तक वे स्वयं इस मुद्दे को फिर से नहीं दोहरा सकते हैं (उदाहरण के लिए क्योंकि गलती से आप भी उसी मुद्दे पर भाग गए थे, और पहले से ही अपने वातावरण में इसे ठीक कर लिया था)।
  • you हो सकता है कि वे अपने द्वारा रिपोर्ट किए गए मुद्दों को पुन: उत्पन्न करने में सक्षम न हों, क्योंकि जिस वातावरण में वे किसी मुद्दे पर भागे थे, वह अब समान नहीं है (आप (!!!) ने शायद अपने पर्यावरण को ओवरले किया है)।

तो इस तरह की (निराशाजनक) स्थितियों से बचने के लिए आप क्या कर सकते हैं (चीजों को कैसे कॉन्फ़िगर करें?)

जवाबों:


10

मैं इस पर अपना अनुभव दूंगा, ज्यादातर क्योंकि यह दिखाता है कि कुछ जवाब हमेशा लागू नहीं होते हैं।

शुरू करने के लिए कुछ संदर्भ:

  • हमारे पास लगभग host० अनुप्रयोगों की मेजबानी करने के लिए host वातावरण हैं, उनमें से अधिकांश वेबसर्विस या db2-iSeries पर साझा तालिकाओं के माध्यम से एक-दूसरे पर भरोसा करते हैं।
  • अच्छे या बुरे के लिए, iSeries हमारे संदर्भ की DB प्रणाली है।
  • यह अंतिम बिंदु एक अलग वातावरण में अपनी निर्भरता के साथ एप्लिकेशन को लाने के किसी भी विचार को अमान्य करता है क्योंकि प्रत्येक के लिए एक AS400 लाने से बहुत अधिक लागत आएगी और हमारे पास इसे चलाने के लिए हार्डवेयर नहीं होगा।

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

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

लघु संस्करण में पर्यावरण में अनुप्रयोगों के चारों ओर एक 'सेमाफोर' प्रणाली है, एक टीम को मैनुअल परीक्षणों के समय के लिए अपनी निर्भरता (और सकर्मक निर्भरता) के साथ अपने लक्ष्य एप्लिकेशन को लॉक करने में सक्षम होना चाहिए।
इस सेमाफ़ोर का कार्यान्वयन आपके स्वचालन प्रणाली पर अत्यधिक निर्भर है इसलिए मैं उस पर विस्तार नहीं करूँगा।

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


यह उत्तर इस बात की भिन्नता है कि मैं (मेनफ्रेम) के लिए क्या कर रहा हूं, जहां हम कम से कम 1,5 दशक या तो पहले से ही इस तरह की चीजें करते हैं ("DevOps" पैदा होने से पहले)। मुझे आश्चर्य है कि अगर यह मेरे खुद के उत्तर को जोड़ने के लिए समझ में आता है (इस उत्तर पर और विस्तार करने के लिए, हम यह कैसे उदाहरण के लिए "बैंकों" के लिए CMN / ZMF के साथ करते हैं), या बस इसे एक नए (स्व उत्तर) प्रश्न पर ले जाएं। तुम क्या सोचते हो? इसके अलावा, मैं उस रूपक के बारे में उत्सुक हूं, जो एक नए प्रश्न के लायक है (इस उत्तर के संदर्भ में)? पुनश्च: अगर आप कुछ टाइपो को ठीक करते हैं तो आप बुरा मानते हैं?
Pierre.Vriens

संपादित करने के लिए कोई समस्या नहीं है :) मैंने इसे सामान्य रखा, यह एक devops org IMHO के लिए बहुत विशिष्ट नहीं है। फिर से DevOps एक संगठन परिवर्तन है, जो चिंताओं को साझा करके एक बेहतर स्वचालन स्थापित करने में मदद कर सकता है ... इसलिए मैं इसे प्रोग्राम के रूप में एक सेमाफोर कहता हूं, मुझे नहीं लगता कि यह एक प्रश्न के लायक है लेकिन यह आपके ऊपर है
तेंसिबाई

ठीक है, संपादित करें (हमेशा की तरह: रोलबैक / सुधार जैसा कि आप फिट देखते हैं)। BTW, क्या आपके पास अपने कीबोर्ड पर "s" है?!?!? इसके अलावा: सप्ताहांत में सोचने के लिए सामान: मेरे नवीनतम मेटा प्रश्न देखें ... बॉन सप्ताहांत! समय (प्रूनिंग ...) यहाँ पर बागवानी के लिए
Pierre.Vriens

8

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

IMHO आपको अपने CI / CD योग्यता प्रयोजनों के अंदर इस तरह के परीक्षण का उपयोग नहीं करना चाहिए क्योंकि यह आपकी योग्यता प्रक्रिया (उस क्षेत्र में कम से कम) को प्रभावी ढंग से अमान्य कर देगा। यह कहते हुए कि सॉफ़्टवेयर वास्तव में वितरित किए गए प्रत्येक सॉफ़्टवेयर संस्करण के लिए परीक्षण X निष्पादित किए बिना या निश्चितता के बिना परीक्षण X पास करता है कि passप्राप्त परिणाम आकस्मिक नहीं है (झूठी सकारात्मक के कारण) आपके परीक्षण के आत्मविश्वास स्तर को नष्ट कर देगा। गलत नकारात्मक विश्वसनीयता को नुकसान नहीं पहुंचा रहे हैं, लेकिन वे अनावश्यक "शोर" के कारण अवांछित हैं।

आपके CI / CD योग्यता प्रक्रिया के बाहर ऐसे परीक्षण को निष्पादित करना ठीक है । लेकिन आप इस तरह के परीक्षण में एक विफल परिणाम का इलाज एक ग्राहक-पाया बग की तरह करेंगे: आपको इसके लिए एक निश्चित रूप से विकास करने और इस बात की पुष्टि करने में सक्षम होना चाहिए कि फिक्स काम कर रहा है। और आप वास्तव में ऐसा नहीं कर सकते हैं यदि परीक्षण विश्वसनीय नहीं है।

यदि आप समस्या को हल करने की योजना बनाते हैं तो आदर्श रूप से आप पहली बार समस्या को पुन: प्रस्तुत करने के लिए एक स्वचालित, विश्वसनीय परीक्षण मामला विकसित करेंगे। जिसका उपयोग आप एक फिक्स को विकसित करने और इसकी प्रभावशीलता की पुष्टि करने के लिए करेंगे (परीक्षा परिणाम FAIL से PASS में संक्रमण होना चाहिए)। भविष्य में दोबारा होने वाली घटनाओं को रोकने के लिए आप अपने (सीआई) सीडी-क्वालीफिकेशन प्रक्रिया के अंदर इस टेस्टकेस को रख सकते हैं, यदि वांछित हो - अपने समग्र सॉफ्टवेयर रिलीज गुणवत्ता स्तर को बढ़ाने के लिए।


आपके उत्तर में पचाने के लिए बहुत कुछ है (मुझे यकीन नहीं है कि मैं इसे पहले से ही पूरी तरह से प्राप्त करूंगा)। लेकिन आपने " अपने सीआई / सीडी योग्यता प्रक्रिया के बाहर इस तरह के परीक्षण को निष्पादित करें " के बारे में क्या लिखा है : मैं उम्मीद करूंगा कि जो उत्पादित / वितरित किया जाता है उसका अंतिम परिणाम आपके क्यूए और उत्पादों (सीडी के माध्यम से, स्वत: या मैनुअल) में संग्रहीत होता है। लेकिन यह भी " मुझे " लगता है कि सीआई को भी अपना आउटपुट देना चाहिए, जबकि "बाहर" को अलगाव या दोहराव या कुछ और लगता है, नहीं?
Pierre.Vriens

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

7

विभिन्न वातावरण बनाने के लिए सामान्य दृष्टिकोण है:

DEV - यह वह स्थान है जहाँ देव टीम चीजों को गड़बड़ करती है। यहां सभी परिवर्तन ट्यूनिंग बनाएं, नए संस्करण को तैनात करें और इसी तरह। यहां वह स्थान है जहां CI को पूरी तरह से एकीकृत किया गया है।

PREPROD / QA - यह वह जगह है जो "खेल" QA / परीक्षण / सत्यापन टीम परीक्षण करती है। यह वातावरण आमतौर पर परीक्षणों के दौरान जम जाता है। इस वातावरण के साथ CI का एकीकरण केवल उत्पाद के नए संस्करण, विन्यास आदि प्रदान करना है।

प्रोडक्शन - क्या इसे समझाने की ज़रूरत है :)?


ठीक है, कि स्थिरता में सुधार करने में मदद करनी चाहिए, योग्यता! मेरा प्रश्न "परीक्षण" वातावरण के बारे में है, इसलिए स्पष्ट रूप से "उत्पादन" को ऐसा नहीं माना जाना चाहिए। परीक्षण के लिए "उत्पादन" का उपयोग करने वालों के बावजूद, आप यह कहते हैं कि " सबसे अच्छा परीक्षण उत्पादन में इसे सक्रिय करना है, और यदि यह काम नहीं करता है, तो बस एक रोलबैक / बैकआउट करें "!
Pierre.Vriens

@ पियरे.वीयरेंस, IMHO के उत्पादों में "खेल" बुद्धिमान नहीं है :) पर्यावरण का ऐसा अलगाव जानबूझकर नहीं है। पिछली नौकरी में हमारे पास 5 अलग-अलग वातावरण थे .... एक मतदाता सीरियस
रोमियो निनोव

1
"मैं" मानता हूं कि इस तरह का खेल बुद्धिमान नहीं है। हालाँकि, काउबॉय के बारे में "आप" क्या कर सकते हैं (मेरे 'शब्द' मैं ऐसे जुप्पियों के लिए उपयोग करता हूं) जो इस पर और बार-बार करते रहते हैं, और हर बार उन्हें अपने प्रबंधकों से लगभग (जैसे) मासिक रिलीज सक्रियता प्राप्त करने के लिए मंजूरी मिलती है , अभी तक एक और बगफिक्स (जैसे पहले दिन से उनके बगफिक्स के लिए ... जिसने एक नया बग पेश किया)। आपको लगता है कि वास्तविक दुनिया में ऐसा नहीं होता है? BTW: अपने जवाब में "फ्रीज" के बारे में, आपको लगता है कि यह एक प्रश्न को पोस्ट करने के लिए समझ में आता है जैसे "जमे हुए वातावरण के नमूना कार्यान्वयन क्या हैं?"
Pierre.Vriens

@ पियरे.वीयरेंस, मेरे लिए इस तरह के प्रश्न को पोस्ट करना सही अर्थ है। आम तौर पर इसे कंपनी के नियमों द्वारा नियंत्रित किया जाता है, लेकिन डेप्स काफी गतिशील वातावरण बनाते हैं और इससे वास्तविक चुनौती मिल सकती है :)
रोमियो निनोव

1
यह मेरा पसंदीदा तरीका है, इस तरह यह एक ऐसा वातावरण देता है जहाँ देवता अपने वातावरण को तुरंत एक एकीकृत वातावरण में परख सकते हैं, लेकिन क्यूए को तब तक साफ रखते हैं जब तक कोड औपचारिक रूप से परीक्षण के लिए तैयार न हो जाए
तायगेस्ट

3

यदि आप CI / CD कर रहे हैं, तो इसका मतलब है कि तैनाती (CD) से पहले कुछ स्वचालित परीक्षण (CI) हो रहे हैं। यदि आप अपने परीक्षण के माहौल में बहुत सारे मुद्दे खोज रहे हैं, तो इसका मतलब है कि वे तैनाती से पहले चलाए जा रहे परीक्षणों से नहीं पकड़े जा रहे हैं; यह अपर्याप्त स्वचालित परीक्षण इंगित करता है। यदि डेवलपर्स में ऐसे मुद्दे हैं, जहां परीक्षण वातावरण में दोष उत्पन्न हो रहे हैं, तो इसे रोकने के लिए उन्हें अपने स्वचालित परीक्षण सूट में सुधार करना होगा। इससे गुणवत्ता और विश्वसनीयता में भी सुधार होगा, सभी तरह के उत्पादन में।


3

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

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

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


दिलचस्प दृष्टिकोण / परिवर्धन, हालांकि इसमें कुछ चीजें हैं जो शायद आप इस संदर्भ में परिष्कृत / पुनः काम करना चाहते हैं: (1) "आवेदन", आपका क्या मतलब है (कुछ उदाहरण?) (2) किसी भी विचार यह कैसे काम कर सकता है? (अच्छा पुराना) मेनफ्रेम वातावरण (3) इस संदर्भ में एक "माइटिगेंट" क्या है? PS: मुझे बताएं कि क्या आपको लगता है कि मुझे इनमें से किसी भी "चीज़" (गोलियों) के लिए एक नया प्रश्न बनाना चाहिए।
Pierre.Vriens
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.