भाग १: वेब/अँड्रॉइड

शेरा: हा लेख मूळ लेखाचा रशियन भाषेत अनुवाद आहे “DevOps टूल्स फक्त DevOps साठी नाहीत. "स्क्रॅचमधून बिल्डिंग टेस्ट ऑटोमेशन इन्फ्रास्ट्रक्चर." तथापि, रशियन भाषेत अनुवादित करताना अर्थाचा विपर्यास टाळण्यासाठी सर्व चित्रे, दुवे, अवतरण आणि संज्ञा मूळ भाषेत जतन केल्या जातात. मी तुम्हाला आनंदी अभ्यास करू इच्छितो!

सध्या, DevOps स्पेशॅलिटी ही आयटी उद्योगात सर्वाधिक मागणी आहे. तुम्ही लोकप्रिय जॉब सर्च साइट्स उघडल्यास आणि पगारानुसार फिल्टर केल्यास, तुम्हाला DevOps-संबंधित नोकर्‍या सूचीच्या शीर्षस्थानी असल्याचे दिसेल. तथापि, हे समजून घेणे महत्त्वाचे आहे की हे मुख्यत्वे 'वरिष्ठ' पदाचा संदर्भ देते, ज्याचा अर्थ उमेदवाराकडे उच्च दर्जाचे कौशल्य, तंत्रज्ञान आणि साधनांचे ज्ञान आहे. हे उत्पादनाच्या अखंडित कार्याशी संबंधित उच्च जबाबदारीसह देखील येते. मात्र, DevOps म्हणजे काय हे आम्ही विसरायला लागलो. सुरुवातीला ती कोणतीही विशिष्ट व्यक्ती किंवा विभाग नव्हती. जर आपण या संज्ञेच्या व्याख्या शोधल्या तर आपल्याला अनेक सुंदर आणि योग्य संज्ञा सापडतील, जसे की कार्यपद्धती, पद्धती, सांस्कृतिक तत्त्वज्ञान, संकल्पनांचा समूह, इत्यादी.

माझे स्पेशलायझेशन चाचणी ऑटोमेशन अभियंता (क्यूए ऑटोमेशन अभियंता) आहे, परंतु माझा विश्वास आहे की ते केवळ स्वयं-चाचण्या लिहिण्याशी किंवा चाचणी फ्रेमवर्क आर्किटेक्चर विकसित करण्याशी संबंधित नसावे. 2020 मध्ये, ऑटोमेशन इन्फ्रास्ट्रक्चरचे ज्ञान देखील आवश्यक आहे. हे तुम्हाला ऑटोमेशन प्रक्रिया स्वतः आयोजित करण्यास अनुमती देते, चाचण्या चालवण्यापासून ते तुमच्या उद्दिष्टांनुसार सर्व भागधारकांना परिणाम प्रदान करण्यापर्यंत. परिणामी, काम पूर्ण करण्यासाठी DevOps कौशल्ये आवश्यक आहेत. आणि हे सर्व चांगले आहे, परंतु, दुर्दैवाने, एक समस्या आहे (spoiler: हा लेख ही समस्या सोपी करण्याचा प्रयत्न करतो). मुद्दा असा आहे की DevOps कठीण आहे. आणि हे स्पष्ट आहे, कारण कंपन्या सोप्या गोष्टीसाठी जास्त पैसे देणार नाहीत... DevOps जगात, मोठ्या संख्येने साधने, अटी आणि पद्धती आहेत ज्यात प्रभुत्व मिळवणे आवश्यक आहे. करिअरच्या सुरुवातीला हे विशेषतः कठीण आहे आणि ते संचित तांत्रिक अनुभवावर अवलंबून असते.

स्त्रोत: http://maximelanciauxbi.blogspot.com/2017/04/devops-tools.html

येथे आपण कदाचित प्रास्ताविक भाग पूर्ण करू आणि या लेखाच्या उद्देशावर लक्ष केंद्रित करू. 

हा लेख कशाबद्दल आहे?

या लेखात, मी चाचणी ऑटोमेशन इन्फ्रास्ट्रक्चर तयार करण्याचा माझा अनुभव शेअर करणार आहे. इंटरनेटवर विविध साधने आणि त्यांचा वापर कसा करायचा याबद्दल माहितीचे अनेक स्त्रोत आहेत, परंतु मी त्यांना पूर्णपणे ऑटोमेशनच्या संदर्भात पाहू इच्छितो. माझा विश्वास आहे की अनेक ऑटोमेशन अभियंते परिस्थितीशी परिचित आहेत जेव्हा तुमच्याशिवाय कोणीही विकसित चाचण्या चालवत नाही किंवा त्यांच्या देखभालीची काळजी घेत नाही. परिणामी, चाचण्या कालबाह्य होतात आणि तुम्हाला त्या अपडेट करण्यात वेळ घालवावा लागतो. पुन्हा, करिअरच्या सुरुवातीस, हे खूप कठीण काम असू शकते: दिलेल्या समस्येचे निराकरण करण्यासाठी कोणती साधने मदत करावी, त्यांची निवड कशी करावी, कॉन्फिगर आणि देखभाल कशी करावी हे सुज्ञपणे ठरवणे. काही परीक्षक मदतीसाठी DevOps (मानवांकडे) वळतात आणि, प्रामाणिकपणे सांगूया, हा दृष्टिकोन कार्य करतो. बर्‍याच प्रकरणांमध्ये हा एकमेव पर्याय असू शकतो कारण आमच्याकडे सर्व अवलंबनांमध्ये दृश्यमानता नसते. परंतु आम्हाला माहिती आहे की, DevOps खूप व्यस्त आहेत, कारण त्यांना संपूर्ण कंपनीच्या पायाभूत सुविधा, तैनाती, देखरेख, मायक्रोसर्व्हिसेस आणि इतर तत्सम कामांचा संस्थे/टीमवर अवलंबून विचार करावा लागतो. जसे सामान्यतः प्रकरण आहे, ऑटोमेशनला प्राधान्य नाही. अशा वेळी आपण सुरुवातीपासून शेवटपर्यंत सर्व काही करण्याचा प्रयत्न केला पाहिजे. हे अवलंबित्व कमी करेल, कार्यप्रवाह गतिमान करेल, आमची कौशल्ये सुधारेल आणि आम्हाला काय घडत आहे याचे मोठे चित्र पाहण्यास अनुमती देईल.

लेख सर्वात लोकप्रिय आणि लोकप्रिय साधने सादर करतो आणि टप्प्याटप्प्याने ऑटोमेशन इन्फ्रास्ट्रक्चर तयार करण्यासाठी त्यांचा वापर कसा करावा हे दर्शवितो. प्रत्येक गट वैयक्तिक अनुभवाद्वारे चाचणी केलेल्या साधनांद्वारे दर्शविला जातो. पण याचा अर्थ असा नाही की तुम्हाला तीच गोष्ट वापरावी लागेल. साधने स्वतःच महत्त्वाची नसतात, ती दिसतात आणि अप्रचलित होतात. आमचे अभियांत्रिकी कार्य हे मूलभूत तत्त्वे समजून घेणे आहे: आम्हाला या साधनांच्या गटाची आवश्यकता का आहे आणि त्यांच्या मदतीने आम्ही कोणत्या कामाच्या समस्या सोडवू शकतो. म्हणूनच प्रत्येक विभागाच्या शेवटी मी तुमच्या संस्थेमध्ये वापरल्या जाणाऱ्या तत्सम साधनांच्या लिंक्स सोडतो.

या लेखात काय नाही

मी पुन्हा एकदा पुनरावृत्ती करतो की लेख विशिष्ट साधनांबद्दल नाही, म्हणून दस्तऐवजीकरण आणि विशिष्ट आदेशांच्या वर्णनातून कोडचे कोणतेही इन्सर्ट केले जाणार नाहीत. पण प्रत्येक विभागाच्या शेवटी मी तपशीलवार अभ्यासासाठी दुवे सोडतो.

हे केले जाते कारण: 

• ही सामग्री विविध स्त्रोतांमध्ये (दस्तऐवजीकरण, पुस्तके, व्हिडिओ अभ्यासक्रम) शोधणे खूप सोपे आहे;
• जर आपण अधिक खोलवर जाऊ लागलो तर आपल्याला या लेखाचे 10, 20, 30 भाग लिहावे लागतील (योजना 2-3 असताना);
• मला तुमचा वेळ वाया घालवायचा नाही कारण तुम्हाला तीच ध्येये साध्य करण्यासाठी इतर साधने वापरायची असतील.

सराव

मला ही सामग्री प्रत्येक वाचकासाठी उपयुक्त ठरेल, आणि फक्त वाचून विसरले जाऊ नये असे वाटते. कोणत्याही अभ्यासात सराव हा अत्यंत महत्त्वाचा घटक असतो. त्यासाठी मी तयारी केली आहे सुरवातीपासून सर्वकाही कसे करावे यावरील चरण-दर-चरण सूचनांसह GitHub भांडार. तुम्‍ही अंमलात आणत असलेल्‍या कमांडस्च्‍या ओळी तुम्ही बेफिकीरपणे कॉपी करत नाही याची खात्री करण्‍यासाठी तुमच्‍या प्रतीक्षेत गृहपाठ देखील आहे.

योजना

पाऊल
तंत्रज्ञान
साधने

1
स्थानिक धावणे (वेब ​​/ अँड्रॉइड डेमो चाचण्या तयार करा आणि स्थानिक पातळीवर चालवा) 
Node.js, Selenium, Appium

2
आवृत्ती नियंत्रण प्रणाली 
Git

3
कंटेनरायझेशन
डॉकर, सेलेनियम ग्रिड, सेलेनोइड (वेब, अँड्रॉइड)

4
CI/CD
Gitlab CI

5
मेघ प्लॅटफॉर्म
Google Cloud Platform

6
ऑर्केस्ट्रेशन
कुबेरनेट्स

7
कोड म्हणून पायाभूत सुविधा (IaC)
टेराफॉर्म, उत्तरदायी

प्रत्येक विभागाची रचना

कथा स्पष्ट ठेवण्यासाठी, प्रत्येक विभागाचे वर्णन खालील रूपरेषेनुसार केले आहे:

• तंत्रज्ञानाचे संक्षिप्त वर्णन,
• ऑटोमेशन पायाभूत सुविधांसाठी मूल्य,
• पायाभूत सुविधांच्या सद्य स्थितीचे चित्रण,
• अभ्यासाच्या लिंक्स,
• समान साधने.

1. स्थानिक पातळीवर चाचण्या चालवा

तंत्रज्ञानाचे संक्षिप्त वर्णन

डेमो चाचण्या स्थानिक पातळीवर चालवण्यासाठी आणि त्या उत्तीर्ण झाल्याची पडताळणी करण्यासाठी ही फक्त एक तयारीची पायरी आहे. व्यावहारिक भागामध्ये, Node.js वापरला जातो, परंतु प्रोग्रामिंग भाषा आणि प्लॅटफॉर्म देखील महत्त्वाचे नाहीत आणि तुम्ही ते वापरू शकता जे तुमच्या कंपनीमध्ये वापरले जातात. 

तथापि, ऑटोमेशन टूल्स म्हणून, मी अनुक्रमे वेब प्लॅटफॉर्मसाठी Selenium WebDriver आणि Android प्लॅटफॉर्मसाठी Appium वापरण्याची शिफारस करतो, कारण पुढील चरणांमध्ये आम्ही या साधनांसह विशेषतः काम करण्यासाठी तयार केलेल्या डॉकर प्रतिमा वापरू. शिवाय, नोकरीच्या गरजांचा संदर्भ देताना, या साधनांना बाजारात सर्वाधिक मागणी आहे.

तुमच्या लक्षात आले असेल की, आम्ही फक्त वेब आणि Android चाचण्यांचा विचार करतो. दुर्दैवाने, iOS ही पूर्णपणे वेगळी कथा आहे (धन्यवाद Appleपल). मी आगामी भागांमध्ये IOS संबंधित उपाय आणि पद्धती प्रदर्शित करण्याची योजना आखत आहे.

ऑटोमेशन पायाभूत सुविधांसाठी मूल्य

पायाभूत सुविधांच्या दृष्टीकोनातून, स्थानिक पातळीवर धावणे कोणतेही मूल्य प्रदान करत नाही. तुम्ही फक्त स्थानिक ब्राउझर आणि सिम्युलेटरमध्ये स्थानिक मशीनवर चाचण्या चालतात हे तपासा. परंतु कोणत्याही परिस्थितीत, हा एक आवश्यक प्रारंभिक बिंदू आहे.

पायाभूत सुविधांच्या सद्य स्थितीचे चित्रण

एक्सप्लोर करण्यासाठी लिंक्स

• सेलेनियम
• अॅपिअस
• अँड्रॉइड एमुलेटर
• सेलेनियम जेएस गिटहब उदाहरणे
• Appium JS GitHub उदाहरणे

तत्सम साधने

• सेलेनियम/एपियम चाचण्यांसह तुम्हाला आवडणारी कोणतीही प्रोग्रामिंग भाषा;
• कोणत्याही चाचण्या;
• कोणताही चाचणी धावपटू.

2. आवृत्ती नियंत्रण प्रणाली (Git)

तंत्रज्ञानाचे संक्षिप्त वर्णन

आवृत्ती नियंत्रण हा विकासाचा एक अत्यंत महत्त्वाचा भाग आहे असे मी म्हटले तर कोणासाठीही हे मोठे प्रकटीकरण होणार नाही, दोन्ही संघात आणि वैयक्तिकरित्या. विविध स्त्रोतांच्या आधारावर, हे सांगणे सुरक्षित आहे की गिट सर्वात लोकप्रिय प्रतिनिधी आहे. आवृत्ती नियंत्रण प्रणाली कोड सामायिकरण, आवृत्त्या संग्रहित करणे, मागील शाखांमध्ये पुनर्संचयित करणे, प्रकल्प इतिहासाचे निरीक्षण करणे आणि बॅकअप यासारखे अनेक फायदे प्रदान करते. आम्ही प्रत्येक मुद्यावर तपशीलवार चर्चा करणार नाही, कारण मला खात्री आहे की तुम्हाला ते खूप परिचित आहे आणि तुमच्या दैनंदिन कामात त्याचा वापर करा. परंतु जर अचानक नाही, तर मी हा लेख वाचण्यास विराम देण्याची आणि शक्य तितक्या लवकर ही अंतर भरण्याची शिफारस करतो.

ऑटोमेशन पायाभूत सुविधांसाठी मूल्य

आणि इथे तुम्ही एक वाजवी प्रश्न विचारू शकता: “तो आम्हाला Git बद्दल का सांगत आहे? प्रत्येकाला हे माहित आहे आणि ते विकास कोड आणि स्वयं-चाचणी कोड दोन्हीसाठी वापरते. तुमचे म्हणणे अगदी बरोबर असेल, परंतु या लेखात आम्ही पायाभूत सुविधांबद्दल बोलत आहोत आणि हा विभाग कलम 7 साठी पूर्वावलोकन म्हणून काम करतो: “पायाभूत सुविधा म्हणून कोड (IaC)”. आमच्यासाठी, याचा अर्थ असा आहे की चाचणीसह संपूर्ण पायाभूत सुविधा कोडच्या स्वरूपात वर्णन केल्या आहेत, त्यामुळे आम्ही त्यावर आवृत्ती प्रणाली लागू करू शकतो आणि विकास आणि ऑटोमेशन कोड प्रमाणेच फायदे मिळवू शकतो.

आम्ही IaC कडे अधिक तपशीलवार पायरी 7 मध्ये पाहू, परंतु आताही तुम्ही स्थानिक रेपॉजिटरी तयार करून Git वापरण्यास प्रारंभ करू शकता. जेव्हा आम्ही पायाभूत सुविधांमध्ये रिमोट रिपॉझिटरी जोडतो तेव्हा मोठे चित्र विस्तृत केले जाईल.

पायाभूत सुविधांच्या सद्य स्थितीचे चित्रण

एक्सप्लोर करण्यासाठी लिंक्स

• आवृत्ती नियंत्रण म्हणजे काय
• Git
• प्रारंभ करणे - आवृत्ती नियंत्रण बद्दल

तत्सम साधने

• एसव्हीएन
• मर्क्युरीअल 
• Microsoft TFS (आता Azure DevOps सेवांचा भाग आहे)

3. कंटेनरायझेशन (डॉकर)

तंत्रज्ञानाचे संक्षिप्त वर्णन

कंटेनरायझेशनने खेळाचे नियम कसे बदलले आहेत हे दाखवण्यासाठी, काही दशके मागे जाऊ या. पूर्वी, लोकांनी अनुप्रयोग चालविण्यासाठी सर्व्हर मशीन खरेदी केली आणि वापरली. परंतु बहुतेक प्रकरणांमध्ये, आवश्यक स्टार्टअप संसाधने आगाऊ माहित नव्हती. परिणामी, कंपन्यांनी महागड्या, शक्तिशाली सर्व्हरच्या खरेदीवर पैसे खर्च केले, परंतु यापैकी काही क्षमता पूर्णपणे वापरली गेली नाही.

उत्क्रांतीचा पुढचा टप्पा व्हर्च्युअल मशीन्स (व्हीएम) होता, ज्याने न वापरलेल्या संसाधनांवर पैसे वाया घालवण्याची समस्या सोडवली. या तंत्रज्ञानामुळे पूर्णपणे वेगळ्या जागेचे वाटप करून एकाच सर्व्हरमध्ये एकमेकांपासून स्वतंत्रपणे अनुप्रयोग चालवणे शक्य झाले. परंतु, दुर्दैवाने, कोणत्याही तंत्रज्ञानामध्ये त्याचे तोटे आहेत. VM चालवण्यासाठी संपूर्ण ऑपरेटिंग सिस्टमची आवश्यकता असते, जी CPU, RAM, स्टोरेज वापरते आणि OS वर अवलंबून, परवाना खर्च विचारात घेणे आवश्यक आहे. हे घटक लोडिंगच्या गतीवर परिणाम करतात आणि पोर्टेबिलिटी कठीण करतात.

आणि आता आपण कंटेनरायझेशनवर येतो. पुन्हा एकदा, हे तंत्रज्ञान मागील समस्येचे निराकरण करते, कारण कंटेनर पूर्ण OS वापरत नाहीत, जे मोठ्या प्रमाणात संसाधने मुक्त करते आणि पोर्टेबिलिटीसाठी जलद आणि लवचिक समाधान प्रदान करते.

अर्थात, कंटेनरायझेशन तंत्रज्ञान काही नवीन नाही आणि ते 70 च्या दशकाच्या उत्तरार्धात प्रथम सादर केले गेले. त्या दिवसांत, बरेच संशोधन, घडामोडी आणि प्रयत्न केले गेले. पण डॉकरनेच हे तंत्रज्ञान स्वीकारले आणि ते सर्वसामान्यांना सहज उपलब्ध करून दिले. आजकाल, जेव्हा आपण कंटेनरबद्दल बोलतो तेव्हा बहुतेक प्रकरणांमध्ये आपला अर्थ डॉकर असा होतो. जेव्हा आपण डॉकर कंटेनर्सबद्दल बोलतो तेव्हा आपला अर्थ लिनक्स कंटेनर असतो. आम्ही कंटेनर चालविण्यासाठी Windows आणि macOS प्रणाली वापरू शकतो, परंतु हे समजून घेणे महत्त्वाचे आहे की या प्रकरणात एक अतिरिक्त स्तर दिसतो. उदाहरणार्थ, मॅकवरील डॉकर हलक्या वजनाच्या लिनक्स व्हीएममध्ये शांतपणे कंटेनर चालवतात. जेव्हा आम्ही कंटेनरमध्ये Android एमुलेटर चालवण्याबद्दल चर्चा करू तेव्हा आम्ही या विषयावर परत येऊ, म्हणून येथे एक अतिशय महत्त्वाचा मुद्दा आहे ज्यावर अधिक तपशीलवार चर्चा करणे आवश्यक आहे.

ऑटोमेशन पायाभूत सुविधांसाठी मूल्य

आम्हाला आढळले की कंटेनरायझेशन आणि डॉकर छान आहेत. चला हे ऑटोमेशनच्या संदर्भात पाहू, कारण प्रत्येक साधन किंवा तंत्रज्ञानाने समस्या सोडवणे आवश्यक आहे. चला UI चाचण्यांच्या संदर्भात चाचणी ऑटोमेशनच्या स्पष्ट समस्यांची रूपरेषा देऊ:

• सेलेनियम आणि विशेषत: अॅपियम स्थापित करताना मोठ्या संख्येने अवलंबन;
• ब्राउझर, सिम्युलेटर आणि ड्रायव्हर्सच्या आवृत्त्यांमधील सुसंगतता समस्या;
• ब्राउझर/सिम्युलेटर्ससाठी वेगळ्या जागेचा अभाव, जे समांतर चालण्यासाठी विशेषतः गंभीर आहे;
• तुम्हाला एकाच वेळी 10, 50, 100 किंवा अगदी 1000 ब्राउझर चालवायचे असल्यास व्यवस्थापित करणे आणि देखरेख करणे कठीण आहे.

परंतु सेलेनियम हे सर्वात लोकप्रिय ऑटोमेशन साधन असल्याने आणि डॉकर हे सर्वात लोकप्रिय कंटेनरायझेशन साधन असल्याने, वर नमूद केलेल्या समस्यांचे निराकरण करण्यासाठी कोणीतरी एक शक्तिशाली साधन तयार करण्यासाठी त्यांना एकत्र करण्याचा प्रयत्न केला आहे हे आश्चर्यचकित होऊ नये. चला अशा उपायांचा अधिक तपशीलवार विचार करूया. 

डॉकरमध्ये सेलेनियम ग्रिड

एकाधिक मशीनवर एकाधिक ब्राउझर चालविण्यासाठी आणि मध्यवर्ती हबमधून त्यांचे व्यवस्थापन करण्यासाठी हे साधन सेलेनियम जगात सर्वात लोकप्रिय आहे. सुरू करण्यासाठी, तुम्हाला किमान 2 भागांची नोंदणी करणे आवश्यक आहे: हब आणि नोड(चे). हब हा एक मध्यवर्ती नोड आहे जो चाचण्यांमधून सर्व विनंत्या प्राप्त करतो आणि त्यांना योग्य नोड्समध्ये वितरित करतो. प्रत्येक नोडसाठी आम्ही विशिष्ट कॉन्फिगरेशन कॉन्फिगर करू शकतो, उदाहरणार्थ, इच्छित ब्राउझर आणि त्याची आवृत्ती निर्दिष्ट करून. तथापि, आम्हाला अद्याप सुसंगत ब्राउझर ड्रायव्हर्सची स्वतःची काळजी घेणे आणि त्यांना इच्छित नोड्सवर स्थापित करणे आवश्यक आहे. या कारणास्तव, सेलेनियम ग्रिड त्याच्या शुद्ध स्वरूपात वापरली जात नाही, जेव्हा आम्हाला Linux OS वर स्थापित केले जाऊ शकत नाही अशा ब्राउझरसह कार्य करण्याची आवश्यकता असते. इतर सर्व प्रकरणांसाठी, सेलेनियम ग्रिड हब आणि नोड्स चालविण्यासाठी डॉकर प्रतिमा वापरणे हा एक लक्षणीय लवचिक आणि योग्य उपाय असेल. हा दृष्टिकोन नोड व्यवस्थापनास मोठ्या प्रमाणात सुलभ करतो, कारण आम्ही आधीपासून स्थापित ब्राउझर आणि ड्रायव्हर्सच्या सुसंगत आवृत्त्यांसह आम्हाला आवश्यक असलेली प्रतिमा निवडू शकतो.

स्थिरतेबद्दल नकारात्मक पुनरावलोकने असूनही, विशेषत: समांतरमध्ये मोठ्या संख्येने नोड्स चालवताना, सेलेनियम ग्रिड हे समांतरपणे सेलेनियम चाचण्या चालविण्यासाठी सर्वात लोकप्रिय साधन आहे. हे लक्षात घेणे महत्त्वाचे आहे की या साधनातील विविध सुधारणा आणि बदल सतत मुक्त-स्रोतमध्ये दिसून येत आहेत, जे विविध अडथळ्यांचा सामना करतात.

वेबसाठी सेलेनोइड

हे साधन सेलेनियमच्या जगात एक प्रगती आहे कारण ते अगदी बॉक्सच्या बाहेर काम करते आणि अनेक ऑटोमेशन अभियंत्यांचे जीवन खूप सोपे केले आहे. सर्व प्रथम, हे सेलेनियम ग्रिडचे दुसरे बदल नाही. त्याऐवजी, विकसकांनी गोलंगमध्ये सेलेनियम हबची पूर्णपणे नवीन आवृत्ती तयार केली, जी विविध ब्राउझरसाठी लाइटवेट डॉकर प्रतिमांसह एकत्रितपणे चाचणी ऑटोमेशनच्या विकासास चालना देते. शिवाय, सेलेनियम ग्रिडच्या बाबतीत, आम्ही सर्व आवश्यक ब्राउझर आणि त्यांच्या आवृत्त्या आधीच निश्चित केल्या पाहिजेत, जे केवळ एका ब्राउझरसह कार्य करताना समस्या नाही. परंतु जेव्हा एकाधिक समर्थित ब्राउझरचा विचार केला जातो, तेव्हा सेलेनोइड त्याच्या 'मागणीवर ब्राउझर' वैशिष्ट्यामुळे प्रथम क्रमांकाचे समाधान आहे. आमच्यासाठी आवश्यक असलेली सर्व आवश्यक प्रतिमा ब्राउझरसह आगाऊ डाउनलोड करणे आणि कॉन्फिगरेशन फाइल अद्यतनित करणे आहे ज्यासह सेलेनोइड संवाद साधते. Selenoid चाचण्यांमधून विनंती प्राप्त केल्यानंतर, तो इच्छित ब्राउझरसह इच्छित कंटेनर स्वयंचलितपणे लॉन्च करेल. चाचणी पूर्ण झाल्यावर, सेलेनोइड कंटेनर निवृत्त करेल, ज्यामुळे भविष्यातील विनंत्यांसाठी संसाधने मोकळी होतील. हा दृष्टीकोन 'नोड डिग्रेडेशन' ची सुप्रसिद्ध समस्या पूर्णपणे काढून टाकतो जी आपण अनेकदा सेलेनियम ग्रिडमध्ये अनुभवतो.

पण, अरेरे, सेलेनोइड अजूनही चांदीची बुलेट नाही. आम्हाला 'मागणीवर ब्राउझर' वैशिष्ट्य मिळाले, परंतु 'मागणीनुसार संसाधने' वैशिष्ट्य अद्याप उपलब्ध नाही. Selenoid वापरण्यासाठी, आम्ही ते भौतिक हार्डवेअरवर किंवा VM वर तैनात केले पाहिजे, याचा अर्थ आम्हाला किती संसाधने वाटप करणे आवश्यक आहे हे आधीच माहित असणे आवश्यक आहे. मला वाटते की समांतर 10, 20 किंवा 30 ब्राउझर चालवणार्‍या छोट्या प्रकल्पांसाठी ही समस्या नाही. पण 100, 500, 1000 किंवा त्याहून अधिक गरज असल्यास काय? अनेक संसाधने कायम राखण्यात आणि त्यासाठी पैसे देण्यात काहीच अर्थ नाही. या लेखाच्या कलम 5 आणि 6 मध्ये, आम्ही अशा उपायांवर चर्चा करू जे तुम्हाला स्केल करू देतात, ज्यामुळे कंपनीच्या खर्चात लक्षणीय घट होईल.

Android साठी Selenoid

वेब ऑटोमेशन टूल म्हणून सेलेनोइडच्या यशानंतर, लोकांना Android साठी असेच काहीतरी हवे होते. आणि ते घडले - सेलेनोइड Android समर्थनासह सोडले गेले. उच्च-स्तरीय वापरकर्त्याच्या दृष्टिकोनातून, ऑपरेशनचे सिद्धांत वेब ऑटोमेशनसारखेच आहे. फरक एवढाच आहे की ब्राउझर कंटेनरऐवजी, सेलेनोइड Android एमुलेटर कंटेनर चालवते. माझ्या मते, समांतरपणे Android चाचण्या चालविण्यासाठी हे सध्या सर्वात शक्तिशाली विनामूल्य साधन आहे.

मला या साधनाच्या नकारात्मक पैलूंबद्दल बोलणे खरोखर आवडणार नाही, कारण मला ते खरोखर आवडते. परंतु तरीही, वेब ऑटोमेशनवर लागू होणारे आणि स्केलिंगशी संबंधित समान तोटे आहेत. या व्यतिरिक्त, आम्हाला आणखी एका मर्यादेबद्दल बोलण्याची गरज आहे जी आम्ही पहिल्यांदाच टूल सेट करत असल्यास आश्चर्यचकित होऊ शकते. Android प्रतिमा चालवण्यासाठी, आम्हाला नेस्टेड व्हर्च्युअलायझेशन समर्थनासह एक भौतिक मशीन किंवा VM आवश्यक आहे. कसे करावे या मार्गदर्शकामध्ये, मी हे Linux VM वर कसे सक्षम करायचे ते दाखवतो. तथापि, जर तुम्ही macOS वापरकर्ता असाल आणि स्थानिक पातळीवर Selenoid उपयोजित करू इच्छित असाल, तर Android चाचण्या चालवणे शक्य होणार नाही. परंतु तुम्ही नेहमी स्थानिक पातळीवर 'नेस्टेड व्हर्च्युअलायझेशन' कॉन्फिगर करून Linux VM चालवू शकता आणि आत Selenoid तैनात करू शकता.

पायाभूत सुविधांच्या सद्य स्थितीचे चित्रण

या लेखाच्या संदर्भात, आम्ही पायाभूत सुविधा स्पष्ट करण्यासाठी 2 साधने जोडू. हे वेब चाचण्यांसाठी सेलेनियम ग्रिड आणि Android चाचण्यांसाठी सेलेनोइड आहेत. GitHub ट्यूटोरियलमध्ये, मी तुम्हाला वेब चाचण्या चालवण्यासाठी Selenoid कसे वापरायचे ते देखील दाखवतो. 

एक्सप्लोर करण्यासाठी लिंक्स

• डॉकर: कंटेनर काय आहे
• डॉकर: प्रारंभ करा
• डॉकरसाठी 5 कंटेनर पर्याय
• सेलेनियम ग्रिड
• सेलेनियम डॉकर
• सेलेनोइड
• सेलेनोइड गिथब
• Android एमुलेटरसाठी KVM सेटअप
• डॉकर डीप डायव्ह पुस्तक

तत्सम साधने

• इतर कंटेनरायझेशन साधने आहेत, परंतु डॉकर सर्वात लोकप्रिय आहे. तुम्हाला दुसरे काहीतरी करून पहायचे असल्यास, हे लक्षात ठेवा की सेलेनियम चाचण्या समांतर चालवण्यासाठी आम्ही कव्हर केलेली साधने बॉक्सच्या बाहेर काम करणार नाहीत.  
• आधीच म्हटल्याप्रमाणे, सेलेनियम ग्रिडमध्ये अनेक बदल आहेत, उदाहरणार्थ, झालेनियम.

4.CI/CD

तंत्रज्ञानाचे संक्षिप्त वर्णन

सतत एकत्रीकरणाचा सराव विकासामध्ये खूप लोकप्रिय आहे आणि आवृत्ती नियंत्रण प्रणालीच्या बरोबरीने आहे. असे असूनही मला असे वाटते की पारिभाषिक शब्दांमध्ये गोंधळ आहे. या परिच्छेदात मी माझ्या दृष्टिकोनातून या तंत्रज्ञानातील 3 सुधारणांचे वर्णन करू इच्छितो. इंटरनेटवर तुम्हाला वेगवेगळ्या व्याख्यांसह अनेक लेख सापडतील आणि तुमचे मत वेगळे असल्यास ते अगदी सामान्य आहे. सर्वात महत्वाची गोष्ट म्हणजे तुम्ही तुमच्या सहकाऱ्यांसोबत एकाच पानावर आहात.

तर, 3 अटी आहेत: CI - सतत एकत्रीकरण, CD - सतत वितरण आणि पुन्हा CD - सतत तैनाती. (खाली मी या संज्ञा इंग्रजीत वापरेन). प्रत्येक सुधारणा तुमच्या विकास पाइपलाइनमध्ये अनेक अतिरिक्त पायऱ्या जोडते. पण शब्द सतत (सतत) ही सर्वात महत्वाची गोष्ट आहे. या संदर्भात, आमचा अर्थ असा आहे की जे सुरुवातीपासून शेवटपर्यंत घडते, व्यत्यय किंवा मॅन्युअल हस्तक्षेपाशिवाय. या संदर्भात सीआय आणि सीडी आणि सीडी पाहू.

• सतत एकात्मता ही उत्क्रांतीची सुरुवातीची पायरी आहे. सर्व्हरवर नवीन कोड सबमिट केल्यानंतर, आमचे बदल ठीक आहेत असा त्वरित अभिप्राय मिळण्याची आम्हाला अपेक्षा आहे. सामान्यतः, CI मध्ये स्टॅटिक कोड विश्लेषण साधने आणि युनिट/अंतर्गत API चाचण्यांचा समावेश असतो. हे आम्हाला आमच्या कोडबद्दल काही सेकंद/मिनिटांमध्ये माहिती मिळवू देते.
• सतत वितरण ही एक अधिक प्रगत पायरी आहे जिथे आम्ही एकत्रीकरण/UI चाचण्या चालवतो. तथापि, या टप्प्यावर आम्हाला CI प्रमाणे लवकर परिणाम मिळत नाहीत. प्रथम, या प्रकारच्या चाचण्या पूर्ण होण्यासाठी जास्त वेळ लागतो. दुसरे म्हणजे, लॉन्च करण्यापूर्वी, आम्ही आमचे बदल चाचणी/स्टेजिंग वातावरणात तैनात केले पाहिजेत. शिवाय, जर आपण मोबाईल डेव्हलपमेंटबद्दल बोलत असाल, तर आमच्या ऍप्लिकेशनची बिल्ड तयार करण्यासाठी एक अतिरिक्त पायरी दिसते.
• सतत तैनाती सर्व स्वीकृती चाचण्या मागील टप्प्यात उत्तीर्ण झाल्या असल्यास आम्ही आमचे बदल उत्पादनात आपोआप सोडतो असे गृहीत धरते. या व्यतिरिक्त, रिलीझ स्टेजनंतर, तुम्ही उत्पादनावर धूर चाचण्या चालवणे आणि स्वारस्य मेट्रिक्स गोळा करणे यासारखे विविध टप्पे कॉन्फिगर करू शकता. सतत तैनात करणे केवळ स्वयंचलित चाचण्यांद्वारे चांगल्या कव्हरेजसह शक्य आहे. चाचणीसह कोणतेही मॅन्युअल हस्तक्षेप आवश्यक असल्यास, हे यापुढे नाही सतत (सतत). मग आपण असे म्हणू शकतो की आमची पाइपलाइन केवळ सतत वितरणाच्या सरावाचे पालन करते.

ऑटोमेशन पायाभूत सुविधांसाठी मूल्य

या विभागात, मी हे स्पष्ट केले पाहिजे की जेव्हा आम्ही एंड-टू-एंड UI चाचण्यांबद्दल बोलतो, तेव्हा याचा अर्थ असा होतो की आम्ही आमचे बदल आणि संबंधित सेवा चाचणी वातावरणात तैनात केल्या पाहिजेत. सतत एकत्रीकरण - या कार्यासाठी प्रक्रिया लागू होत नाही आणि आम्ही किमान सतत वितरण पद्धती लागू करण्याची काळजी घेतली पाहिजे. जर आम्ही त्यांना उत्पादनात चालवणार आहोत तर UI चाचण्यांच्या संदर्भात सतत उपयोजन देखील अर्थपूर्ण आहे.

आणि आम्ही आर्किटेक्चर बदलाचे उदाहरण पाहण्यापूर्वी, मला GitLab CI बद्दल काही शब्द सांगायचे आहेत. इतर CI/CD टूल्सच्या विपरीत, GitLab रिमोट रिपॉझिटरी आणि इतर अनेक अतिरिक्त वैशिष्ट्ये प्रदान करते. अशा प्रकारे, GitLab CI पेक्षा जास्त आहे. यामध्ये सोर्स कोड मॅनेजमेंट, एजाइल मॅनेजमेंट, CI/CD पाइपलाइन, लॉगिंग टूल्स आणि मेट्रिक्स कलेक्शन ऑफ द बॉक्स समाविष्ट आहे. GitLab आर्किटेक्चरमध्ये Gitlab CI/CD आणि GitLab रनर यांचा समावेश आहे. अधिकृत वेबसाइटवरून येथे एक लहान वर्णन आहे:

गिटलॅब सीआय/सीडी हे एपीआय असलेले वेब अॅप्लिकेशन आहे जे त्याची स्थिती डेटाबेसमध्ये साठवते, प्रोजेक्ट/बिल्ड व्यवस्थापित करते आणि यूजर इंटरफेस प्रदान करते. गिटलॅब रनर हा एक अॅप्लिकेशन आहे जो बिल्डवर प्रक्रिया करतो. हे स्वतंत्रपणे तैनात केले जाऊ शकते आणि API द्वारे GitLab CI/CD सह कार्य करते. चालू असलेल्या चाचण्यांसाठी तुम्हाला Gitlab इंस्टन्स आणि रनर दोन्ही आवश्यक आहेत.

पायाभूत सुविधांच्या सद्य स्थितीचे चित्रण

एक्सप्लोर करण्यासाठी लिंक्स

• मार्टिन फॉलर: सतत एकत्रीकरण
• GitLab CI/CD
• सतत एकत्रीकरण पुस्तक
• सतत वितरण पुस्तक

तत्सम साधने

• जेनकिन्स
• टीमसिटी
• ट्रॅव्हिस 
• आणि इतर अनेक

5. क्लाउड प्लॅटफॉर्म

तंत्रज्ञानाचे संक्षिप्त वर्णन

या विभागात आपण 'पब्लिक क्लाउड्स' नावाच्या लोकप्रिय ट्रेंडबद्दल बोलू. वर वर्णन केलेले व्हर्च्युअलायझेशन आणि कंटेनरायझेशन तंत्रज्ञान प्रदान करणारे प्रचंड फायदे असूनही, आम्हाला अद्याप संगणकीय संसाधनांची आवश्यकता आहे. कंपन्या महागडे सर्व्हर विकत घेतात किंवा डेटा सेंटर भाड्याने घेतात, परंतु या प्रकरणात आपल्याला किती संसाधने लागतील, आपण त्यांचा 24/7 वापर करू आणि कोणत्या हेतूंसाठी याची गणना करणे आवश्यक आहे (कधीकधी अवास्तव). उदाहरणार्थ, उत्पादनासाठी XNUMX/XNUMX चालणारे सर्व्हर आवश्यक आहे, परंतु आम्हाला कामाच्या वेळेच्या बाहेर चाचणीसाठी समान संसाधनांची आवश्यकता आहे का? ते कोणत्या प्रकारच्या चाचण्या केल्या जात आहे यावर देखील अवलंबून असते. एक उदाहरण म्हणजे लोड/स्ट्रेस चाचण्या ज्या आम्ही कामाच्या नसलेल्या वेळेत चालवण्याचा विचार करतो जेणेकरुन दुसऱ्या दिवशी निकाल मिळू शकतील. परंतु निश्चितपणे XNUMX/XNUMX सर्व्हरची उपलब्धता एंड-टू-एंड स्वयंचलित चाचण्यांसाठी आवश्यक नाही आणि विशेषतः मॅन्युअल चाचणी वातावरणासाठी नाही. अशा परिस्थितींसाठी, मागणीनुसार आवश्यक तितकी संसाधने मिळवणे, त्यांचा वापर करणे आणि यापुढे गरज नसताना पैसे देणे थांबवणे चांगले होईल. शिवाय, काही माऊस क्लिक करून किंवा दोन स्क्रिप्ट चालवून त्यांना त्वरित प्राप्त करणे चांगले होईल. यासाठी सार्वजनिक ढगांचा वापर केला जातो. चला व्याख्या पाहू:

“सार्वजनिक क्लाउडची व्याख्या सार्वजनिक इंटरनेटवर तृतीय-पक्ष प्रदात्यांद्वारे ऑफर केलेल्या संगणकीय सेवा म्हणून केली जाते, ज्यांना ती वापरायची किंवा खरेदी करायची आहे अशा कोणालाही उपलब्ध करून देते. ते विनामूल्य असू शकतात किंवा मागणीनुसार विकले जाऊ शकतात, ज्यामुळे ग्राहकांना ते वापरत असलेल्या CPU सायकल, स्टोरेज किंवा बँडविड्थसाठी फक्त प्रति वापर देय देतात."

एक मत आहे की सार्वजनिक ढग महाग आहेत. परंतु कंपनीचा खर्च कमी करणे ही त्यांची मुख्य कल्पना आहे. आधी सांगितल्याप्रमाणे, सार्वजनिक ढग तुम्हाला मागणीनुसार संसाधने मिळवू देतात आणि तुम्ही ते वापरता त्या वेळेसाठीच पैसे देतात. तसेच, काहीवेळा आपण हे विसरतो की कर्मचार्‍यांना पगार मिळतो आणि विशेषज्ञ देखील एक महाग संसाधन आहेत. हे लक्षात घेतले पाहिजे की सार्वजनिक ढग पायाभूत सुविधांना अधिक सुलभ करतात, ज्यामुळे अभियंते अधिक महत्त्वाच्या कामांवर लक्ष केंद्रित करू शकतात. 

ऑटोमेशन पायाभूत सुविधांसाठी मूल्य

एंड-टू-एंड UI चाचण्यांसाठी आम्हाला कोणत्या विशिष्ट संसाधनांची आवश्यकता आहे? मुळात ही व्हर्च्युअल मशीन्स किंवा क्लस्टर्स आहेत (आम्ही पुढील भागात कुबेरनेट्सबद्दल बोलू) ब्राउझर आणि एमुलेटर चालवण्यासाठी. आपल्याला एकाच वेळी जितके अधिक ब्राउझर आणि एमुलेटर चालवायचे आहेत, तितके जास्त CPU आणि मेमरी आवश्यक आहे आणि त्यासाठी आपल्याला अधिक पैसे द्यावे लागतील. अशाप्रकारे, चाचणी ऑटोमेशनच्या संदर्भात सार्वजनिक ढग आम्हाला मागणीनुसार मोठ्या संख्येने (100, 200, 1000...) ब्राउझर/अनुकरणकर्ते चालविण्यास, शक्य तितक्या लवकर चाचणी निकाल मिळविण्यास आणि अशा अत्यंत संसाधन-केंद्रित गोष्टींसाठी पैसे देणे थांबविण्यास अनुमती देतात. शक्ती 

Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP) हे सर्वात लोकप्रिय क्लाउड प्रदाता आहेत. कसे-करायचे मार्गदर्शक GCP कसे वापरायचे याची उदाहरणे प्रदान करते, परंतु सर्वसाधारणपणे ऑटोमेशन कार्यांसाठी तुम्ही काय वापरता याने काही फरक पडत नाही. ते सर्व अंदाजे समान कार्यक्षमता प्रदान करतात. सामान्यतः, प्रदाता निवडण्यासाठी, व्यवस्थापन कंपनीच्या संपूर्ण पायाभूत सुविधा आणि व्यवसाय आवश्यकतांवर लक्ष केंद्रित करते, जे या लेखाच्या व्याप्तीच्या बाहेर आहे. ऑटोमेशन अभियंत्यांसाठी, क्लाउड प्रदात्यांचा वापर क्लाउड प्लॅटफॉर्मच्या वापराशी तुलना करणे अधिक मनोरंजक असेल, विशेषत: सॉस लॅब्स, ब्राउझरस्टॅक, बिटबार आणि यासारख्या चाचणी उद्देशांसाठी. चला तर मग ते पण करूया! माझ्या मते, सॉस लॅब्स हे सर्वात प्रसिद्ध क्लाउड टेस्टिंग फार्म आहे, म्हणूनच मी ते तुलना करण्यासाठी वापरले. 

ऑटोमेशन हेतूंसाठी GCP वि सॉस लॅब:

चला कल्पना करूया की आपल्याला 8 वेब चाचण्या आणि 8 Android चाचण्या एकाच वेळी चालवण्याची गरज आहे. यासाठी आम्ही GCP वापरू आणि सेलेनोइडसह 2 आभासी मशीन चालवू. प्रथम आम्ही ब्राउझरसह 8 कंटेनर वाढवू. दुस-यावर एमुलेटरसह 8 कंटेनर आहेत. चला किंमतींवर एक नजर टाकूया:  

Chrome सह एक कंटेनर चालविण्यासाठी, आम्हाला आवश्यक आहे n1-मानक-1 गाडी. Android च्या बाबतीत ते असेल n1-मानक-4 एका एमुलेटरसाठी. खरं तर, अधिक लवचिक आणि स्वस्त मार्ग म्हणजे CPU/मेमरी साठी विशिष्ट वापरकर्ता मूल्ये सेट करणे, परंतु या क्षणी सॉस लॅबशी तुलना करण्यासाठी हे महत्त्वाचे नाही.

आणि येथे सॉस लॅब वापरण्यासाठी दर आहेत:

मला विश्वास आहे की तुम्हाला फरक आधीच लक्षात आला आहे, परंतु तरीही मी आमच्या कार्यासाठी गणनेसह एक टेबल प्रदान करेन:

आवश्यक संसाधने
मॉन्टली
कामाचे तास(सकाळी ८ ते रात्री ८)
कामाचे तास+ पूर्वग्रहण करण्यायोग्य

वेबसाठी GCP
n1-मानक-1 x 8 = n1-मानक-8
$194.18
23 दिवस * 12 तास * 0.38 = $104.88 
23 दिवस * 12 तास * 0.08 = $22.08

वेबसाठी सॉस लॅब
व्हर्च्युअल क्लाउड8 समांतर चाचण्या
$1.559
-
-

Android साठी GCP
n1-मानक-4 x 8: n1-मानक-16
$776.72
23 दिवस * 12 तास * 1.52 = $419.52 
23 दिवस * 12 तास * 0.32 = $88.32

Android साठी सॉस लॅब
रिअल डिव्हाइस क्लाउड 8 समांतर चाचण्या
$1.999
-
-

तुम्ही बघू शकता, किमतीतील फरक खूप मोठा आहे, खासकरून जर तुम्ही फक्त बारा तासांच्या कामकाजाच्या कालावधीत चाचण्या चालवत असाल. परंतु तुम्ही प्रीएम्प्टिबल मशीन वापरत असाल तर तुम्ही खर्च आणखी कमी करू शकता. हे काय आहे?

प्रीएम्प्टिबल VM हे एक उदाहरण आहे जे तुम्ही सामान्य उदाहरणांपेक्षा जास्त किंमतीत तयार आणि चालवू शकता. तथापि, इतर कार्यांसाठी त्या संसाधनांमध्ये प्रवेश आवश्यक असल्यास Compute Engine ही उदाहरणे संपुष्टात आणू शकते (प्रीम्प्ट). प्रीम्पेटिबल उदाहरणे जास्तीची कॉम्प्युट इंजिन क्षमता आहेत, त्यामुळे त्यांची उपलब्धता वापरानुसार बदलते.

जर तुमचे अॅप्स दोष-सहिष्णु असतील आणि संभाव्य उदाहरणांच्या पूर्वकल्पना सहन करू शकत असतील, तर प्रीम्पेटिबल उदाहरणे तुमच्या कॉम्प्युट इंजिनच्या खर्चात लक्षणीय घट करू शकतात. उदाहरणार्थ, बॅच प्रोसेसिंग जॉब्स प्रीम्पेटिबल उदाहरणांवर चालू शकतात. यापैकी काही उदाहरणे प्रक्रियेदरम्यान संपुष्टात आल्यास, काम मंद होते परंतु पूर्णपणे थांबत नाही. प्रीम्पेटिबल उदाहरणे तुमच्या विद्यमान उदाहरणांवर अतिरिक्त वर्कलोड न ठेवता आणि अतिरिक्त सामान्य उदाहरणांसाठी तुम्हाला पूर्ण किंमत न भरता तुमची बॅच प्रक्रिया कार्ये पूर्ण करतात.

आणि ते अजूनही संपलेले नाही! प्रत्यक्षात, मला खात्री आहे की ब्रेकशिवाय कोणीही 12 तास चाचणी घेत नाही. आणि तसे असल्यास, आपण व्हर्च्युअल मशीनची आवश्यकता नसताना स्वयंचलितपणे सुरू आणि थांबवू शकता. वास्तविक वापर वेळ दररोज 6 तासांपर्यंत कमी केला जाऊ शकतो. मग आमच्या कार्याच्या संदर्भात पेमेंट 11 ब्राउझरसाठी दरमहा $8 पर्यंत कमी होईल. हे आश्चर्यकारक नाही का? परंतु प्रीम्पेटिबल मशीन्ससह आपण सावध असले पाहिजे आणि व्यत्यय आणि अस्थिरतेसाठी तयार असले पाहिजे, जरी या परिस्थिती सॉफ्टवेअरमध्ये प्रदान केल्या जाऊ शकतात आणि हाताळल्या जाऊ शकतात. ते यथायोग्य किमतीचे आहे!

पण मी 'क्लाउड टेस्ट फार्म कधीही वापरू नका' असे म्हणत नाही. त्यांचे अनेक फायदे आहेत. सर्व प्रथम, हे केवळ एक आभासी मशीन नाही तर बॉक्सच्या बाहेर कार्यक्षमतेच्या संचासह एक पूर्ण चाचणी ऑटोमेशन समाधान आहे: दूरस्थ प्रवेश, लॉग, स्क्रीनशॉट, व्हिडिओ रेकॉर्डिंग, विविध ब्राउझर आणि भौतिक मोबाइल डिव्हाइस. बर्याच परिस्थितींमध्ये, हा एक अत्यावश्यक डोळ्यात भरणारा पर्याय असू शकतो. चाचणी प्लॅटफॉर्म विशेषतः IOS ऑटोमेशनसाठी उपयुक्त आहेत, जेव्हा सार्वजनिक क्लाउड फक्त Linux/Windows सिस्टम देऊ शकतात. परंतु आम्ही पुढील लेखांमध्ये iOS बद्दल बोलू. मी नेहमी परिस्थितीकडे पाहण्याची आणि कार्यांपासून प्रारंभ करण्याची शिफारस करतो: काही प्रकरणांमध्ये सार्वजनिक ढग वापरणे स्वस्त आणि अधिक कार्यक्षम आहे आणि इतरांमध्ये चाचणी प्लॅटफॉर्म निश्चितपणे खर्च केलेल्या पैशाची किंमत आहे.

पायाभूत सुविधांच्या सद्य स्थितीचे चित्रण

एक्सप्लोर करण्यासाठी लिंक्स

• जीसीपी
• GCP: प्रीम्पेटिबल
• GCP: VM किंमत
• सॉसलॅब्स
• मेघ प्रदात्यांशी तुलना करणे

तत्सम साधने:

• ऑव्हज 
• अस्मानी

6. वाद्यवृंद

तंत्रज्ञानाचे संक्षिप्त वर्णन

माझ्याकडे चांगली बातमी आहे - आम्ही जवळजवळ लेखाच्या शेवटी आहोत! याक्षणी, आमच्या ऑटोमेशन इन्फ्रास्ट्रक्चरमध्ये वेब आणि Android चाचण्या आहेत, ज्या आम्ही Docker-सक्षम साधने वापरून GitLab CI द्वारे समांतर चालवतो: Selenium grid आणि Selenoid. शिवाय, आम्ही ब्राउझर आणि एमुलेटरसह कंटेनर होस्ट करण्यासाठी GCP द्वारे तयार केलेली आभासी मशीन वापरतो. खर्च कमी करण्यासाठी, आम्ही ही व्हर्च्युअल मशीन केवळ मागणीनुसार सुरू करतो आणि चाचणी केली जात नसताना ती थांबवतो. आमच्या पायाभूत सुविधांमध्ये आणखी काही सुधारणा होऊ शकते का? उत्तर होय आहे! Kubernetes (K8s) ला भेटा!

प्रथम, ऑर्केस्ट्रेशन, क्लस्टर आणि कुबर्नेट्स हे शब्द एकमेकांशी कसे संबंधित आहेत ते पाहू. उच्च स्तरावर, ऑर्केस्ट्रेशन ही प्रणाली आहे जी अनुप्रयोग तैनात आणि व्यवस्थापित करते. चाचणी ऑटोमेशनसाठी, सेलेनियम ग्रिड आणि सेलेनोइड असे कंटेनरीकृत अनुप्रयोग आहेत. डॉकर आणि K8 एकमेकांना पूरक आहेत. पहिला ऍप्लिकेशन डिप्लॉयमेंटसाठी, दुसरा ऑर्केस्ट्रेशनसाठी वापरला जातो. या बदल्यात, K8s एक क्लस्टर आहे. क्लस्टरचे कार्य नोड्स म्हणून व्हीएम वापरणे आहे, जे तुम्हाला एका सर्व्हरमध्ये (क्लस्टर) विविध कार्यक्षमता, प्रोग्राम आणि सेवा स्थापित करण्यास अनुमती देते. कोणतेही नोड्स अयशस्वी झाल्यास, इतर नोड्स उचलले जातील, जे आमच्या अर्जाच्या अखंडित ऑपरेशनची खात्री देतात. या व्यतिरिक्त, K8s मध्ये स्केलिंगशी संबंधित महत्त्वपूर्ण कार्यक्षमता आहे, ज्यामुळे आम्ही लोड आणि सेट मर्यादांवर आधारित इष्टतम संसाधने स्वयंचलितपणे प्राप्त करतो.

खरं तर, कुबर्नेट्स स्क्रॅचमधून मॅन्युअली तैनात करणे हे अजिबात क्षुल्लक काम नाही. मी "कुबर्नेट्स द हार्ड वे" या प्रसिद्ध मार्गदर्शिकेची लिंक देईन आणि तुम्हाला स्वारस्य असल्यास, तुम्ही त्याचा सराव करू शकता. परंतु, सुदैवाने, पर्यायी पद्धती आणि साधने आहेत. GCP मध्ये Google Kubernetes Engine (GKE) वापरणे हा सर्वात सोपा मार्ग आहे, ज्यामुळे तुम्हाला काही क्लिक्समध्ये तयार क्लस्टर मिळू शकेल. मी शिकणे सुरू करण्यासाठी हा दृष्टीकोन वापरण्याची शिफारस करतो, कारण हे तुम्हाला अंतर्गत घटक एकमेकांशी कसे समाकलित केले जावे हे शिकण्याऐवजी तुमच्या कार्यांसाठी K8 कसे वापरायचे हे शिकण्यावर लक्ष केंद्रित करण्यास अनुमती देईल. 

ऑटोमेशन पायाभूत सुविधांसाठी मूल्य

चला K8s प्रदान केलेल्या काही महत्त्वपूर्ण वैशिष्ट्यांवर एक नजर टाकूया:

• अनुप्रयोग उपयोजन: VMs ऐवजी मल्टी-नोड क्लस्टर वापरणे;
• डायनॅमिक स्केलिंग: केवळ मागणीनुसार वापरल्या जाणार्‍या संसाधनांची किंमत कमी करते;
• स्वयं-उपचार: शेंगांची स्वयंचलित पुनर्प्राप्ती (ज्याचा परिणाम म्हणून कंटेनर देखील पुनर्संचयित केले जातात);
• डाउनटाइमशिवाय अपडेट्स आणि रोलबॅकचे रोलआउट: टूल्स, ब्राउझर आणि एमुलेटर अद्यतनित केल्याने सध्याच्या वापरकर्त्यांच्या कामात व्यत्यय येत नाही

पण K8s अजूनही चांदीची बुलेट नाही. आम्ही विचार करत असलेल्या साधनांच्या संदर्भात सर्व फायदे आणि मर्यादा समजून घेण्यासाठी (सेलेनियम ग्रिड, सेलेनोइड), आम्ही K8 च्या संरचनेची थोडक्यात चर्चा करू. क्लस्टरमध्ये दोन प्रकारचे नोड असतात: मास्टर नोड्स आणि वर्कर्स नोड्स. मास्टर नोड्स व्यवस्थापन, उपयोजन आणि शेड्यूलिंग निर्णयांसाठी जबाबदार असतात. वर्कर्स नोड्स जिथे अर्ज चालवले जातात. नोड्समध्ये कंटेनर रनटाइम वातावरण देखील असते. आमच्या बाबतीत, हे डॉकर आहे, जे कंटेनर-संबंधित ऑपरेशन्ससाठी जबाबदार आहे. परंतु पर्यायी उपाय देखील आहेत, उदाहरणार्थ कंटेनर. हे समजून घेणे महत्त्वाचे आहे की स्केलिंग किंवा स्वयं-उपचार थेट कंटेनरवर लागू होत नाहीत. हे पॉड्सची संख्या जोडून/कमी करून अंमलात आणले जाते, ज्यामध्ये कंटेनर असतात (सामान्यत: प्रति पॉड एक कंटेनर, परंतु कार्यावर अवलंबून आणखी असू शकतात). उच्च-स्तरीय पदानुक्रमामध्ये कामगार नोड्स असतात, ज्याच्या आत शेंगा असतात, ज्याच्या आत कंटेनर उभे असतात.

स्केलिंग वैशिष्ट्य महत्त्वाचे आहे आणि क्लस्टर नोड-पूलमधील दोन्ही नोड्स आणि नोडमधील पॉड्सवर लागू केले जाऊ शकते. दोन प्रकारचे स्केलिंग आहेत जे दोन्ही नोड्स आणि पॉड्सवर लागू होतात. पहिला प्रकार क्षैतिज आहे - नोड्स/पॉड्सची संख्या वाढवून स्केलिंग होते. हा प्रकार अधिक श्रेयस्कर आहे. दुसरा प्रकार, त्यानुसार, अनुलंब आहे. स्केलिंग नोड्स/पॉड्सचा आकार वाढवून केले जाते, त्यांची संख्या नव्हे.

आता वरील संज्ञांच्या संदर्भात आपली साधने पाहू.

सेलेनियम ग्रिड

आधी सांगितल्याप्रमाणे, सेलेनियम ग्रिड हे एक अतिशय लोकप्रिय साधन आहे, आणि ते कंटेनरीकृत केले गेले आहे हे आश्चर्यकारक नाही. म्हणून, K8s मध्ये सेलेनियम ग्रिड तैनात केले जाऊ शकते हे आश्चर्यकारक नाही. हे कसे करायचे याचे उदाहरण अधिकृत K8s रेपॉजिटरीमध्ये आढळू शकते. नेहमीप्रमाणे, मी विभागाच्या शेवटी दुवे जोडतो. याशिवाय, टेराफॉर्ममध्ये हे कसे करायचे ते मार्गदर्शिका दाखवते. ब्राउझर कंटेनर असलेल्या पॉड्सची संख्या कशी मोजावी याबद्दल देखील सूचना आहेत. परंतु K8s च्या संदर्भात स्वयंचलित स्केलिंग कार्य अद्याप पूर्णपणे स्पष्ट कार्य नाही. जेव्हा मी अभ्यास सुरू केला तेव्हा मला कोणतेही व्यावहारिक मार्गदर्शन किंवा शिफारसी आढळल्या नाहीत. DevOps टीमच्या समर्थनासह अनेक अभ्यास आणि प्रयोगांनंतर, आम्ही एका पॉडमध्ये आवश्यक ब्राउझरसह कंटेनर वाढवण्याचा दृष्टिकोन निवडला, जो एका वर्कर नोडमध्ये स्थित आहे. ही पद्धत आम्हाला नोड्सची संख्या वाढवून क्षैतिज स्केलिंगची रणनीती लागू करण्यास अनुमती देते. मला आशा आहे की हे भविष्यात बदलेल आणि आम्ही अधिकाधिक चांगल्या पध्दतींचे आणि तयार-तयार उपायांचे वर्णन पाहू, विशेषत: बदललेल्या अंतर्गत आर्किटेक्चरसह सेलेनियम ग्रिड 4 च्या प्रकाशनानंतर.

सेलेनोइड:

K8s मध्ये सेलेनोइड तैनात करणे सध्या सर्वात मोठी निराशा आहे. ते सुसंगत नाहीत. सिद्धांततः, आम्ही पॉडमध्ये सेलेनोइड कंटेनर वाढवू शकतो, परंतु जेव्हा सेलेनोइड ब्राउझरसह कंटेनर लाँच करण्यास प्रारंभ करते तेव्हा ते त्याच पॉडमध्ये असतील. यामुळे स्केलिंग अशक्य होते आणि परिणामी, क्लस्टरमधील सेलेनोइडचे कार्य आभासी मशीनमधील कामापेक्षा वेगळे नसते. कथेचा शेवट.

चंद्र:

सेलेनोइडसह काम करताना ही अडचण ओळखून, विकसकांनी मून नावाचे अधिक शक्तिशाली साधन जारी केले. हे साधन मूलतः कुबर्नेट्ससह कार्य करण्यासाठी डिझाइन केले होते आणि परिणामी, ऑटोस्केलिंग वैशिष्ट्य वापरले जाऊ शकते आणि केले पाहिजे. शिवाय, मी असे म्हणेन की सध्या ते आहे फक्त सेलेनियम जगातील एक साधन, ज्यामध्ये बॉक्सच्या बाहेर नेटिव्ह K8s क्लस्टर सपोर्ट आहे (यापुढे उपलब्ध नाही, पुढील साधन पहा ). हे समर्थन प्रदान करणारी चंद्राची प्रमुख वैशिष्ट्ये आहेत: 

पूर्णपणे राज्यविरहित. सेलेनोइड सध्या चालू असलेल्या ब्राउझर सत्रांबद्दल मेमरी माहिती संग्रहित करते. काही कारणास्तव त्याची प्रक्रिया क्रॅश झाल्यास — सर्व चालू सत्रे गमावली जातात. याउलट चंद्राची कोणतीही अंतर्गत स्थिती नाही आणि डेटा केंद्रांवर त्याची प्रतिकृती केली जाऊ शकते. जरी एक किंवा अधिक प्रतिकृती कमी झाल्या तरीही ब्राउझर सत्रे जिवंत राहतात.

तर, चंद्र हा एक उत्तम उपाय आहे, परंतु एक समस्या आहे: ती विनामूल्य नाही. किंमत सत्रांच्या संख्येवर अवलंबून असते. तुम्ही फक्त 0-4 सत्रे विनामूल्य चालवू शकता, जे विशेषतः उपयुक्त नाही. परंतु, पाचव्या सत्रापासून, तुम्हाला प्रत्येकासाठी $5 भरावे लागतील. परिस्थिती कंपनीनुसार भिन्न असू शकते, परंतु आमच्या बाबतीत, चंद्र वापरणे निरर्थक आहे. मी वर वर्णन केल्याप्रमाणे, आम्ही मागणीनुसार सेलेनियम ग्रिडसह व्हीएम चालवू शकतो किंवा क्लस्टरमधील नोड्सची संख्या वाढवू शकतो. अंदाजे एका पाइपलाइनसाठी, आम्ही 500 ब्राउझर लाँच करतो आणि चाचण्या पूर्ण झाल्यानंतर सर्व संसाधने थांबवतो. आम्ही चंद्राचा वापर केल्यास, आम्हाला दरमहा अतिरिक्त 500 x 5 = $2500 द्यावे लागतील, आम्ही कितीही वेळा चाचण्या घेतल्या तरी. पुन्हा, मी असे म्हणत नाही की चंद्र वापरू नका. तुमच्या कार्यांसाठी, हा एक अपरिहार्य उपाय असू शकतो, उदाहरणार्थ, तुमच्याकडे तुमच्या संस्थेमध्ये अनेक प्रकल्प/संघ असल्यास आणि तुम्हाला प्रत्येकासाठी एक प्रचंड सामान्य क्लस्टर आवश्यक आहे. नेहमीप्रमाणे, मी शेवटी एक दुवा सोडतो आणि तुमच्या कार्याच्या संदर्भात सर्व आवश्यक गणना करण्याची शिफारस करतो.

कॅलिस्टो(लक्ष द्या! हे मूळ लेखात नाही आणि फक्त रशियन भाषांतरात आहे)

मी म्हटल्याप्रमाणे, सेलेनियम हे एक अतिशय लोकप्रिय साधन आहे आणि आयटी क्षेत्र खूप वेगाने विकसित होत आहे. मी भाषांतरावर काम करत असताना, वेबवर कॅलिस्टो नावाचे एक नवीन आश्वासक साधन दिसले (हॅलो सायप्रेस आणि इतर सेलेनियम किलर). हे K8s सह नेटिव्हरित्या कार्य करते आणि तुम्हाला सेलेनोइड कंटेनर पॉड्समध्ये चालवण्याची परवानगी देते, नोड्समध्ये वितरीत केले जाते. ऑटोस्केलिंगसह सर्व काही अगदी बॉक्सच्या बाहेर कार्य करते. विलक्षण, परंतु चाचणी करणे आवश्यक आहे. मी आधीच हे साधन उपयोजित करण्यात आणि अनेक प्रयोग चालविण्यात व्यवस्थापित केले आहे. परंतु निष्कर्ष काढणे खूप लवकर आहे, बर्याच अंतरावर परिणाम प्राप्त केल्यानंतर, कदाचित मी भविष्यातील लेखांमध्ये पुनरावलोकन करेन. सध्या मी स्वतंत्र संशोधनासाठी फक्त लिंक्स सोडत आहे.  

पायाभूत सुविधांच्या सद्य स्थितीचे चित्रण

एक्सप्लोर करण्यासाठी लिंक्स

• कुबर्नेट्स: सेटअप
• कुबर्नेट्स: कठीण मार्ग
• कुबर्नेट्स: सेलेनियम
• GCP: कुबर्नेट्स इंजिन
• चंद्र
• कुबर्नेट्स बुक
• Kubernetes वापरून वितरित ऑटोमेशन
• सेलेनियम ग्रिड 4
• कॅलिस्टो गिटहब
• Wrike TechClub (कॅलिस्टो)

तत्सम साधने

• डॉकरचा थवा 
• मॅरेथॉन 

7. कोड (IaC) म्हणून पायाभूत सुविधा

तंत्रज्ञानाचे संक्षिप्त वर्णन

आणि आता आपण शेवटच्या विभागात येतो. सामान्यतः, हे तंत्रज्ञान आणि संबंधित कार्ये ऑटोमेशन अभियंत्यांची जबाबदारी नाही. आणि याची कारणे आहेत. प्रथमतः, अनेक संस्थांमध्ये, पायाभूत सुविधांच्या समस्या DevOps विभागाच्या नियंत्रणाखाली आहेत आणि विकास कार्यसंघ खरोखरच पाइपलाइन कशामुळे कार्य करते आणि त्याच्याशी जोडलेल्या प्रत्येक गोष्टीला समर्थन देणे आवश्यक आहे याकडे खरोखर लक्ष देत नाहीत. दुसरे म्हणजे, प्रामाणिकपणे सांगायचे तर, इन्फ्रास्ट्रक्चर अॅज कोड (IaC) ची प्रथा अजूनही अनेक कंपन्यांमध्ये अवलंबलेली नाही. परंतु तो निश्चितपणे एक लोकप्रिय ट्रेंड बनला आहे आणि त्याच्याशी संबंधित प्रक्रिया, दृष्टिकोन आणि साधनांमध्ये सहभागी होण्याचा प्रयत्न करणे महत्त्वाचे आहे. किंवा किमान अद्ययावत रहा.

चला हा दृष्टिकोन वापरण्याच्या प्रेरणेने सुरुवात करूया. आम्ही आधीच चर्चा केली आहे की GitlabCI मध्ये चाचण्या चालवण्यासाठी, आम्हाला Gitlab रनर चालवण्यासाठी कमीतकमी संसाधनांची आवश्यकता असेल. आणि ब्राउझर/एमुलेटरसह कंटेनर चालवण्यासाठी, आम्हाला VM किंवा क्लस्टर आरक्षित करणे आवश्यक आहे. संसाधने तपासण्याव्यतिरिक्त, आम्हाला विकास, स्टेजिंग, उत्पादन वातावरणास समर्थन देण्यासाठी मोठ्या प्रमाणात क्षमतेची आवश्यकता आहे, ज्यामध्ये डेटाबेस, स्वयंचलित वेळापत्रक, नेटवर्क कॉन्फिगरेशन, लोड बॅलन्सर्स, वापरकर्ता अधिकार इत्यादींचा समावेश आहे. या सर्वांचे समर्थन करण्यासाठी आवश्यक असलेल्या प्रयत्नांचा मुख्य मुद्दा आहे. आम्ही बदल करू शकतो आणि अपडेट रोल आउट करू शकतो असे अनेक मार्ग आहेत. उदाहरणार्थ, GCP च्या संदर्भात, आम्ही ब्राउझरमध्ये UI कन्सोल वापरू शकतो आणि बटणावर क्लिक करून सर्व क्रिया करू शकतो. क्लाउड घटकांशी संवाद साधण्यासाठी API कॉल वापरणे किंवा इच्छित हाताळणी करण्यासाठी gcloud कमांड लाइन युटिलिटी वापरणे हा एक पर्याय आहे. परंतु खरोखरच मोठ्या संख्येने विविध घटक आणि पायाभूत घटकांसह, सर्व ऑपरेशन्स व्यक्तिचलितपणे करणे कठीण किंवा अगदी अशक्य होते. शिवाय, या सर्व मॅन्युअल क्रिया अनियंत्रित आहेत. आम्ही त्यांना अंमलबजावणीपूर्वी पुनरावलोकनासाठी सबमिट करू शकत नाही, आवृत्ती नियंत्रण प्रणाली वापरू शकत नाही आणि घटना घडवून आणणारे बदल त्वरीत परत करू शकत नाही. अशा समस्यांचे निराकरण करण्यासाठी, अभियंत्यांनी स्वयंचलित बॅश/शेल स्क्रिप्ट तयार केल्या आणि तयार केल्या, ज्या मागील पद्धतींपेक्षा जास्त चांगल्या नाहीत, कारण ते प्रक्रियात्मक शैलीमध्ये द्रुतपणे वाचणे, समजणे, देखरेख करणे आणि सुधारणे इतके सोपे नाही.

या लेखात आणि कसे मार्गदर्शन करावे, मी IaC सरावाशी संबंधित 2 साधने वापरतो. हे टेराफॉर्म आणि उत्तरदायी आहेत. काही लोकांचा असा विश्वास आहे की ते एकाच वेळी वापरण्यात काही अर्थ नाही, कारण त्यांची कार्यक्षमता सारखीच आहे आणि ते अदलाबदल करण्यायोग्य आहेत. परंतु वस्तुस्थिती अशी आहे की सुरुवातीला त्यांना पूर्णपणे भिन्न कार्ये दिली जातात. आणि ही साधने एकमेकांना पूरक असली पाहिजेत या वस्तुस्थितीची पुष्टी HashiCorp आणि RedHat चे प्रतिनिधित्व करणाऱ्या डेव्हलपर्सनी संयुक्त सादरीकरणात केली होती. वैचारिक फरक असा आहे की टेराफॉर्म हे सर्व्हर स्वतः व्यवस्थापित करण्यासाठी एक तरतूद साधन आहे. Ansible हे एक कॉन्फिगरेशन व्यवस्थापन साधन आहे ज्याचे कार्य या सर्व्हरवर सॉफ्टवेअर स्थापित करणे, कॉन्फिगर करणे आणि व्यवस्थापित करणे आहे.

या साधनांचे आणखी एक प्रमुख वेगळे वैशिष्ट्य म्हणजे कोडिंग शैली. बॅश आणि अॅन्सिबलच्या विपरीत, टेराफॉर्म अंमलबजावणीच्या परिणामी प्राप्त होणाऱ्या इच्छित अंतिम स्थितीच्या वर्णनावर आधारित घोषणात्मक शैली वापरते. उदाहरणार्थ, जर आपण 10 VM तयार करणार आहोत आणि बदल Terraform द्वारे लागू करणार आहोत, तर आपल्याला 10 VM मिळतील. आम्ही स्क्रिप्ट पुन्हा चालवल्यास, आमच्याकडे आधीपासूनच 10 VM असल्याने काहीही होणार नाही आणि टेराफॉर्मला याबद्दल माहिती आहे कारण ते राज्य फाइलमध्ये पायाभूत सुविधांची सद्य स्थिती संग्रहित करते. पण Ansible एक प्रक्रियात्मक दृष्टीकोन वापरते आणि, जर तुम्ही 10 VM तयार करण्यास सांगितले, तर पहिल्या लॉन्चवर आम्हाला टेराफॉर्म प्रमाणेच 10 VM मिळतील. परंतु रीस्टार्ट केल्यानंतर आमच्याकडे आधीपासूनच 20 VM असतील. हा महत्त्वाचा फरक आहे. प्रक्रियात्मक शैलीमध्ये, आम्ही सद्य स्थिती संचयित करत नाही आणि फक्त केलेल्या चरणांच्या क्रमाचे वर्णन करतो. अर्थात, आपण विविध परिस्थिती हाताळू शकतो, संसाधनांच्या अस्तित्वासाठी आणि सद्य स्थितीसाठी अनेक तपासण्या जोडू शकतो, परंतु आपला वेळ वाया घालवण्यात आणि या तर्कावर नियंत्रण ठेवण्यासाठी प्रयत्न करण्यात काहीच अर्थ नाही. याव्यतिरिक्त, यामुळे चुका होण्याचा धोका वाढतो. 

वरील सर्व गोष्टींचा सारांश देऊन, आम्ही असा निष्कर्ष काढू शकतो की सर्व्हरची तरतूद करण्यासाठी टेराफॉर्म आणि घोषणात्मक नोटेशन हे अधिक योग्य साधन आहे. परंतु कॉन्फिगरेशन व्यवस्थापनाचे काम उत्तरदायीकडे सोपविणे चांगले आहे. तसे न करता, ऑटोमेशनच्या संदर्भात वापर प्रकरणे पाहू.

ऑटोमेशन पायाभूत सुविधांसाठी मूल्य

येथे समजून घेण्याची एकच महत्त्वाची गोष्ट म्हणजे चाचणी ऑटोमेशन पायाभूत सुविधा संपूर्ण कंपनीच्या पायाभूत सुविधांचा भाग मानली जावी. याचा अर्थ सर्व IaC पद्धती संपूर्ण संस्थेच्या संसाधनांवर जागतिक स्तरावर लागू केल्या पाहिजेत. यासाठी कोण जबाबदार आहे हे तुमच्या प्रक्रियेवर अवलंबून आहे. DevOps टीम या समस्यांमध्ये अधिक अनुभवी आहे, ते काय घडत आहे याचे संपूर्ण चित्र पाहतात. तथापि, QA अभियंते ऑटोमेशन आणि पाइपलाइनच्या संरचनेच्या प्रक्रियेत अधिक गुंतलेले असतात, जे त्यांना सर्व आवश्यक बदल आणि सुधारणेच्या संधी अधिक चांगल्या प्रकारे पाहण्याची परवानगी देतात. अपेक्षित परिणाम साध्य करण्यासाठी एकत्र काम करणे, ज्ञान आणि कल्पनांची देवाणघेवाण करणे हा सर्वोत्तम पर्याय आहे. 

चाचणी ऑटोमेशन आणि आम्ही आधी चर्चा केलेल्या साधनांच्या संदर्भात टेराफॉर्म आणि उत्तरदायी वापरण्याची काही उदाहरणे येथे आहेत:

1. टेराफॉर्म वापरून VM आणि क्लस्टर्सची आवश्यक वैशिष्ट्ये आणि पॅरामीटर्सचे वर्णन करा.

2. Ansible वापरून, चाचणीसाठी आवश्यक साधने स्थापित करा: डॉकर, सेलेनोइड, सेलेनियम ग्रिड आणि ब्राउझर/इम्युलेटरच्या आवश्यक आवृत्त्या डाउनलोड करा.

3. टेराफॉर्म वापरून, VM च्या वैशिष्ट्यांचे वर्णन करा ज्यामध्ये GitLab रनर लाँच केले जाईल.

4. Ansible, सेट सेटिंग्ज आणि कॉन्फिगरेशन वापरून GitLab रनर आणि आवश्यक सोबतची साधने स्थापित करा.

पायाभूत सुविधांच्या सद्य स्थितीचे चित्रण

एक्सप्लोर करण्यासाठी लिंक्स:

• टेराफॉर्म
• उत्तर द्या
• उत्तरदायी आणि टेराफॉर्म एकत्र चांगले
• टेराफॉर्मसाठी सर्वसमावेशक मार्गदर्शक
• आम्ही टेराफॉर्म का वापरतो आणि शेफ, पपेट, अॅन्सिबल, सॉल्टस्टॅक किंवा क्लाउडफॉर्मेशन का वापरतो
• GCP: IaC

तत्सम साधने

• डोके
• कठपुतळी
• सॉल्टस्टॅक
• भटक्या

चला बेरीज करूया!

पाऊल
तंत्रज्ञान
साधने
ऑटोमेशन पायाभूत सुविधांसाठी मूल्य

1
लोकल चालू आहे
Node.js, Selenium, Appium

• वेब आणि मोबाइलसाठी सर्वात लोकप्रिय साधने
• अनेक भाषा आणि प्लॅटफॉर्मचे समर्थन करते (Node.js सह)

2
आवृत्ती नियंत्रण प्रणाली 
Git

• विकास कोडसह समान फायदे

3
कंटेनरायझेशन
डॉकर, सेलेनियम ग्रिड, सेलेनोइड (वेब, अँड्रॉइड)

• समांतर चाचण्या चालवणे
• अलिप्त वातावरण
• साधी, लवचिक आवृत्ती अपग्रेड
• गतिमानपणे न वापरलेली संसाधने थांबवणे
• सेट करणे सोपे आहे

4
CI/CD
Gitlab CI

• पाइपलाइनचा भाग तपासतो
• Ыстрая связь
• संपूर्ण कंपनी/संघासाठी दृश्यमानता

5
मेघ प्लॅटफॉर्म
Google Cloud Platform

• मागणीनुसार संसाधने (आम्ही गरज असेल तेव्हाच पैसे देतो)
• व्यवस्थापित करणे आणि अद्यतनित करणे सोपे आहे
• सर्व संसाधनांची दृश्यमानता आणि नियंत्रण

6
ऑर्केस्ट्रेशन
कुबेरनेट्स
पॉड्सच्या आत ब्राउझर/एमुलेटर असलेल्या कंटेनरच्या संदर्भात:

• स्केलिंग/ऑटो स्केलिंग
• स्व-उपचार
• कोणत्याही व्यत्ययाशिवाय अद्यतने आणि रोलबॅक

7
कोड म्हणून पायाभूत सुविधा (IaC)
टेराफॉर्म, उत्तरदायी

• विकासाच्या पायाभूत सुविधांसह समान फायदे
• कोड आवृत्तीचे सर्व फायदे
• बदल करणे आणि देखभाल करणे सोपे आहे
• पूर्णपणे स्वयंचलित

मन नकाशा आकृती: पायाभूत सुविधांची उत्क्रांती

पायरी 1: स्थानिक

पायरी 2: VCS

पायरी 3: कंटेनरायझेशन 

पायरी 4: CI/CD 

पायरी 5: क्लाउड प्लॅटफॉर्म

पायरी 6:ऑर्केस्ट्रेशन

पायरी 7: IaC

पुढील काय आहे?

तर, हा लेखाचा शेवट आहे. पण शेवटी, मी तुमच्याशी काही करार प्रस्थापित करू इच्छितो.

तुझ्या बाजूने
सुरुवातीला म्हटल्याप्रमाणे, लेखाचा व्यावहारिक उपयोग व्हावा आणि मिळालेले ज्ञान प्रत्यक्ष कामात लागू करण्यात मदत व्हावी असे मला वाटते. मी पुन्हा जोडतो व्यावहारिक मार्गदर्शकाची लिंक.

परंतु त्यानंतरही, थांबू नका, सराव करा, संबंधित लिंक्स आणि पुस्तकांचा अभ्यास करा, ते तुमच्या कंपनीमध्ये कसे कार्य करते ते शोधा, सुधारता येईल अशी ठिकाणे शोधा आणि त्यात भाग घ्या. शुभेच्छा!

माझ्याकडून

शीर्षकावरून तुम्ही पाहू शकता की हा फक्त पहिला भाग होता. ते बरेच मोठे असल्याचे असूनही, महत्त्वाचे विषय अद्याप येथे समाविष्ट केलेले नाहीत. दुसऱ्या भागात, IOS च्या संदर्भात ऑटोमेशन इन्फ्रास्ट्रक्चर पाहण्याची माझी योजना आहे. केवळ macOS सिस्टीमवर iOS सिम्युलेटर चालवण्यावर Apple च्या निर्बंधांमुळे, आमच्या उपायांची श्रेणी कमी झाली आहे. उदाहरणार्थ, आम्ही सिम्युलेटर चालविण्यासाठी डॉकर किंवा व्हर्च्युअल मशीन चालविण्यासाठी सार्वजनिक क्लाउड वापरण्यास अक्षम आहोत. परंतु याचा अर्थ असा नाही की इतर कोणतेही पर्याय नाहीत. मी तुम्हाला प्रगत उपाय आणि आधुनिक साधनांसह अद्ययावत ठेवण्याचा प्रयत्न करेन!

तसेच, मी निरीक्षणाशी संबंधित मोठ्या विषयांचा उल्लेख केलेला नाही. भाग 3 मध्ये, मी सर्वात लोकप्रिय इन्फ्रास्ट्रक्चर मॉनिटरिंग टूल्स आणि कोणते डेटा आणि मेट्रिक्स विचारात घ्यायचे ते पाहणार आहे.

आणि शेवटी. भविष्यात, मी चाचणी पायाभूत सुविधा आणि लोकप्रिय साधने तयार करण्यासाठी व्हिडिओ कोर्स जारी करण्याची योजना आखत आहे. सध्या, इंटरनेटवर DevOps वर बरेच अभ्यासक्रम आणि व्याख्याने आहेत, परंतु सर्व साहित्य विकासाच्या संदर्भात सादर केले जाते, चाचणी ऑटोमेशन नाही. या मुद्द्यावर, असा कोर्स परीक्षक आणि ऑटोमेशन अभियंत्यांच्या समुदायासाठी मनोरंजक आणि मौल्यवान असेल की नाही याबद्दल मला खरोखर अभिप्राय हवा आहे. आगाऊ धन्यवाद!

स्त्रोत: www.habr.com