भाग १: वेब/एन्ड्रोइड

भन्नु: यो लेख मूल लेखको रूसीमा अनुवाद हो "DevOps उपकरणहरू DevOps को लागि मात्र होइनन्। "स्क्र्याचबाट निर्माण परीक्षण स्वचालन पूर्वाधार।" यद्यपि, सबै दृष्टान्तहरू, लिङ्कहरू, उद्धरणहरू र सर्तहरू मूल भाषामा संरक्षित छन् जब रूसीमा अनुवाद गर्दा अर्थको विकृतिबाट बच्न। म तिमीलाई खुशी अध्ययन गर्न चाहन्छु!

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

मेरो विशेषज्ञता एक परीक्षण स्वचालन ईन्जिनियर (QA स्वचालन ईन्जिनियर) हो, तर म विश्वास गर्छु कि यो केवल लेखन स्वतः-परीक्षण वा विकास परीक्षण फ्रेमवर्क वास्तुकला संग सम्बन्धित हुनु हुँदैन। २०२० मा, स्वचालन पूर्वाधारको ज्ञान पनि आवश्यक छ। यसले तपाइँलाई तपाइँको लक्ष्य अनुसार सबै सरोकारवालाहरूलाई नतिजाहरू उपलब्ध गराउन परीक्षणहरू चलाउनेदेखि लिएर स्वचालन प्रक्रिया आफैलाई व्यवस्थित गर्न अनुमति दिन्छ। नतिजाको रूपमा, DevOps सीपहरू काम गर्न आवश्यक छ। र यो सबै राम्रो छ, तर, दुर्भाग्यवश, त्यहाँ एक समस्या छ (स्पोइलर: यस लेखले यो समस्यालाई सरल बनाउने प्रयास गर्दछ)। बिन्दु यो हो कि 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
क्लाउड प्लेटफार्महरू
गुगल क्लाउड प्लेटफार्म

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

7
कोडको रूपमा पूर्वाधार (IaC)
Terraform, उत्तरदायी

प्रत्येक खण्डको संरचना

कथा स्पष्ट राख्न, प्रत्येक खण्डलाई निम्न रूपरेखा अनुसार वर्णन गरिएको छ:

• प्रविधिको संक्षिप्त विवरण,
• स्वचालन पूर्वाधारको लागि मूल्य,
• पूर्वाधारको वर्तमान अवस्थाको चित्रण,
• अध्ययन को लिङ्क,
• समान उपकरणहरू।

1. स्थानीय रूपमा परीक्षणहरू चलाउनुहोस्

प्रविधिको संक्षिप्त विवरण

यो स्थानीय रूपमा डेमो परीक्षणहरू चलाउन र तिनीहरू उत्तीर्ण भएको प्रमाणित गर्नको लागि एक तयारी चरण मात्र हो। व्यावहारिक भागमा, Node.js प्रयोग गरिन्छ, तर प्रोग्रामिङ भाषा र प्लेटफर्म पनि महत्त्वपूर्ण छैन र तपाइँ तपाइँको कम्पनीमा प्रयोग गरिएका ती प्रयोग गर्न सक्नुहुन्छ। 

जे होस्, स्वचालन उपकरणहरूको रूपमा, म वेब प्लेटफर्महरूको लागि सेलेनियम वेबड्राइभर र एन्ड्रोइड प्लेटफर्मको लागि एपियम क्रमशः प्रयोग गर्न सिफारिस गर्दछु, किनकि अर्को चरणहरूमा हामी यी उपकरणहरूसँग विशेष रूपमा काम गर्नको लागि अनुकूल डकर छविहरू प्रयोग गर्नेछौं। यसबाहेक, रोजगार आवश्यकताहरू सन्दर्भ गर्दै, यी उपकरणहरू बजारमा सबैभन्दा बढी माग छन्।

तपाईंले याद गर्नुभएको हुनसक्छ, हामी वेब र एन्ड्रोइड परीक्षणहरू मात्र विचार गर्छौं। दुर्भाग्यवश, आईओएस एक पूर्ण फरक कथा हो (धन्यवाद एप्पल)। म आगामी भागहरूमा IOS सम्बन्धित समाधान र अभ्यासहरू प्रदर्शन गर्ने योजना गर्छु।

स्वचालन पूर्वाधारको लागि मूल्य

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

पूर्वाधारको वर्तमान अवस्थाको चित्रण

अन्वेषण गर्न लिङ्कहरू

• सेलेनियम
• एपियम
• एन्ड्रोइड इमुलेटर
• सेलेनियम JS GitHub उदाहरणहरू
• Appium JS GitHub उदाहरणहरू

समान उपकरणहरू

• सेलेनियम/एपियम परीक्षणहरूसँग संयोजनमा तपाईंलाई मनपर्ने कुनै पनि प्रोग्रामिङ भाषा;
• कुनै पनि परीक्षण;
• कुनै पनि परीक्षण धावक।

2. संस्करण नियन्त्रण प्रणाली (Git)

प्रविधिको संक्षिप्त विवरण

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

स्वचालन पूर्वाधारको लागि मूल्य

र यहाँ तपाइँ एक व्यावहारिक प्रश्न सोध्न सक्नुहुन्छ: "किन उसले हामीलाई Git बारे बताइरहेको छ? सबैलाई यो थाहा छ र यसलाई विकास कोड र स्वत: परीक्षण कोड दुवैको लागि प्रयोग गर्दछ। तपाईं बिल्कुल सही हुनुहुनेछ, तर यस लेखमा हामी पूर्वाधारको बारेमा कुरा गर्दैछौं र यो खण्डले खण्ड 7 को पूर्वावलोकनको रूपमा कार्य गर्दछ: "संहिताको रूपमा पूर्वाधार (IaC)"। हाम्रो लागि, यसको मतलब परीक्षण सहित सम्पूर्ण पूर्वाधार कोडको रूपमा वर्णन गरिएको छ, त्यसैले हामी यसमा संस्करण प्रणालीहरू पनि लागू गर्न सक्छौं र विकास र स्वचालन कोडको लागि समान लाभहरू प्राप्त गर्न सक्छौं।

हामी IaC लाई चरण 7 मा थप विस्तारमा हेर्नेछौं, तर अहिले पनि तपाईले स्थानीय भण्डार सिर्जना गरेर स्थानीय रूपमा Git प्रयोग गर्न सुरु गर्न सक्नुहुन्छ। हामीले पूर्वाधारमा रिमोट रिपोजिटरी थप्दा ठूलो चित्र विस्तार हुनेछ।

पूर्वाधारको वर्तमान अवस्थाको चित्रण

अन्वेषण गर्न लिङ्कहरू

• संस्करण नियन्त्रण के हो
• Git
• सुरु गर्दै - संस्करण नियन्त्रण बारे

समान उपकरणहरू

• SVN
• मर्कुरियल 
• Microsoft TFS (अब Azure DevOps सेवाहरूको अंश हो)

३. कन्टेनराइजेशन (डकर)

प्रविधिको संक्षिप्त विवरण

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

विकासको अर्को चरण भर्चुअल मेसिनहरू (VMs) थियो, जसले अप्रयुक्त स्रोतहरूमा पैसा बर्बाद गर्ने समस्या समाधान गर्‍यो। यो प्रविधिले एउटै सर्भर भित्र एक अर्काबाट स्वतन्त्र रूपमा एप्लिकेसनहरू चलाउन सम्भव बनायो, पूर्ण रूपमा पृथक ठाउँ आवंटित गर्दै। तर, दुर्भाग्यवश, कुनै पनि प्रविधि यसको कमजोरी छ। VM चलाउनको लागि पूर्ण अपरेटिङ सिस्टम चाहिन्छ, जसले CPU, RAM, भण्डारण उपभोग गर्छ र, OS मा निर्भर गर्दै, इजाजतपत्र लागतहरूलाई ध्यानमा राख्नुपर्छ। यी कारकहरूले लोडिङ गतिलाई असर गर्छ र पोर्टेबिलिटीलाई गाह्रो बनाउँछ।

र अब हामी कन्टेनराइजेशनमा आउँछौं। एक पटक फेरि, यस प्रविधिले अघिल्लो समस्या समाधान गर्दछ, किनकि कन्टेनरहरूले पूर्ण ओएस प्रयोग गर्दैनन्, जसले ठूलो मात्रामा स्रोतहरू खाली गर्दछ र पोर्टेबिलिटीको लागि छिटो र लचिलो समाधान प्रदान गर्दछ।

निस्सन्देह, कन्टेनराइजेशन टेक्नोलोजी कुनै नयाँ कुरा होइन र पहिलो पटक 70 को दशकमा पेश गरिएको थियो। ती दिनहरूमा, धेरै अनुसन्धान, विकास, र प्रयासहरू गरियो। तर यो डकर थियो जसले यो प्रविधिलाई अनुकूलित गर्यो र यसलाई जनताको लागि सजिलै पहुँचयोग्य बनायो। आजकल, जब हामी कन्टेनरहरूको बारेमा कुरा गर्छौं, धेरै जसो केसहरूमा हाम्रो मतलब डकर हो। जब हामी डकर कन्टेनरहरूको बारेमा कुरा गर्छौं, हाम्रो मतलब लिनक्स कन्टेनरहरू। हामी कन्टेनरहरू चलाउन Windows र macOS प्रणालीहरू प्रयोग गर्न सक्छौं, तर यो बुझ्न महत्त्वपूर्ण छ कि यस अवस्थामा एक अतिरिक्त तह देखिन्छ। उदाहरण को लागी, म्याक मा डकर चुपचाप एक हल्का लिनक्स VM भित्र कन्टेनर चलाउँछ। हामी कन्टेनर भित्र एन्ड्रोइड इमुलेटरहरू चलाउने बारे छलफल गर्दा हामी यस विषयमा फर्कनेछौं, त्यसैले यहाँ एक धेरै महत्त्वपूर्ण सूक्ष्मता छ जुन थप विस्तारमा छलफल गर्न आवश्यक छ।

स्वचालन पूर्वाधारको लागि मूल्य

हामीले पत्ता लगायौं कि कन्टेनराइजेशन र डकर राम्रो छ। यसलाई स्वचालनको सन्दर्भमा हेरौं, किनभने प्रत्येक उपकरण वा प्रविधिले समस्या समाधान गर्न आवश्यक छ। UI परीक्षणको सन्दर्भमा परीक्षण स्वचालनको स्पष्ट समस्याहरूलाई रूपरेखा गरौं:

• सेलेनियम र विशेष गरी एपियम स्थापना गर्दा निर्भरताहरूको ठूलो संख्या;
• ब्राउजर, सिमुलेटर र ड्राइभरहरूको संस्करणहरू बीच अनुकूलता समस्याहरू;
• ब्राउजर/सिम्युलेटरहरूको लागि पृथक ठाउँको अभाव, जुन समानान्तर दौडका लागि विशेष गरी महत्त्वपूर्ण छ;
• यदि तपाइँ एकै समयमा 10, 50, 100 वा 1000 ब्राउजरहरू चलाउन आवश्यक छ भने व्यवस्थापन गर्न र मर्मत गर्न गाह्रो छ।

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

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

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

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

वेब को लागी Selenoid

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

तर, अफसोस, सेलेनोइड अझै पनि चाँदीको गोली होइन। हामीले 'मागमा ब्राउजर' सुविधा पायौं, तर 'डिमान्डमा संसाधन' सुविधा अझै उपलब्ध छैन। Selenoid प्रयोग गर्नको लागि, हामीले यसलाई भौतिक हार्डवेयर वा VM मा तैनात गर्नुपर्छ, जसको अर्थ हामीले पहिले नै थाहा पाउनु पर्छ कति स्रोतहरू आवंटित गर्न आवश्यक छ। मलाई लाग्छ कि यो समानान्तरमा 10, 20 वा 30 ब्राउजरहरू चलाउने साना परियोजनाहरूको लागि समस्या होइन। तर हामीलाई १००, ५००, १००० वा बढी चाहिन्छ भने के हुन्छ? सबै समय यति धेरै स्रोतहरू कायम राख्न र तिर्नको कुनै अर्थ छैन। यस लेखको खण्ड 100 र 500 मा, हामी समाधानहरू छलफल गर्नेछौं जसले तपाईंलाई मापन गर्न अनुमति दिन्छ, जसले गर्दा कम्पनीको लागतमा उल्लेखनीय रूपमा कमी आउँछ।

एन्ड्रोइडका लागि सेलेनोइड

वेब स्वचालन उपकरणको रूपमा सेलेनोइडको सफलता पछि, मानिसहरूले एन्ड्रोइडको लागि यस्तै केहि चाहन्थे। र यो भयो - सेलेनोइड एन्ड्रोइड समर्थनको साथ जारी गरिएको थियो। उच्च-स्तर प्रयोगकर्ताको दृष्टिकोणबाट, सञ्चालनको सिद्धान्त वेब स्वचालन जस्तै छ। फरक यति मात्र हो कि ब्राउजर कन्टेनरको सट्टा, सेलेनोइडले एन्ड्रोइड इमुलेटर कन्टेनरहरू चलाउँछ। मेरो विचारमा, यो हाल समानान्तरमा एन्ड्रोइड परीक्षणहरू चलाउनको लागि सबैभन्दा शक्तिशाली नि: शुल्क उपकरण हो।

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

पूर्वाधारको वर्तमान अवस्थाको चित्रण

यस लेखको सन्दर्भमा, हामी पूर्वाधार चित्रण गर्न २ उपकरणहरू थप्नेछौं। यी वेब परीक्षणहरूको लागि सेलेनियम ग्रिड र एन्ड्रोइड परीक्षणहरूको लागि सेलेनोइड हुन्। GitHub ट्यूटोरियलमा, म तपाइँलाई वेब परीक्षणहरू चलाउन कसरी Selenoid प्रयोग गर्ने भनेर पनि देखाउनेछु। 

अन्वेषण गर्न लिङ्कहरू

• डकर: के कन्टेनर हो
• डकर: सुरु गर्नुहोस्
• डकरका लागि 5 कन्टेनर विकल्पहरू
• सेलेनियम ग्रिड
• सेलेनियम डकर
• सेलेनोइड
• Selenoid Github
• एन्ड्रोइड इमुलेटरहरूको लागि KVM सेटअप
• डकर डीप डाइभ पुस्तक

समान उपकरणहरू

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

4.CI/CD

प्रविधिको संक्षिप्त विवरण

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

त्यसोभए, त्यहाँ 3 सर्तहरू छन्: CI - निरन्तर एकीकरण, CD - निरन्तर डेलिभरी र फेरि CD - निरन्तर तैनाती। (तल म यी सर्तहरू अंग्रेजीमा प्रयोग गर्नेछु)। प्रत्येक परिमार्जनले तपाईंको विकास पाइपलाइनमा धेरै अतिरिक्त चरणहरू थप्छ। तर शब्द निरन्तर (निरन्तर) सबैभन्दा महत्त्वपूर्ण कुरा हो। यस सन्दर्भमा, हामीले कुनै अवरोध वा म्यानुअल हस्तक्षेप बिना सुरुदेखि अन्त्यसम्म हुने कुरा भनेको हो। यस सन्दर्भमा CI र CD र CD हेरौं।

• निरन्तर एकीकरण यो विकासको प्रारम्भिक चरण हो। सर्भरमा नयाँ कोड पेस गरेपछि, हामी हाम्रा परिवर्तनहरू ठीक छ भनी द्रुत प्रतिक्रिया प्राप्त गर्ने आशा गर्छौं। सामान्यतया, CI मा चलिरहेको स्थिर कोड विश्लेषण उपकरणहरू र एकाइ/आन्तरिक API परीक्षणहरू समावेश छन्। यसले हामीलाई हाम्रो कोडको बारेमा केही सेकेन्ड/मिनेटमा जानकारी प्राप्त गर्न अनुमति दिन्छ।
• लगातार वितरण एक थप उन्नत चरण हो जहाँ हामी एकीकरण/UI परीक्षणहरू चलाउँछौं। यद्यपि, यस चरणमा हामीले CI को रूपमा छिटो परिणामहरू प्राप्त गर्दैनौं। पहिलो, यी प्रकारका परीक्षणहरू पूरा हुन लामो समय लाग्छ। दोस्रो, सुरु गर्नु अघि, हामीले हाम्रा परिवर्तनहरू परीक्षण/स्टेजिङ वातावरणमा प्रयोग गर्नुपर्छ। यसबाहेक, यदि हामी मोबाइल विकासको बारेमा कुरा गर्दैछौं, त्यसपछि हाम्रो अनुप्रयोगको निर्माण सिर्जना गर्न थप कदम देखिन्छ।
• निरन्तर तैनाती यदि सबै स्वीकृति परीक्षणहरू अघिल्लो चरणहरूमा पास भइसकेका छन् भने हामीले उत्पादनमा हाम्रा परिवर्तनहरू स्वचालित रूपमा जारी गर्छौं भनेर मानिन्छ। यसका अतिरिक्त, रिलीज चरण पछि, तपाइँ विभिन्न चरणहरू कन्फिगर गर्न सक्नुहुन्छ, जस्तै उत्पादनमा धुम्रपान परीक्षणहरू चलाउने र रुचिको मेट्रिक्स सङ्कलन। निरन्तर परिनियोजन स्वचालित परीक्षणहरूद्वारा राम्रो कभरेजको साथ मात्र सम्भव छ। यदि कुनै पनि म्यानुअल हस्तक्षेप आवश्यक छ, परीक्षण सहित, तब यो अब छैन लगातार (निरन्तर)। त्यसोभए हामी भन्न सक्छौं कि हाम्रो पाइपलाइनले निरन्तर डेलिभरीको अभ्याससँग मात्र पालना गर्दछ।

स्वचालन पूर्वाधारको लागि मूल्य

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

र हामीले वास्तुकला परिवर्तनको दृष्टान्त हेर्नु अघि, म GitLab CI को बारेमा केहि शब्दहरू भन्न चाहन्छु। अन्य CI/CD उपकरणहरूको विपरीत, GitLab ले रिमोट रिपोजिटरी र अन्य धेरै अतिरिक्त सुविधाहरू प्रदान गर्दछ। यसैले, GitLab CI भन्दा बढी छ। यसमा स्रोत कोड व्यवस्थापन, चुस्त व्यवस्थापन, CI/CD पाइपलाइनहरू, लगिङ उपकरणहरू र बक्स बाहिर मेट्रिक्स सङ्कलन समावेश छ। GitLab आर्किटेक्चर Gitlab CI/CD र GitLab धावक समावेश गर्दछ। यहाँ आधिकारिक वेबसाइटबाट छोटो विवरण छ:

Gitlab CI/CD एक API को साथ एक वेब अनुप्रयोग हो जसले यसको राज्यलाई डेटाबेसमा भण्डार गर्दछ, परियोजनाहरू/निर्माणहरू प्रबन्ध गर्दछ र प्रयोगकर्ता इन्टरफेस प्रदान गर्दछ। GitLab Runner एउटा एप्लिकेसन हो जसले निर्माण प्रक्रिया गर्दछ। यसलाई छुट्टै तैनाथ गर्न सकिन्छ र एपीआई मार्फत GitLab CI/CD सँग काम गर्दछ। चलिरहेको परीक्षणहरूको लागि तपाईंलाई Gitlab उदाहरण र धावक दुवै चाहिन्छ।

पूर्वाधारको वर्तमान अवस्थाको चित्रण

अन्वेषण गर्न लिङ्कहरू

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

समान उपकरणहरू

• जेनकिन्स
• TeamCity
• ट्रैविस 
• र धेरै अन्य

5. क्लाउड प्लेटफार्महरू

प्रविधिको संक्षिप्त विवरण

यस खण्डमा हामी 'पब्लिक क्लाउड' नामक लोकप्रिय प्रवृत्तिको बारेमा कुरा गर्नेछौं। माथि वर्णन गरिएको भर्चुअलाइजेशन र कन्टेनराइजेशन टेक्नोलोजीहरूले प्रदान गर्ने विशाल फाइदाहरूको बावजुद, हामीलाई अझै पनि कम्प्युटिङ स्रोतहरू चाहिन्छ। कम्पनीहरूले महँगो सर्भरहरू खरिद गर्छन् वा डाटा सेन्टरहरू भाडामा लिन्छन्, तर यस अवस्थामा हामीले कति स्रोतहरू चाहिन्छ भनेर गणना गर्न आवश्यक छ (कहिलेकाँही अवास्तविक)। उदाहरण को लागी, उत्पादन को लागी 24/7 चलिरहेको सर्भर चाहिन्छ, तर के हामीलाई काम को घण्टा बाहिर परीक्षण को लागी समान स्रोतहरु को आवश्यकता छ? यो परीक्षणको प्रकारमा पनि निर्भर गर्दछ। एउटा उदाहरण लोड/तनाव परीक्षणहरू हुन् जुन हामीले अर्को दिन नतिजाहरू प्राप्त गर्नका लागि गैर-कामका घण्टाहरूमा चलाउने योजना बनाउँछौं। तर निश्चित रूपमा XNUMX/XNUMX सर्भर उपलब्धता अन्त-देखि-अन्त स्वचालित परीक्षणहरूको लागि आवश्यक पर्दैन र विशेष गरी म्यानुअल परीक्षण वातावरणहरूको लागि होइन। त्यस्ता परिस्थितिहरूको लागि, मागमा आवश्यक पर्ने धेरै स्रोतहरू प्राप्त गर्नु राम्रो हुन्छ, तिनीहरूलाई प्रयोग गर्नुहोस्, र तिनीहरूको आवश्यकता नभएको बेला भुक्तान गर्न बन्द गर्नुहोस्। यसबाहेक, केहि माउस क्लिकहरू बनाएर वा केही स्क्रिप्टहरू चलाएर तिनीहरूलाई तुरुन्तै प्राप्त गर्न राम्रो हुनेछ। यसका लागि सार्वजनिक क्लाउडहरू प्रयोग गरिन्छ। परिभाषा हेरौं:

"सार्वजनिक क्लाउडलाई सार्वजनिक इन्टरनेटमा तेस्रो-पक्ष प्रदायकहरूद्वारा प्रस्तावित कम्प्युटिङ सेवाहरूको रूपमा परिभाषित गरिएको छ, जसले तिनीहरूलाई प्रयोग गर्न वा खरिद गर्न चाहने जो कोहीलाई उपलब्ध गराउँछ। तिनीहरू नि: शुल्क वा मागमा बेच्न सकिन्छ, ग्राहकहरूलाई CPU चक्र, भण्डारण, वा ब्यान्डविथ तिनीहरूले खपत गर्ने प्रति प्रयोग मात्र तिर्न अनुमति दिन्छ।"

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

स्वचालन पूर्वाधारको लागि मूल्य

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

सबैभन्दा लोकप्रिय क्लाउड प्रदायकहरू Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP) हुन्। कसरी गर्ने गाइडले GCP कसरी प्रयोग गर्ने भन्ने उदाहरणहरू प्रदान गर्दछ, तर सामान्यतया तपाईंले स्वचालन कार्यहरूका लागि के प्रयोग गर्नुहुन्छ भन्ने कुराले फरक पार्दैन। तिनीहरू सबैले लगभग समान कार्यक्षमता प्रदान गर्दछ। सामान्यतया, प्रदायक चयन गर्न, व्यवस्थापनले कम्पनीको सम्पूर्ण पूर्वाधार र व्यापार आवश्यकताहरूमा ध्यान केन्द्रित गर्दछ, जुन यस लेखको दायराभन्दा बाहिर छ। स्वचालन ईन्जिनियरहरूका लागि, क्लाउड प्रदायकहरूको प्रयोगलाई क्लाउड प्लेटफर्महरूको प्रयोगसँग तुलना गर्न अझ चाखलाग्दो हुनेछ विशेष गरी परीक्षण उद्देश्यका लागि, जस्तै Sauce Labs, BrowserStack, BitBar, र यस्तै। त्यसोभए यो पनि गरौं! मेरो विचारमा, सस ल्याबहरू सबैभन्दा प्रसिद्ध क्लाउड परीक्षण फार्म हो, त्यसैले मैले यसलाई तुलनाको लागि प्रयोग गरें। 

GCP बनाम सस ल्याबहरू स्वचालन उद्देश्यका लागि:

कल्पना गरौं कि हामीले 8 वेब परीक्षणहरू र 8 एन्ड्रोइड परीक्षणहरू एकैसाथ चलाउन आवश्यक छ। यसका लागि हामी GCP प्रयोग गर्नेछौं र सेलेनोइडसँग २ भर्चुअल मेसिनहरू चलाउनेछौं। पहिलोमा हामी ब्राउजरहरूसँग 2 कन्टेनरहरू उठाउनेछौं। दोस्रोमा त्यहाँ 8 कन्टेनरहरू इमुलेटरहरू छन्। आउनुहोस् मूल्यहरू हेरौं:  

Chrome को साथ एउटा कन्टेनर चलाउन, हामीलाई चाहिन्छ n1-मानक-1 कार। एन्ड्रोइड को मामला मा यो हुनेछ n1-मानक-4 एउटा इमुलेटरको लागि। वास्तवमा, अधिक लचिलो र सस्तो तरीका भनेको CPU/मेमोरीका लागि विशिष्ट प्रयोगकर्ता मानहरू सेट गर्नु हो, तर यस समयमा यो सस ल्याबहरूसँग तुलना गर्न महत्त्वपूर्ण छैन।

र यहाँ सस ल्याबहरू प्रयोग गर्नका लागि शुल्कहरू छन्:

मलाई विश्वास छ कि तपाईंले पहिले नै भिन्नता देख्नुभएको छ, तर म अझै पनि हाम्रो कार्यको लागि गणनाको साथ तालिका प्रदान गर्नेछु:

आवश्यक स्रोतसाधन
मोन्टली
कार्य घन्टा(8 बजे - 8 बजे)
कार्य घन्टा+ पूर्वनिर्धारित

वेब को लागी GCP
n1-मानक-1 x 8 = n1-मानक-8
$194.18
२३ दिन * १२ घन्टा * ०.३८ = $१०४.८८ 
२३ दिन * १२ घन्टा * ०.३८ = $१०४.८८

वेबको लागि सस ल्याबहरू
भर्चुअल Cloud8 समानान्तर परीक्षण
$1.559
-
-

एन्ड्रोइड को लागी GCP
n1-मानक-4 x 8: n1-मानक-16
$776.72
२३ दिन * १२ घन्टा * ०.३८ = $१०४.८८ 
२३ दिन * १२ घन्टा * ०.३८ = $१०४.८८

एन्ड्रोइडका लागि सस ल्याबहरू
वास्तविक उपकरण क्लाउड 8 समानान्तर परीक्षण
$1.999
-
-

तपाईले देख्न सक्नुहुने रूपमा, लागतमा भिन्नता ठूलो छ, विशेष गरी यदि तपाईले बाह्र घण्टाको कार्य अवधिमा मात्र परीक्षण चलाउनुहुन्छ। तर यदि तपाइँ प्रिमेप्टिबल मेशिनहरू प्रयोग गर्नुहुन्छ भने तपाइँ लागतहरू अझ घटाउन सक्नुहुन्छ। यो के हो?

एक प्रिमप्टिबल VM एउटा उदाहरण हो जुन तपाईंले सामान्य उदाहरणहरू भन्दा धेरै कम मूल्यमा सिर्जना गर्न र चलाउन सक्नुहुन्छ। यद्यपि, कम्प्युट इन्जिनले अन्य कार्यहरूको लागि ती स्रोतहरूमा पहुँच आवश्यक भएमा यी उदाहरणहरूलाई समाप्त (प्रीम्प्ट) गर्न सक्छ। प्रिमप्टिबल उदाहरणहरू कम्प्युट इन्जिन क्षमताभन्दा बढी छन्, त्यसैले तिनीहरूको उपलब्धता प्रयोग अनुसार भिन्न हुन्छ।

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

र यो अझै समाप्त भएको छैन! वास्तवमा, म पक्का छु कि कसैले पनि 12 घण्टाको लागि ब्रेक बिना परीक्षण चलाउँदैन। र यदि त्यसो हो भने, तपाईंले भर्चुअल मेसिनहरू आवश्यक नभएको बेला स्वचालित रूपमा सुरू गर्न र रोक्न सक्नुहुन्छ। वास्तविक उपयोग समय प्रति दिन 6 घण्टा घटाउन सकिन्छ। त्यसपछि हाम्रो कार्यको सन्दर्भमा भुक्तान 11 ब्राउजरहरूको लागि प्रति महिना $ 8 मा घट्नेछ। यो गजब हैन र? तर प्रिमेप्टिबल मेशिनहरूसँग हामी सावधान र अवरोधहरू र अस्थिरताको लागि तयार हुनुपर्छ, यद्यपि यी परिस्थितिहरू सफ्टवेयरमा प्रदान गर्न र ह्यान्डल गर्न सकिन्छ। यो लायक छ!

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

पूर्वाधारको वर्तमान अवस्थाको चित्रण

अन्वेषण गर्न लिङ्कहरू

• GCP
• GCP: पूर्वनिर्धारित
• GCP: VM मूल्य निर्धारण
• सस ल्याबहरू
• क्लाउड प्रदायकहरू तुलना गर्दै

समान उपकरणहरू:

• AWS 
• ट्याबनेतृत्व

६. अर्केस्ट्रेशन

प्रविधिको संक्षिप्त विवरण

मसँग राम्रो समाचार छ - हामी लगभग लेखको अन्त्यमा छौं! यस समयमा, हाम्रो स्वचालन पूर्वाधारमा वेब र एन्ड्रोइड परीक्षणहरू छन्, जुन हामी समानान्तर रूपमा GitLab CI मार्फत चलाउँछौं, Docker-सक्षम उपकरणहरू प्रयोग गरेर: Selenium grid र Selenoid। यसबाहेक, हामी ब्राउजर र इमुलेटरहरू भएका कन्टेनरहरू होस्ट गर्न GCP मार्फत सिर्जना गरिएका भर्चुअल मेसिनहरू प्रयोग गर्छौं। लागत घटाउनको लागि, हामी यी भर्चुअल मेशिनहरू मागमा मात्र सुरु गर्छौं र परीक्षण नगरिएको बेला तिनीहरूलाई रोक्छौं। हाम्रो पूर्वाधार सुधार गर्न सक्ने अरू केही छ कि? जवाफ हो हो! Kubernetes (K8s) लाई भेट्नुहोस्!

पहिले, अर्केस्ट्रेशन, क्लस्टर र कुबेरनेट शब्दहरू कसरी एकअर्कासँग सम्बन्धित छन् भनी हेरौं। उच्च स्तरमा, अर्केस्ट्रेशन प्रणाली हो जसले अनुप्रयोगहरू डिप्लोइ र प्रबन्ध गर्दछ। परीक्षण स्वचालनको लागि, त्यस्ता कन्टेनराइज्ड अनुप्रयोगहरू सेलेनियम ग्रिड र सेलेनोइड हुन्। Docker र K8s एक अर्काको पूरक हुन्। पहिलो अनुप्रयोग परिनियोजनको लागि प्रयोग गरिन्छ, दोस्रो अर्केस्ट्रेसनको लागि। बारीमा, K8s एक क्लस्टर हो। क्लस्टरको कार्य VM हरू नोडहरूको रूपमा प्रयोग गर्नु हो, जसले तपाईंलाई विभिन्न प्रकार्यहरू, कार्यक्रमहरू र सेवाहरू एक सर्भर (क्लस्टर) भित्र स्थापना गर्न अनुमति दिन्छ। यदि कुनै नोडहरू असफल भएमा, अन्य नोडहरू उठ्नेछन्, जसले हाम्रो अनुप्रयोगको निर्बाध सञ्चालन सुनिश्चित गर्दछ। यसका अतिरिक्त, K8s मा स्केलिंगसँग सम्बन्धित महत्त्वपूर्ण कार्यक्षमता छ, जसको लागि हामी स्वचालित रूपमा लोड र सेट सीमाहरूमा आधारित स्रोतहरूको इष्टतम मात्रा प्राप्त गर्छौं।

वास्तवमा, म्यानुअल रूपमा स्क्र्याचबाट Kubernetes तैनाती कुनै पनि मामूली काम होइन। म प्रसिद्ध कसरी गाइड "कुबर्नेट्स द हार्ड वे" को लिङ्क छोड्नेछु र यदि तपाइँ इच्छुक हुनुहुन्छ भने, तपाइँ यसलाई अभ्यास गर्न सक्नुहुन्छ। तर, सौभाग्य देखि, त्यहाँ वैकल्पिक विधि र उपकरणहरू छन्। सबैभन्दा सजिलो तरीका भनेको GCP मा Google Kubernetes Engine (GKE) प्रयोग गर्नु हो, जसले तपाईंलाई केही क्लिकहरूमा तयार क्लस्टर प्राप्त गर्न अनुमति दिनेछ। म सिक्न सुरु गर्नको लागि यो दृष्टिकोण प्रयोग गर्न सिफारिस गर्छु, किनकि यसले तपाइँलाई तपाइँको कार्यहरूको लागि K8s कसरी प्रयोग गर्ने भनेर सिक्नमा ध्यान केन्द्रित गर्न अनुमति दिनेछ कि कसरी आन्तरिक घटकहरू एकसाथ एकीकृत गर्नुपर्छ भनेर सिक्न। 

स्वचालन पूर्वाधारको लागि मूल्य

K8s ले प्रदान गर्ने केही महत्त्वपूर्ण सुविधाहरूलाई हेरौं:

• अनुप्रयोग तैनाती: VMs को सट्टा बहु-नोड क्लस्टर प्रयोग गर्दै;
• गतिशील स्केलिंग: मागमा मात्र प्रयोग हुने स्रोतहरूको लागत घटाउँछ;
• आत्म-उपचार: पोडहरूको स्वचालित रिकभरी (जसको फलस्वरूप कन्टेनरहरू पनि पुनर्स्थापित हुन्छन्);
• डाउनटाइम बिना अपडेटहरूको रोलआउट र परिवर्तनहरूको रोलब्याक: उपकरणहरू, ब्राउजरहरू र इमुलेटरहरू अद्यावधिक गर्नाले हालका प्रयोगकर्ताहरूको काममा अवरोध गर्दैन।

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

स्केलिंग सुविधा कुञ्जी हो र क्लस्टर नोड-पूल र नोड भित्र पोडहरू दुवै नोडहरूमा लागू गर्न सकिन्छ। त्यहाँ 2 प्रकारका स्केलिंगहरू छन् जुन दुबै नोडहरू र पोडहरूमा लागू हुन्छन्। पहिलो प्रकार तेर्सो हो - स्केलिंग नोड्स/पोडहरूको संख्या बढाएर हुन्छ। यो प्रकार बढी उपयुक्त छ। दोस्रो प्रकार, तदनुसार, ठाडो छ। स्केलिंग नोड्स/पोडहरूको आकार बढाएर गरिन्छ, तिनीहरूको संख्या होइन।

अब माथिका सर्तहरूको सन्दर्भमा हाम्रा उपकरणहरू हेरौं।

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

पहिले उल्लेख गरिए अनुसार, सेलेनियम ग्रिड एक धेरै लोकप्रिय उपकरण हो, र यो कुनै आश्चर्यको कुरा होइन कि यो कन्टेनराइज गरिएको छ। त्यसकारण, यो कुनै आश्चर्यको कुरा होइन कि सेलेनियम ग्रिड K8s मा तैनात गर्न सकिन्छ। यो कसरी गर्ने भन्ने उदाहरण आधिकारिक K8s भण्डारमा फेला पार्न सकिन्छ। सामान्य रूपमा, म सेक्सनको अन्त्यमा लिङ्कहरू संलग्न गर्दछु। थप रूपमा, कसरी गर्ने गाइडले Terraform मा यो कसरी गर्ने भनेर देखाउँछ। त्यहाँ ब्राउजर कन्टेनरहरू समावेश गर्ने पोडहरूको संख्या कसरी मापन गर्ने भनेर निर्देशनहरू पनि छन्। तर K8s को सन्दर्भमा स्वचालित स्केलिंग प्रकार्य अझै पनि पूर्ण रूपमा स्पष्ट कार्य होइन। जब मैले अध्ययन सुरु गरें, मैले कुनै व्यावहारिक निर्देशन वा सिफारिसहरू फेला पारेन। DevOps टोलीको समर्थनमा धेरै अध्ययनहरू र प्रयोगहरू पछि, हामीले एउटा पोड भित्र आवश्यक ब्राउजरहरूसँग कन्टेनरहरू उठाउने दृष्टिकोण रोज्यौं, जुन एक कार्यकर्ता नोड भित्र अवस्थित छ। यो विधिले हामीलाई तिनीहरूको संख्या बढाएर नोडहरूको तेर्सो स्केलिंगको रणनीति लागू गर्न अनुमति दिन्छ। मलाई आशा छ कि यो भविष्यमा परिवर्तन हुनेछ र हामीले अझ राम्रो दृष्टिकोण र तयार समाधानहरूको थप विवरणहरू देख्नेछौं, विशेष गरी सेलेनियम ग्रिड 4 को परिवर्तन पछि आन्तरिक वास्तुकलाको साथ।

सेलेनोइड:

K8s मा Selenoid तैनाती हाल सबैभन्दा ठूलो निराशा हो। तिनीहरू संगत छैनन्। सिद्धान्तमा, हामी पोड भित्र सेलेनोइड कन्टेनर उठाउन सक्छौं, तर जब सेलेनोइडले ब्राउजरहरूसँग कन्टेनरहरू सुरू गर्न थाल्छ, तिनीहरू अझै पनि उही पोड भित्र हुनेछन्। यसले स्केलिंग असम्भव बनाउँछ र नतिजाको रूपमा, क्लस्टर भित्र सेलेनोइडको काम भर्चुअल मेसिन भित्रको काम भन्दा फरक हुनेछैन। कथाको अन्त्य।

चन्द्र:

सेलेनोइडसँग काम गर्दा यो अवरोध थाहा पाएर, विकासकर्ताहरूले मून भनिने थप शक्तिशाली उपकरण जारी गरे। यो उपकरण मूल रूपमा Kubernetes सँग काम गर्न डिजाइन गरिएको थियो र परिणाम स्वरूप, स्वत: स्केलिंग सुविधा प्रयोग गर्न सकिन्छ र हुनुपर्छ। यसबाहेक, म भन्न चाहन्छु कि अहिले यो छ एकल सेलेनियम संसारमा एउटा उपकरण, जसमा बक्स बाहिर नेटिभ K8s क्लस्टर समर्थन छ (अब उपलब्ध छैन, अर्को उपकरण हेर्नुहोस् )। यो समर्थन प्रदान गर्ने चन्द्रमाका मुख्य विशेषताहरू हुन्: 

पूर्ण राज्यविहीन। सेलेनोइडले हाल चलिरहेको ब्राउजर सत्रहरूको बारेमा मेमोरी जानकारी भण्डार गर्दछ। यदि कुनै कारणले गर्दा यसको प्रक्रिया क्र्यास हुन्छ — तब सबै चलिरहेको सत्रहरू हराएका छन्। चन्द्रमाको विपरित रूपमा कुनै आन्तरिक अवस्था छैन र डाटा केन्द्रहरूमा प्रतिलिपि गर्न सकिन्छ। ब्राउजर सत्रहरू जीवित रहन्छन् यदि एक वा धेरै प्रतिकृतिहरू तल गए पनि।

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

Callisto: (ध्यान! यो मूल लेखमा छैन र रूसी अनुवादमा मात्र समावेश छ)

मैले भनेझैं, सेलेनियम एक धेरै लोकप्रिय उपकरण हो, र आईटी क्षेत्र धेरै चाँडै विकास हुँदैछ। जब मैले अनुवादमा काम गरिरहेको थिएँ, वेबमा Callisto नामक नयाँ आशाजनक उपकरण देखा पर्‍यो (नमस्ते साइप्रस र अन्य सेलेनियम किलरहरू)। यसले K8s सँग नेटिभ रूपमा काम गर्दछ र तपाईंलाई नोडहरूमा वितरित सेलेनोइड कन्टेनरहरू पोडहरूमा चलाउन अनुमति दिन्छ। अटोस्केलिंग सहित सबै कुरा बाकसको बाहिर काम गर्दछ। शानदार, तर परीक्षण गर्न आवश्यक छ। मैले पहिले नै यो उपकरण प्रयोग गर्न र धेरै प्रयोगहरू चलाउन व्यवस्थित गरेको छु। तर निष्कर्ष निकाल्न धेरै चाँडो छ, लामो दूरीमा परिणामहरू प्राप्त गरेपछि, सायद म भविष्यका लेखहरूमा समीक्षा गर्नेछु। अहिलेको लागि म स्वतन्त्र अनुसन्धानको लागि मात्र लिङ्कहरू छोड्दै छु।  

पूर्वाधारको वर्तमान अवस्थाको चित्रण

अन्वेषण गर्न लिङ्कहरू

• Kubernetes: सेटअप
• Kubernetes: कठिन बाटो
• Kubernetes: सेलेनियम
• GCP: Kubernetes इन्जिन
• चन्द्र
• कुबेरनेट बुक
• Kubernetes प्रयोग गरेर वितरण स्वचालन
• सेलेनियम ग्रिड ४
• Callisto GitHub
• Wrike TechClub (Callisto)

समान उपकरणहरू

• डकर झुण्ड 
• म्याराथन 

7. कोड (IaC) को रूपमा पूर्वाधार

प्रविधिको संक्षिप्त विवरण

र अब हामी अन्तिम खण्डमा आउँछौं। सामान्यतया, यो प्रविधि र सम्बन्धित कार्यहरू स्वचालन इन्जिनियरहरूको जिम्मेवारी होइन। र यसका कारणहरू छन्। पहिलो, धेरै संस्थाहरूमा, पूर्वाधारका मुद्दाहरू DevOps विभागको नियन्त्रणमा छन् र विकास टोलीहरूले पाइपलाइनले के काम गर्छ र कसरी यससँग जोडिएको सबै कुरालाई समर्थन गर्न आवश्यक छ भन्ने कुरामा वास्तवमै वास्ता गर्दैनन्। दोस्रो, इमान्दारीपूर्वक भनौं, कोड (IaC) को रूपमा पूर्वाधारको अभ्यास अझै धेरै कम्पनीहरूमा अपनाइएको छैन। तर यो पक्कै पनि लोकप्रिय प्रवृत्ति भएको छ र यससँग सम्बन्धित प्रक्रिया, दृष्टिकोण र उपकरणहरूमा संलग्न हुन प्रयास गर्नु महत्त्वपूर्ण छ। वा कम्तिमा अप टु डेट रहनुहोस्।

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

यस लेखमा र कसरी गाइड गर्ने, म IaC अभ्याससँग सम्बन्धित 2 उपकरणहरू प्रयोग गर्छु। यी Terraform र उत्तरदायी छन्। केही मानिसहरू विश्वास गर्छन् कि तिनीहरूलाई एकै समयमा प्रयोग गर्न कुनै अर्थ छैन, किनकि तिनीहरूको कार्यक्षमता समान छ र तिनीहरू आदानप्रदानयोग्य छन्। तर तथ्य यो छ कि प्रारम्भमा तिनीहरूलाई पूर्ण रूपमा फरक कार्यहरू दिइन्छ। र यी उपकरणहरूले एकअर्कालाई पूरक हुनुपर्छ भन्ने तथ्यलाई HashiCorp र RedHat प्रतिनिधित्व गर्ने विकासकर्ताहरूद्वारा संयुक्त प्रस्तुतिमा पुष्टि गरियो। वैचारिक भिन्नता यो हो कि Terraform सर्भरहरू आफैं व्यवस्थापन गर्नको लागि एक प्रावधान उपकरण हो। जबकि Ansible कन्फिगरेसन व्यवस्थापन उपकरण हो जसको कार्य यी सर्भरहरूमा सफ्टवेयर स्थापना, कन्फिगर र व्यवस्थापन गर्नु हो।

यी उपकरणहरूको अर्को प्रमुख विशेषता कोडिङ शैली हो। bash र Ansible को विपरीत, Terraform ले कार्यान्वयनको परिणामको रूपमा प्राप्त हुने इच्छित अन्तिम अवस्थाको विवरणमा आधारित घोषणात्मक शैली प्रयोग गर्दछ। उदाहरण को लागी, यदि हामी 10 VMs सिर्जना गर्न जाँदैछौं र Terraform मार्फत परिवर्तनहरू लागू गर्न जाँदैछौं, तब हामीले 10 VM प्राप्त गर्नेछौं। यदि हामीले स्क्रिप्टलाई फेरि चलाउँछौं भने, हामीसँग पहिले नै 10 VM हरू भएकाले केही हुने छैन, र Terraform लाई यसको बारेमा थाहा छ किनभने यसले पूर्वाधारको हालको अवस्थालाई राज्य फाइलमा भण्डार गर्छ। तर Ansible ले एक प्रक्रियात्मक दृष्टिकोण प्रयोग गर्दछ र, यदि तपाइँ यसलाई 10 VMs सिर्जना गर्न भन्नुहुन्छ भने, त्यसपछि पहिलो प्रक्षेपणमा हामीले Terraform जस्तै 10 VMs प्राप्त गर्नेछौं। तर पुन: सुरु गरेपछि हामीसँग पहिले नै 20 VM हुनेछ। यो महत्त्वपूर्ण भिन्नता हो। प्रक्रियागत शैलीमा, हामी हालको अवस्था भण्डार गर्दैनौं र केवल प्रदर्शन गर्नै पर्ने चरणहरूको अनुक्रम वर्णन गर्दछौं। निस्सन्देह, हामी विभिन्न परिस्थितिहरू ह्यान्डल गर्न सक्छौं, स्रोतहरूको अस्तित्व र वर्तमान अवस्थाको लागि धेरै जाँचहरू थप्न सक्छौं, तर हाम्रो समय बर्बाद गर्नु र यस तर्कलाई नियन्त्रण गर्न प्रयास गर्नुको कुनै अर्थ छैन। थप रूपमा, यसले गल्ती गर्ने जोखिम बढाउँछ। 

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

स्वचालन पूर्वाधारको लागि मूल्य

यहाँ बुझ्नको लागि मात्र महत्त्वपूर्ण कुरा यो हो कि परीक्षण स्वचालन पूर्वाधारलाई सम्पूर्ण कम्पनी पूर्वाधारको भागको रूपमा विचार गरिनु पर्छ। यसको मतलब सबै IaC अभ्यासहरू सम्पूर्ण संगठनको स्रोतहरूमा विश्वव्यापी रूपमा लागू गरिनुपर्छ। यसको लागि को जिम्मेवार छ तपाइँको प्रक्रियाहरु मा निर्भर गर्दछ। DevOps टोली यी मुद्दाहरूमा बढी अनुभवी छ, उनीहरूले के भइरहेको छ भन्ने सम्पूर्ण तस्वीर देख्छन्। यद्यपि, QA इन्जिनियरहरू स्वचालन र पाइपलाइनको संरचना निर्माण गर्ने प्रक्रियामा बढी संलग्न हुन्छन्, जसले उनीहरूलाई सबै आवश्यक परिवर्तनहरू र सुधारका अवसरहरू राम्रोसँग हेर्न अनुमति दिन्छ। अपेक्षित नतिजा प्राप्त गर्नको लागि सँगै काम गर्नु, ज्ञान र विचारहरू आदानप्रदान गर्नु उत्तम विकल्प हो। 

परीक्षण स्वचालनको सन्दर्भमा Terraform र Ansible प्रयोग गर्ने केही उदाहरणहरू र हामीले पहिले छलफल गरेका उपकरणहरू यहाँ छन्:

1. Terraform प्रयोग गरी VMs र क्लस्टरहरूको आवश्यक विशेषताहरू र मापदण्डहरू वर्णन गर्नुहोस्।

2. Ansible प्रयोग गरेर, परीक्षणको लागि आवश्यक उपकरणहरू स्थापना गर्नुहोस्: डकर, सेलेनोइड, सेलेनियम ग्रिड र ब्राउजर/इम्युलेटरहरूको आवश्यक संस्करणहरू डाउनलोड गर्नुहोस्।

3. Terraform प्रयोग गरेर, VM को विशेषताहरू वर्णन गर्नुहोस् जसमा GitLab रनर सुरु हुनेछ।

4. GitLab धावक र आवश्यक सहयोगी उपकरणहरू Ansible, सेट सेटिङहरू र कन्फिगरेसनहरू प्रयोग गरेर स्थापना गर्नुहोस्।

पूर्वाधारको वर्तमान अवस्थाको चित्रण

अन्वेषण गर्न लिङ्कहरू:

• ट्राफर्म
• अज्ञात
• Ansible र Terraform सँगै राम्रो
• Terraform को लागि एक व्यापक गाइड
• किन हामी टेराफर्म प्रयोग गर्छौं र शेफ, पपेट, उत्तरदायी, साल्टस्ट्याक, वा क्लाउडफर्मेसन होइन
• GCP: IaC

समान उपकरणहरू

• सेफ
• कठपुतली
• साल्ट स्ट्याक
• ब्यवहार

यसलाई संक्षेप गरौं!

चरण
प्रविधि
उपकरण
स्वचालन पूर्वाधारको लागि मूल्य

1
स्थानीय चलिरहेको छ
Node.js, Selenium, Appium

• वेब र मोबाइलको लागि सबैभन्दा लोकप्रिय उपकरण
• धेरै भाषाहरू र प्लेटफर्महरूलाई समर्थन गर्दछ (Node.js सहित)

2
संस्करण नियन्त्रण प्रणाली 
Git

• विकास कोड संग समान लाभ

3
कन्टेनराइजेशन
डकर, सेलेनियम ग्रिड, सेलेनोइड (वेब, एन्ड्रोइड)

• समानान्तर रूपमा चलिरहेको परीक्षण
• पृथक वातावरण
• सरल, लचिलो संस्करण अपग्रेड
• गतिशील रूपमा अप्रयुक्त स्रोतहरू रोक्न
• सेट अप गर्न सजिलो

4
CI/CD
Gitlab CI

• पाइपलाइनको भाग परीक्षण गर्नुहोस्
• द्रुत प्रतिक्रिया
• सम्पूर्ण कम्पनी/टोलीको लागि दृश्यता

5
क्लाउड प्लेटफार्महरू
गुगल क्लाउड प्लेटफार्म

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

6
अर्केस्ट्रेशन
कुबर्नेट्स
पोड भित्र ब्राउजर/इम्युलेटरहरू भएका कन्टेनरहरूको सन्दर्भमा:

• स्केलिंग/स्वत: मापन
• आत्म-उपचार
• कुनै अवरोध बिना अपडेट र रोलब्याक

7
कोडको रूपमा पूर्वाधार (IaC)
Terraform, उत्तरदायी

• विकास पूर्वाधार संग समान लाभ
• कोड संस्करणको सबै फाइदाहरू
• परिवर्तन गर्न र कायम राख्न सजिलो
• पूर्ण स्वचालित

मन नक्सा रेखाचित्र: पूर्वाधारको विकास

चरण 1: स्थानीय

चरण 2: VCS

चरण 3: कन्टेनराइजेशन 

चरण 4: CI/CD 

चरण 5: क्लाउड प्लेटफर्महरू

चरण 6: अर्केस्ट्रेशन

चरण 7: IaC

के अर्को छ?

त्यसैले, यो लेखको अन्त्य हो। तर अन्त्यमा, म तपाईंसँग केही सम्झौताहरू स्थापित गर्न चाहन्छु।

तिम्रो तर्फबाट
मैले सुरुमा भनेझैं, म लेख व्यावहारिक उपयोगको होस् र तपाईंलाई वास्तविक काममा प्राप्त ज्ञान लागू गर्न मद्दत गर्न चाहन्छु। फेरि थप्छु व्यावहारिक गाइडको लिङ्क.

तर त्यस पछि पनि, नरोक्नुहोस्, अभ्यास गर्नुहोस्, सान्दर्भिक लिङ्कहरू र पुस्तकहरू अध्ययन गर्नुहोस्, यसले तपाईंको कम्पनीमा कसरी काम गर्छ भनेर पत्ता लगाउनुहोस्, सुधार गर्न सकिने ठाउँहरू खोज्नुहोस् र यसमा भाग लिनुहोस्। भाग्यले साथ दिओस्!

मेरो तर्फबाट

शीर्षकबाट तपाईले देख्न सक्नुहुन्छ कि यो केवल पहिलो भाग थियो। यो धेरै ठूलो भएको तथ्यको बावजुद, महत्त्वपूर्ण विषयहरू अझै पनि यहाँ समेटिएका छैनन्। दोस्रो भागमा, म IOS को सन्दर्भमा स्वचालन पूर्वाधार हेर्ने योजना गर्छु। MacOS प्रणालीहरूमा मात्र iOS सिमुलेटरहरू चलाउनमा एप्पलको प्रतिबन्धका कारण, हाम्रो समाधानहरूको दायरा साँघुरो छ। उदाहरणका लागि, हामी सिम्युलेटर चलाउन डकर वा भर्चुअल मेसिनहरू चलाउन सार्वजनिक क्लाउडहरू प्रयोग गर्न असमर्थ छौं। तर यसको अर्थ अरु विकल्प छैन भन्ने होइन । म तपाईंलाई उन्नत समाधानहरू र आधुनिक उपकरणहरूसँग अद्यावधिक राख्न प्रयास गर्नेछु!

साथै, मैले अनुगमनसँग सम्बन्धित धेरै ठूला विषयहरू उल्लेख गरेको छैन। भाग 3 मा, म सबैभन्दा लोकप्रिय पूर्वाधार अनुगमन उपकरणहरू र कुन डाटा र मेट्रिक्सलाई विचार गर्ने भनेर हेर्न जाँदैछु।

र अन्तमा। भविष्यमा, म परीक्षण पूर्वाधार र लोकप्रिय उपकरणहरू निर्माण गर्न भिडियो कोर्स जारी गर्ने योजनामा ​​छु। हाल, इन्टरनेटमा DevOps मा धेरै पाठ्यक्रमहरू र व्याख्यानहरू छन्, तर सबै सामग्रीहरू विकासको सन्दर्भमा प्रस्तुत गरिएका छन्, परीक्षण स्वचालन होइन। यस मुद्दामा, मलाई वास्तवमै यस्तो पाठ्यक्रम परीक्षक र स्वचालन इन्जिनियरहरूको समुदायको लागि रोचक र मूल्यवान हुनेछ कि भनेर प्रतिक्रिया चाहिन्छ। अग्रिम धन्यवाद!

स्रोत: www.habr.com