ნაწილი 1: ვებ/ანდროიდი

შენიშვნა: ეს სტატია არის ორიგინალური სტატიის რუსულად თარგმანი ”DevOps ინსტრუმენტები არ არის მხოლოდ DevOps-ისთვის. "სატესტო ავტომატიზაციის ინფრასტრუქტურის აშენება ნულიდან." თუმცა, ყველა ილუსტრაცია, ბმული, ციტატა და ტერმინი დაცულია ორიგინალურ ენაზე, რათა თავიდან იქნას აცილებული მნიშვნელობის დამახინჯება რუსულ ენაზე თარგმნისას. გისურვებთ ბედნიერ სწავლას!

ამჟამად, DevOps სპეციალობა ერთ-ერთი ყველაზე მოთხოვნადია IT ინდუსტრიაში. თუ გახსნით სამუშაოს საძიებო პოპულარულ საიტებს და გაფილტრავთ ხელფასის მიხედვით, ნახავთ, რომ DevOps-თან დაკავშირებული სამუშაოები სიის სათავეშია. თუმცა, მნიშვნელოვანია გვესმოდეს, რომ ეს ძირითადად ეხება „უფროს“ თანამდებობას, რაც გულისხმობს, რომ კანდიდატს აქვს მაღალი დონის უნარები, ტექნოლოგიების ცოდნა და ინსტრუმენტები. ამას ასევე გააჩნია პასუხისმგებლობის მაღალი ხარისხი, რომელიც დაკავშირებულია წარმოების უწყვეტ მუშაობასთან. თუმცა, დავიწყეთ დავიწყება რა არის DevOps. თავდაპირველად ეს არ იყო რაიმე კონკრეტული პიროვნება ან განყოფილება. თუ ამ ტერმინის განმარტებებს ვეძებთ, ვიპოვით ბევრ ლამაზ და სწორ არსებით სახელს, როგორიცაა მეთოდოლოგია, პრაქტიკა, კულტურული ფილოსოფია, ცნებების ჯგუფი და ა.შ.

ჩემი სპეციალიზაცია არის ტესტის ავტომატიზაციის ინჟინერი (QA automation engineer), მაგრამ მიმაჩნია, რომ ეს არ უნდა იყოს დაკავშირებული მხოლოდ ავტომატური ტესტების დაწერასთან ან ტესტის ჩარჩო არქიტექტურის შემუშავებასთან. 2020 წელს ასევე აუცილებელია ავტომატიზაციის ინფრასტრუქტურის ცოდნა. ეს საშუალებას გაძლევთ თავად მოაწყოთ ავტომატიზაციის პროცესი, დაწყებული ტესტებიდან დაწყებული, თქვენი მიზნების შესაბამისად ყველა დაინტერესებული მხარისთვის შედეგების მიწოდებამდე. შედეგად, 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
ვერსიის მართვის სისტემები 
წასვლა

3
კონტეინერიზაცია
Docker, Selenium Grid, Selenoid (ვებ, Android)

4
CI/CD
Gitlab CI

5
Cloud პლატფორმები
Google Cloud პლატფორმა

6
ორკესტრირება
კუბერნეტები

7
ინფრასტრუქტურა, როგორც კოდი (IaC)
Terraform, Ansible

თითოეული განყოფილების სტრუქტურა

თხრობის გასაგებად, თითოეული ნაწილი აღწერილია შემდეგი მონახაზის მიხედვით:

• ტექნოლოგიის მოკლე აღწერა,
• ღირებულება ავტომატიზაციის ინფრასტრუქტურისთვის,
• ინფრასტრუქტურის ამჟამინდელი მდგომარეობის ილუსტრაცია,
• სწავლის ლინკები,
• მსგავსი იარაღები.

1. ჩაატარეთ ტესტები ადგილობრივად

ტექნოლოგიის მოკლე აღწერა

ეს მხოლოდ მოსამზადებელი ნაბიჯია დემო ტესტების ადგილობრივად გასაშვებად და მათი ჩაბარების დასადასტურებლად. პრაქტიკულ ნაწილში გამოიყენება Node.js, მაგრამ პროგრამირების ენა და პლატფორმა ასევე არ არის მნიშვნელოვანი და შეგიძლიათ გამოიყენოთ ის, რაც გამოიყენება თქვენს კომპანიაში. 

თუმცა, როგორც ავტომატიზაციის ხელსაწყოები, გირჩევთ გამოიყენოთ Selenium WebDriver ვებ პლატფორმებისთვის და Appium Android პლატფორმისთვის, რადგან მომდევნო ნაბიჯებში გამოვიყენებთ Docker სურათებს, რომლებიც მორგებულია კონკრეტულად ამ ინსტრუმენტებთან მუშაობისთვის. უფრო მეტიც, სამუშაოს მოთხოვნების გათვალისწინებით, ეს ინსტრუმენტები ყველაზე მოთხოვნადია ბაზარზე.

როგორც თქვენ შენიშნეთ, ჩვენ განვიხილავთ მხოლოდ ვებ და Android ტესტებს. სამწუხაროდ, iOS არის სრულიად განსხვავებული ამბავი (მადლობა Apple). მე ვაპირებ IOS-თან დაკავშირებული გადაწყვეტილებებისა და პრაქტიკის ჩვენებას მომავალ ნაწილებში.

ღირებულება ავტომატიზაციის ინფრასტრუქტურისთვის

ინფრასტრუქტურის თვალსაზრისით, ადგილობრივად გაშვება არ იძლევა რაიმე მნიშვნელობას. თქვენ მხოლოდ ამოწმებთ, რომ ტესტები გადის ადგილობრივ აპარატზე ადგილობრივ ბრაუზერებსა და ტრენაჟორებში. მაგრამ ნებისმიერ შემთხვევაში, ეს არის აუცილებელი ამოსავალი წერტილი.

ინფრასტრუქტურის ამჟამინდელი მდგომარეობის ილუსტრაცია

ბმულები შესასწავლად

• სელენი
• აპიუმი
• Android ემულატორი
• Selenium JS GitHub მაგალითები
• Appium JS GitHub მაგალითები

მსგავსი იარაღები

• ნებისმიერი პროგრამირების ენა, რომელიც მოგწონთ Selenium/Appium ტესტებთან ერთად;
• ნებისმიერი ტესტი;
• ნებისმიერი საცდელი მორბენალი.

2. ვერსიის კონტროლის სისტემები (Git)

ტექნოლოგიის მოკლე აღწერა

არავისთვის არ იქნება დიდი აღმოჩენა, თუ ვიტყვი, რომ ვერსიის კონტროლი განვითარების უაღრესად მნიშვნელოვანი ნაწილია, როგორც გუნდში, ასევე ინდივიდუალურად. სხვადასხვა წყაროზე დაყრდნობით, თამამად შეიძლება ითქვას, რომ Git ყველაზე პოპულარული წარმომადგენელია. ვერსიების კონტროლის სისტემა უზრუნველყოფს ბევრ სარგებელს, როგორიცაა კოდის გაზიარება, ვერსიების შენახვა, წინა ფილიალებში აღდგენა, პროექტის ისტორიის მონიტორინგი და სარეზერვო ასლები. ჩვენ არ განვიხილავთ თითოეულ პუნქტს დეტალურად, რადგან დარწმუნებული ვარ, რომ თქვენ კარგად იცნობთ მას და იყენებთ ყოველდღიურ საქმიანობაში. მაგრამ თუ მოულოდნელად არა, მაშინ გირჩევთ შეაჩეროთ ამ სტატიის კითხვა და რაც შეიძლება მალე შეავსოთ ეს ხარვეზი.

ღირებულება ავტომატიზაციის ინფრასტრუქტურისთვის

და აქ შეგიძლიათ დაუსვათ გონივრული კითხვა: „რატომ გვეუბნება ის Git-ის შესახებ? ყველამ იცის ეს და იყენებს მას როგორც განვითარების კოდისთვის, ასევე ავტომატური ტესტის კოდისთვის. ” აბსოლუტურად მართალი იქნებით, მაგრამ ამ სტატიაში ჩვენ ვსაუბრობთ ინფრასტრუქტურაზე და ეს განყოფილება მოქმედებს როგორც გადახედვა მე-7 განყოფილებისთვის: „ინფრასტრუქტურა, როგორც კოდი (IaC)“. ჩვენთვის ეს ნიშნავს, რომ მთელი ინფრასტრუქტურა, ტესტირების ჩათვლით, აღწერილია კოდის სახით, ასე რომ, ჩვენ შეგვიძლია მასზე გამოვიყენოთ ვერსიების სისტემები და მივიღოთ მსგავსი სარგებელი, როგორც განვითარებისა და ავტომატიზაციის კოდისთვის.

ჩვენ უფრო დეტალურად განვიხილავთ IaC-ს მე-7 ნაბიჯში, მაგრამ ახლაც შეგიძლიათ დაიწყოთ Git-ის გამოყენება ლოკალურად ადგილობრივი საცავის შექმნით. დიდი სურათი გაფართოვდება, როდესაც ინფრასტრუქტურას დავამატებთ დისტანციურ საცავს.

ინფრასტრუქტურის ამჟამინდელი მდგომარეობის ილუსტრაცია

ბმულები შესასწავლად

• რა არის ვერსიის კონტროლი
• წასვლა
• დაწყება - ვერსიის კონტროლის შესახებ

მსგავსი იარაღები

• SVN
• Mercurial 
• Microsoft TFS (ახლა არის Azure DevOps სერვისების ნაწილი)

3. კონტეინერიზაცია (დოკერი)

ტექნოლოგიის მოკლე აღწერა

იმის დემონსტრირებისთვის, თუ როგორ შეცვალა კონტეინერიზაციამ თამაშის წესები, მოდით დავბრუნდეთ რამდენიმე ათეული წლის უკან. მაშინ ადამიანები ყიდულობდნენ და იყენებდნენ სერვერის აპარატებს აპლიკაციების გასაშვებად. მაგრამ უმეტეს შემთხვევაში, საჭირო სტარტაპ რესურსები წინასწარ არ იყო ცნობილი. შედეგად, კომპანიებმა დახარჯეს ფული ძვირადღირებული, ძლიერი სერვერების შესაძენად, მაგრამ ამ სიმძლავრის ნაწილი ბოლომდე არ იქნა გამოყენებული.

ევოლუციის შემდეგი ეტაპი იყო ვირტუალური მანქანები (VM), რომლებმაც გადაჭრეს გამოუყენებელ რესურსებზე ფულის დახარჯვის პრობლემა. ამ ტექნოლოგიამ შესაძლებელი გახადა აპლიკაციების ერთმანეთისგან დამოუკიდებლად გაშვება იმავე სერვერზე, სრულიად იზოლირებული სივრცის გამოყოფით. მაგრამ, სამწუხაროდ, ნებისმიერ ტექნოლოგიას აქვს თავისი ნაკლი. VM-ის გაშვება მოითხოვს სრულ ოპერაციულ სისტემას, რომელიც მოიხმარს CPU-ს, RAM-ს, მეხსიერებას და, OS-დან გამომდინარე, ლიცენზიის ხარჯების გათვალისწინება. ეს ფაქტორები გავლენას ახდენს დატვირთვის სიჩქარეზე და ართულებს პორტატულობას.

ახლა კი მივდივართ კონტეინერიზაციაზე. კიდევ ერთხელ, ეს ტექნოლოგია წყვეტს წინა პრობლემას, რადგან კონტეინერები არ იყენებენ სრულ OS-ს, რაც ათავისუფლებს რესურსების დიდ რაოდენობას და უზრუნველყოფს სწრაფ და მოქნილ გადაწყვეტას პორტაბელურობისთვის.

რა თქმა უნდა, კონტეინერიზაციის ტექნოლოგია ახალი არ არის და პირველად დაინერგა 70-იანი წლების ბოლოს. იმ დღეებში ჩატარდა უამრავი კვლევა, განვითარება და მცდელობა. მაგრამ სწორედ დოკერმა მოახდინა ეს ტექნოლოგია ადაპტირებულმა და ადვილად მისაწვდომი გახადა მასებისთვის. დღესდღეობით, როცა კონტეინერებზე ვსაუბრობთ, უმეტეს შემთხვევაში დოკერს ვგულისხმობთ. როდესაც ვსაუბრობთ Docker კონტეინერებზე, ვგულისხმობთ Linux კონტეინერებს. ჩვენ შეგვიძლია გამოვიყენოთ Windows და macOS სისტემები კონტეინერების გასაშვებად, მაგრამ მნიშვნელოვანია გვესმოდეს, რომ ამ შემთხვევაში ჩნდება დამატებითი ფენა. მაგალითად, Docker Mac-ზე ჩუმად მართავს კონტეინერებს მსუბუქი Linux VM-ის შიგნით. ჩვენ დავუბრუნდებით ამ თემას, როდესაც განვიხილავთ Android ემულატორების გაშვებას კონტეინერებში, ამიტომ აქ არის ძალიან მნიშვნელოვანი ნიუანსი, რომელიც უფრო დეტალურად უნდა იყოს განხილული.

ღირებულება ავტომატიზაციის ინფრასტრუქტურისთვის

გავარკვიეთ, რომ კონტეინერიზაცია და დოკერი მაგარია. მოდით შევხედოთ ამას ავტომატიზაციის კონტექსტში, რადგან ყველა ხელსაწყოს ან ტექნოლოგიას სჭირდება პრობლემის გადაჭრა. მოდით გამოვყოთ ტესტის ავტომატიზაციის აშკარა პრობლემები UI ტესტების კონტექსტში:

• დამოკიდებულების დიდი რაოდენობა სელენის და განსაკუთრებით აპიუმის დაყენებისას;
• თავსებადობის პრობლემები ბრაუზერების, ტრენაჟორების და დრაივერების ვერსიებს შორის;
• ბრაუზერების/სიმულატორებისთვის იზოლირებული სივრცის ნაკლებობა, რაც განსაკუთრებით მნიშვნელოვანია პარალელური მუშაობისთვის;
• რთულია მართვა და შენარჩუნება, თუ საჭიროა 10, 50, 100 ან თუნდაც 1000 ბრაუზერის ერთდროულად გაშვება.

მაგრამ იმის გამო, რომ სელენი არის ყველაზე პოპულარული ავტომატიზაციის ინსტრუმენტი და Docker არის ყველაზე პოპულარული კონტეინერიზაციის ინსტრუმენტი, გასაკვირი არ უნდა იყოს, რომ ვინმემ სცადა მათი გაერთიანება, რათა შექმნას ძლიერი ინსტრუმენტი ზემოთ აღნიშნული პრობლემების გადასაჭრელად. განვიხილოთ ასეთი გადაწყვეტილებები უფრო დეტალურად. 

სელენის ბადე დოკერში

ეს ინსტრუმენტი არის ყველაზე პოპულარული სელენის სამყაროში მრავალი ბრაუზერის გაშვებისთვის მრავალ მოწყობილობაზე და მათ ცენტრალურ ცენტრზე სამართავად. დასაწყებად, თქვენ უნდა დაარეგისტრიროთ მინიმუმ 2 ნაწილი: Hub და Node(s). Hub არის ცენტრალური კვანძი, რომელიც იღებს ყველა მოთხოვნას ტესტებიდან და ანაწილებს მათ შესაბამის კვანძებში. თითოეული კვანძისთვის ჩვენ შეგვიძლია დავაკონფიგურიროთ კონკრეტული კონფიგურაცია, მაგალითად, სასურველი ბრაუზერის და მისი ვერსიის მითითებით. თუმცა, ჩვენ მაინც თავად უნდა ვიზრუნოთ ბრაუზერის თავსებად დრაივერებზე და დავაინსტალიროთ ისინი სასურველ კვანძებზე. ამ მიზეზით, Selenium Grid არ გამოიყენება მისი სუფთა სახით, გარდა იმ შემთხვევებისა, როდესაც ჩვენ გვჭირდება მუშაობა ბრაუზერებთან, რომელთა დაინსტალირება შეუძლებელია Linux OS-ზე. ყველა სხვა შემთხვევისთვის, მნიშვნელოვნად მოქნილი და სწორი გამოსავალი იქნება დოკერის სურათების გამოყენება Selenium Grid Hub-ისა და Nodes-ის გასაშვებად. ეს მიდგომა მნიშვნელოვნად ამარტივებს კვანძების მართვას, რადგან ჩვენ შეგვიძლია შევარჩიოთ ჩვენთვის საჭირო სურათი ბრაუზერების და დრაივერების თავსებადი ვერსიებით უკვე დაინსტალირებული.

სტაბილურობის შესახებ უარყოფითი მიმოხილვების მიუხედავად, განსაკუთრებით დიდი რაოდენობით კვანძების პარალელურად გაშვებისას, სელენის ბადე მაინც ყველაზე პოპულარული ინსტრუმენტია სელენის ტესტების პარალელურად გასაშვებად. მნიშვნელოვანია აღინიშნოს, რომ ამ ხელსაწყოს სხვადასხვა გაუმჯობესება და მოდიფიკაცია მუდმივად ჩნდება ღია წყაროში, რომელიც ებრძვის სხვადასხვა დაბრკოლებებს.

სელენოიდი ვებისთვის

ეს ინსტრუმენტი არის გარღვევა სელენის სამყაროში, რადგან ის მუშაობს პირდაპირ ყუთში და მნიშვნელოვნად გაუადვილა მრავალი ავტომატიზაციის ინჟინრის ცხოვრება. პირველ რიგში, ეს არ არის სელენის ქსელის მორიგი მოდიფიკაცია. ამის ნაცვლად, დეველოპერებმა შექმნეს Selenium Hub-ის სრულიად ახალი ვერსია Golang-ში, რომელიც სხვადასხვა ბრაუზერებისთვის მსუბუქი დოკერის სურათებთან ერთად, სტიმული მისცა ტესტის ავტომატიზაციის განვითარებას. მეტიც, Selenium Grid-ის შემთხვევაში წინასწარ უნდა განვსაზღვროთ ყველა საჭირო ბრაუზერი და მათი ვერსიები, რაც მხოლოდ ერთ ბრაუზერთან მუშაობისას პრობლემას არ წარმოადგენს. მაგრამ როდესაც საქმე ეხება მრავალ მხარდაჭერილ ბრაუზერს, Selenoid არის ნომერ პირველი გამოსავალი მისი "ბრაუზერის მოთხოვნით" ფუნქციის წყალობით. ყველაფერი, რაც ჩვენგან არის საჭირო, არის წინასწარ გადმოვწეროთ საჭირო სურათები ბრაუზერებით და განაახლოთ კონფიგურაციის ფაილი, რომელთანაც Selenoid ურთიერთქმედებს. მას შემდეგ რაც Selenoid მიიღებს მოთხოვნას ტესტებიდან, ის ავტომატურად გაუშვებს სასურველ კონტეინერს სასურველი ბრაუზერით. ტესტის დასრულების შემდეგ, სელენოიდი გაათავისუფლებს კონტეინერს, რითაც გაათავისუფლებს რესურსებს მომავალი მოთხოვნებისთვის. ეს მიდგომა მთლიანად გამორიცხავს "კვანძის დეგრადაციის" ცნობილ პრობლემას, რომელსაც ხშირად ვხვდებით სელენის ქსელში.

მაგრამ, სამწუხაროდ, სელენოიდი ჯერ კიდევ არ არის ვერცხლის ტყვია. ჩვენ მივიღეთ ფუნქცია "ბრაუზერი მოთხოვნით", მაგრამ "რესურსების მოთხოვნით" ფუნქცია ჯერ კიდევ არ არის ხელმისაწვდომი. სელენოიდის გამოსაყენებლად ის უნდა განვათავსოთ ფიზიკურ აპარატურაზე ან VM-ზე, რაც ნიშნავს, რომ წინასწარ უნდა ვიცოდეთ რამდენი რესურსი უნდა გამოყოს. ვფიქრობ, ეს არ არის პრობლემა მცირე პროექტებისთვის, რომლებიც პარალელურად მუშაობენ 10, 20 ან თუნდაც 30 ბრაუზერს. მაგრამ რა მოხდება, თუ ჩვენ გვჭირდება 100, 500, 1000 და მეტი? ამდენი რესურსის მუდმივად შენარჩუნებას და გადახდას აზრი არ აქვს. ამ სტატიის მე-5 და მე-6 სექციებში განვიხილავთ გადაწყვეტილებებს, რომლებიც საშუალებას მოგცემთ გააფართოვოთ და ამით მნიშვნელოვნად შეამციროთ კომპანიის ხარჯები.

სელენოიდი ანდროიდისთვის

სელენოიდის, როგორც ვებ ავტომატიზაციის ხელსაწყოს წარმატების შემდეგ, ხალხს სურდა მსგავსი რამ ანდროიდისთვის. და ეს მოხდა - Selenoid გამოვიდა Android-ის მხარდაჭერით. მაღალი დონის მომხმარებლის თვალსაზრისით, მუშაობის პრინციპი მსგავსია ვებ ავტომატიზაციისა. ერთადერთი განსხვავება ისაა, რომ ბრაუზერის კონტეინერების ნაცვლად, Selenoid აწარმოებს Android ემულატორის კონტეინერებს. ჩემი აზრით, ეს არის ამჟამად ყველაზე ძლიერი უფასო ინსტრუმენტი Android ტესტების პარალელურად გასაშვებად.

მე ნამდვილად არ მინდა ვისაუბრო ამ ხელსაწყოს უარყოფით ასპექტებზე, რადგან ძალიან მომწონს. მაგრამ მაინც არის იგივე უარყოფითი მხარეები, რომლებიც ეხება ვებ ავტომატიზაციას და ასოცირდება სკალირებასთან. გარდა ამისა, ჩვენ უნდა ვისაუბროთ კიდევ ერთ შეზღუდვაზე, რომელიც შეიძლება გასაკვირი იყოს, თუ ინსტრუმენტს პირველად ვაყენებთ. Android-ის სურათების გასაშვებად, ჩვენ გვჭირდება ფიზიკური მანქანა ან VM ჩადგმული ვირტუალიზაციის მხარდაჭერით. სახელმძღვანელოში, მე ვაჩვენებ, თუ როგორ უნდა ჩართოთ ეს Linux VM-ზე. თუმცა, თუ თქვენ ხართ macOS-ის მომხმარებელი და გსურთ Selenoid-ის ადგილობრივად განთავსება, მაშინ ეს შეუძლებელი იქნება Android-ის ტესტების გაშვება. მაგრამ თქვენ ყოველთვის შეგიძლიათ გაუშვათ Linux VM ადგილობრივად, კონფიგურირებული "ბუდებული ვირტუალიზაციის" და შიგნით Selenoid-ის განთავსებით.

ინფრასტრუქტურის ამჟამინდელი მდგომარეობის ილუსტრაცია

ამ სტატიის კონტექსტში ჩვენ დავამატებთ 2 ინსტრუმენტს ინფრასტრუქტურის საილუსტრაციოდ. ეს არის სელენის ბადე ვებ ტესტებისთვის და სელენოიდი ანდროიდის ტესტებისთვის. GitHub-ის სახელმძღვანელოში მე ასევე გაჩვენებთ, თუ როგორ გამოიყენოთ Selenoid ვებ ტესტების გასაშვებად. 

ბმულები შესასწავლად

• დოკერი: რა არის კონტეინერი
• დოკერი: დაიწყე
• 5 კონტეინერის ალტერნატივები დოკერისთვის
• სელენის ბადე
• სელენის დოკერი
• სელენოიდი
• სელენოიდი Github
• KVM დაყენება Android ემულატორებისთვის
• Docker Deep Dive წიგნი

მსგავსი იარაღები

• არსებობს სხვა კონტეინერიზაციის ხელსაწყოები, მაგრამ Docker ყველაზე პოპულარულია. თუ გსურთ სცადოთ რაიმე სხვა, გაითვალისწინეთ, რომ ინსტრუმენტები, რომლებიც ჩვენ გავაშუქეთ სელენის ტესტების პარალელურად გასაშვებად, არ გამოდგება.  
• როგორც უკვე ითქვა, სელენის ქსელის მრავალი მოდიფიკაციაა, მაგალითად, ზალენიუმი.

4.CI/CD

ტექნოლოგიის მოკლე აღწერა

უწყვეტი ინტეგრაციის პრაქტიკა საკმაოდ პოპულარულია განვითარებაში და შეესაბამება ვერსიის კონტროლის სისტემებს. ამის მიუხედავად, ვგრძნობ, რომ ტერმინოლოგიაში დაბნეულობაა. ამ პარაგრაფში მინდა აღვწერო ამ ტექნოლოგიის 3 მოდიფიკაცია ჩემი გადმოსახედიდან. ინტერნეტში ნახავთ ბევრ სტატიას სხვადასხვა ინტერპრეტაციით და აბსოლუტურად ნორმალურია, თუ თქვენი აზრი განსხვავებულია. ყველაზე მნიშვნელოვანი ის არის, რომ კოლეგებთან ერთად ხართ.

ასე რომ, არსებობს 3 ტერმინი: CI - უწყვეტი ინტეგრაცია, CD - უწყვეტი მიწოდება და ისევ CD - უწყვეტი განლაგება. (ქვემოთ გამოვიყენებ ამ ტერმინებს ინგლისურად). თითოეული მოდიფიკაცია ამატებს რამდენიმე დამატებით ნაბიჯს თქვენი განვითარების მილსადენს. მაგრამ სიტყვა უწყვეტი (უწყვეტი) ყველაზე მთავარია. ამ კონტექსტში, ჩვენ ვგულისხმობთ იმას, რაც ხდება თავიდან ბოლომდე, შეფერხების ან ხელით ჩარევის გარეშე. მოდით შევხედოთ CI & CD და CD ამ კონტექსტში.

• უწყვეტი ინტეგრაცია ეს არის ევოლუციის საწყისი ეტაპი. სერვერზე ახალი კოდის გაგზავნის შემდეგ, ჩვენ ველით, რომ მივიღებთ სწრაფ გამოხმაურებას, რომ ჩვენი ცვლილებები წესრიგშია. როგორც წესი, CI მოიცავს სტატიკური კოდის ანალიზის ხელსაწყოების გაშვებას და ერთეულის/შიდა API ტესტებს. ეს საშუალებას გვაძლევს მივიღოთ ინფორმაცია ჩვენი კოდის შესახებ რამდენიმე წამში/წუთში.
• უწყვეტი მიწოდების არის უფრო მოწინავე ნაბიჯი, სადაც ჩვენ ვაწარმოებთ ინტეგრაციის/UI ტესტებს. თუმცა, ამ ეტაპზე ჩვენ არ ვიღებთ შედეგს ისე სწრაფად, როგორც CI-ით. პირველ რიგში, ამ ტიპის ტესტებს უფრო მეტი დრო სჭირდება. მეორეც, გაშვებამდე, ჩვენ უნდა განვათავსოთ ჩვენი ცვლილებები ტესტის/დადგმის გარემოში. უფრო მეტიც, თუ ჩვენ ვსაუბრობთ მობილურის განვითარებაზე, მაშინ ჩნდება დამატებითი ნაბიჯი ჩვენი აპლიკაციის კონსტრუქციის შესაქმნელად.
• უწყვეტი განლაგება ვარაუდობს, რომ ჩვენ ავტომატურად გავათავისუფლებთ ჩვენს ცვლილებებს წარმოებაში, თუ ყველა მისაღები ტესტი ჩაბარებულია წინა ეტაპებზე. გარდა ამისა, გამოშვების ეტაპის შემდეგ, შეგიძლიათ დააკონფიგურიროთ სხვადასხვა ეტაპები, როგორიცაა კვამლის ტესტების გაშვება წარმოებაზე და ინტერესის მეტრიკის შეგროვება. უწყვეტი განლაგება შესაძლებელია მხოლოდ კარგი დაფარვით ავტომატური ტესტებით. თუ საჭიროა რაიმე ხელით ჩარევა, მათ შორის ტესტირება, მაშინ ეს აღარ არის უწყვეტი (უწყვეტი). მაშინ შეგვიძლია ვთქვათ, რომ ჩვენი მილსადენი შეესაბამება მხოლოდ უწყვეტი მიწოდების პრაქტიკას.

ღირებულება ავტომატიზაციის ინფრასტრუქტურისთვის

ამ განყოფილებაში უნდა განვმარტო, რომ როდესაც ვსაუბრობთ ბოლომდე UI ტესტებზე, ეს ნიშნავს, რომ ჩვენ უნდა გავავრცელოთ ჩვენი ცვლილებები და მასთან დაკავშირებული სერვისები სატესტო გარემოში. უწყვეტი ინტეგრაცია - პროცესი არ გამოიყენება ამ ამოცანისთვის და ჩვენ უნდა ვიზრუნოთ მინიმუმ უწყვეტი მიწოდების პრაქტიკის განხორციელებაზე. Continuous Deployment ასევე აზრი აქვს UI ტესტების კონტექსტში, თუ ჩვენ ვაპირებთ მათ წარმოებაში გაშვებას.

და სანამ გადავხედავთ არქიტექტურის ცვლილების ილუსტრაციას, მინდა გითხრათ რამდენიმე სიტყვა GitLab CI-ის შესახებ. სხვა CI/CD ინსტრუმენტებისგან განსხვავებით, GitLab უზრუნველყოფს დისტანციურ საცავს და ბევრ სხვა დამატებით ფუნქციას. ამრიგად, GitLab მეტია ვიდრე CI. მასში შედის კოდის მენეჯმენტი, Agile მენეჯმენტი, CI/CD მილსადენები, ხე-ტყის ინსტრუმენტები და მეტრიკის შეგროვება ყუთიდან. GitLab არქიტექტურა შედგება Gitlab CI/CD და GitLab Runner-ისგან. აქ არის მოკლე აღწერა ოფიციალური საიტიდან:

Gitlab CI/CD არის ვებ აპლიკაცია API-ით, რომელიც ინახავს მის მდგომარეობას მონაცემთა ბაზაში, მართავს პროექტებს/ნაგებობებს და უზრუნველყოფს მომხმარებლის ინტერფეისს. GitLab Runner არის აპლიკაცია, რომელიც ამუშავებს შენობებს. ის შეიძლება განთავსდეს ცალკე და მუშაობს GitLab CI/CD-თან API-ის მეშვეობით. გაშვებული ტესტებისთვის გჭირდებათ როგორც Gitlab ინსტანცია, ასევე Runner.

ინფრასტრუქტურის ამჟამინდელი მდგომარეობის ილუსტრაცია

ბმულები შესასწავლად

• მარტინ ფაულერი: უწყვეტი ინტეგრაცია
• Gitlab CI/CD
• უწყვეტი ინტეგრაციის წიგნი
• უწყვეტი მიწოდების წიგნი

მსგავსი იარაღები

• Jenkins
• TeamCity
• Travis 
• Და მრავალი სხვა

5. ღრუბლოვანი პლატფორმები

ტექნოლოგიის მოკლე აღწერა

ამ განყოფილებაში ვისაუბრებთ პოპულარულ ტენდენციაზე, სახელწოდებით "საჯარო ღრუბლები". მიუხედავად იმ უზარმაზარი სარგებლისა, რასაც ზემოთ აღწერილი ვირტუალიზაციისა და კონტეინერიზაციის ტექნოლოგიები გვაძლევს, ჩვენ მაინც გვჭირდება გამოთვლითი რესურსები. კომპანიები ყიდულობენ ძვირადღირებულ სერვერებს ან ქირაობენ მონაცემთა ცენტრებს, მაგრამ ამ შემთხვევაში აუცილებელია გამოთვლები (ზოგჯერ არარეალურია), თუ რამდენი რესურსი დაგვჭირდება, გამოვიყენებთ თუ არა მათ 24/7 და რა მიზნებისთვის. მაგალითად, წარმოებას სჭირდება სერვერი, რომელიც მუშაობს XNUMX/XNUMX, მაგრამ გვჭირდება თუ არა მსგავსი რესურსები სამუშაო საათების მიღმა ტესტირებისთვის? ეს ასევე დამოკიდებულია შესრულებული ტესტირების ტიპზე. ამის მაგალითი იქნება დატვირთვა/სტრეს ტესტები, რომელთა ჩატარებასაც ვგეგმავთ არასამუშაო საათებში, რათა მივიღოთ შედეგი მეორე დღეს. მაგრამ, რა თქმა უნდა, XNUMX/XNUMX სერვერის ხელმისაწვდომობა არ არის საჭირო ბოლომდე ავტომატური ტესტებისთვის და განსაკუთრებით არ არის ხელით ტესტირების გარემოში. ასეთი სიტუაციებისთვის კარგი იქნება მოთხოვნისამებრ მოიპოვოთ იმდენი რესურსი, რამდენიც საჭიროა, გამოიყენოთ ისინი და შეწყვიტოთ გადახდა, როცა აღარ დაგჭირდებათ. უფრო მეტიც, კარგი იქნება მათი მყისიერად მიღება მაუსის რამდენიმე დაწკაპუნებით ან რამდენიმე სკრიპტის გაშვებით. ეს არის ის, რისთვისაც გამოიყენება საჯარო ღრუბლები. მოდით შევხედოთ განმარტებას:

„საჯარო ღრუბელი განისაზღვრება, როგორც გამოთვლითი სერვისები, რომლებსაც სთავაზობენ მესამე მხარის პროვაიდერები საჯარო ინტერნეტის საშუალებით, რაც მათ ხელმისაწვდომს ხდის ყველასთვის, ვისაც სურს მათი გამოყენება ან შეძენა. ისინი შეიძლება იყოს უფასო ან გაიყიდოს მოთხოვნით, რაც მომხმარებელს საშუალებას აძლევს გადაიხადონ მხოლოდ CPU ციკლების, შენახვის ან გამტარუნარიანობისთვის, რომლებიც მოიხმარენ. ”

არსებობს მოსაზრება, რომ საზოგადოებრივი ღრუბლები ძვირია. მაგრამ მათი მთავარი იდეა არის კომპანიის ხარჯების შემცირება. როგორც უკვე აღვნიშნეთ, საჯარო ღრუბლები საშუალებას გაძლევთ მიიღოთ რესურსები მოთხოვნით და გადაიხადოთ მხოლოდ მათი გამოყენების დრო. ასევე, ხანდახან გვავიწყდება, რომ თანამშრომლები ხელფასს იღებენ და სპეციალისტებიც ძვირი რესურსია. გასათვალისწინებელია, რომ საჯარო ღრუბლები ბევრად აადვილებენ ინფრასტრუქტურის მხარდაჭერას, რაც ინჟინრებს საშუალებას აძლევს ფოკუსირება მოახდინონ უფრო მნიშვნელოვან ამოცანებზე. 

ღირებულება ავტომატიზაციის ინფრასტრუქტურისთვის

რა სპეციფიური რესურსები გვჭირდება ბოლოდან ბოლომდე UI ტესტებისთვის? ძირითადად ეს არის ვირტუალური მანქანები ან კლასტერები (Kubernetes-ზე ვისაუბრებთ შემდეგ ნაწილში) ბრაუზერებისა და ემულატორების გასაშვებად. რაც უფრო მეტი ბრაუზერის და ემულატორის ერთდროულად გაშვება გვსურს, მით მეტი CPU და მეხსიერებაა საჭირო და მეტი ფული უნდა გადავიხადოთ მასში. ამგვარად, საჯარო ღრუბლები ტესტის ავტომატიზაციის კონტექსტში საშუალებას გვაძლევს გავუშვათ ბრაუზერების/ემულატორების დიდი რაოდენობა (100, 200, 1000...) მოთხოვნისამებრ, მივიღოთ ტესტის შედეგები რაც შეიძლება სწრაფად და შევწყვიტოთ ფულის გადახდა ასეთი გიჟური რესურსებით ინტენსიურად. ძალა. 

ღრუბლოვანი ყველაზე პოპულარული პროვაიდერებია Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). სახელმძღვანელოში მოცემულია მაგალითები, თუ როგორ გამოიყენოთ GCP, მაგრამ ზოგადად არ აქვს მნიშვნელობა რას იყენებთ ავტომატიზაციის ამოცანებისთვის. ყველა მათგანს აქვს დაახლოებით იგივე ფუნქციონირება. როგორც წესი, პროვაიდერის შესარჩევად მენეჯმენტი ფოკუსირებულია კომპანიის მთელ ინფრასტრუქტურაზე და ბიზნეს მოთხოვნებზე, რაც სცილდება ამ სტატიის ფარგლებს. ავტომატიზაციის ინჟინრებისთვის უფრო საინტერესო იქნება ღრუბლოვანი პროვაიდერების გამოყენების შედარება ღრუბლოვანი პლატფორმების გამოყენებასთან სპეციალურად ტესტირების მიზნებისთვის, როგორიცაა Sauce Labs, BrowserStack, BitBar და ა.შ. ასე რომ, ჩვენც გავაკეთოთ! ჩემი აზრით, Sauce Labs არის ყველაზე ცნობილი ღრუბლოვანი ტესტირების ფერმა, რის გამოც გამოვიყენე იგი შედარებისთვის. 

GCP vs Sauce Labs ავტომატიზაციის მიზნებისთვის:

წარმოვიდგინოთ, რომ ჩვენ გვჭირდება 8 ვებ ტესტის და 8 Android ტესტის ერთდროულად გაშვება. ამისთვის გამოვიყენებთ GCP-ს და გავუშვით 2 ვირტუალური მანქანა Selenoid-ით. პირველზე ავწევთ 8 კონტეინერს ბრაუზერებით. მეორეზე არის 8 კონტეინერი ემულატორებით. მოდით შევხედოთ ფასებს:  

Chrome-ით ერთი კონტეინერის გასაშვებად გვჭირდება n1-სტანდარტი-1 მანქანა. ანდროიდის შემთხვევაში ასე იქნება n1-სტანდარტი-4 ერთი ემულატორისთვის. სინამდვილეში, უფრო მოქნილი და იაფი გზაა CPU/მეხსიერებისთვის კონკრეტული მომხმარებლის მნიშვნელობების დაყენება, მაგრამ ამ დროისთვის ეს არ არის მნიშვნელოვანი Sauce Labs-თან შესადარებლად.

და აქ არის ტარიფები Sauce Labs-ის გამოყენებისთვის:

მე მჯერა, რომ თქვენ უკვე შენიშნეთ განსხვავება, მაგრამ მე მაინც შემოგთავაზებთ ცხრილს ჩვენი დავალების გამოთვლებით:

საჭირო რესურსები
ყოველთვიურად
სამუშაო საათები(8 საათიდან საღამოს 8 საათამდე)
სამუშაო საათები+ წინასწარი შეზღუდვა

GCP ვებისთვის
n1-სტანდარტული-1 x 8 = n1-სტანდარტული-8
$194.18
23 დღე * 12 სთ * 0.38 = 104.88 $ 
23 დღე * 12 სთ * 0.08 = 22.08 $

სოუსის ლაბორატორიები ვებისთვის
ვირტუალური Cloud8 პარალელური ტესტები
$1.559
-
-

GCP Android-ისთვის
n1-სტანდარტული-4 x 8: n1-სტანდარტული-16
$776.72
23 დღე * 12 სთ * 1.52 = 419.52 $ 
23 დღე * 12 სთ * 0.32 = 88.32 $

Sauce Labs Android-ისთვის
Real Device Cloud 8 პარალელური ტესტები
$1.999
-
-

როგორც ხედავთ, ღირებულების სხვაობა უზარმაზარია, განსაკუთრებით იმ შემთხვევაში, თუ ტესტებს ატარებთ მხოლოდ თორმეტსაათიანი სამუშაო პერიოდის განმავლობაში. მაგრამ თქვენ შეგიძლიათ კიდევ უფრო შეამციროთ ხარჯები, თუ იყენებთ წინასწარ დაშვებულ მანქანებს. Რა არის ეს?

Preemptible VM არის მაგალითი, რომლის შექმნა და გაშვება შეგიძლიათ ბევრად უფრო დიდ ფასად, ვიდრე ჩვეულებრივი შემთხვევები. თუმცა, Compute Engine-მა შეიძლება შეწყვიტოს (წინასწარი) ეს შემთხვევები, თუ საჭიროებს ამ რესურსებზე წვდომას სხვა ამოცანებისთვის. წინასწარი შეზღუდვის შემთხვევები არის Compute Engine-ის ჭარბი სიმძლავრე, ამიტომ მათი ხელმისაწვდომობა განსხვავდება გამოყენების მიხედვით.

თუ თქვენი აპლიკაციები შეცდომისადმი ტოლერანტულია და გაუძლებს მაგალითების შესაძლო პრევენციას, მაშინ წინასწარი შეზღუდვის შემთხვევები შეიძლება მნიშვნელოვნად შეამცირონ თქვენი გამოთვლითი ძრავის ხარჯები. მაგალითად, სერიული დამუშავების სამუშაოები შეიძლება გაუშვათ წინასწარ განხორციელებულ შემთხვევებზე. თუ ამ შემთხვევებიდან ზოგიერთი წყდება დამუშავების დროს, სამუშაო შენელდება, მაგრამ მთლიანად არ ჩერდება. წინასწარი შეზღუდვის შემთხვევები ასრულებენ თქვენს სერიული დამუშავების ამოცანებს თქვენს არსებულ ინსტანციებზე დამატებითი დატვირთვის გარეშე და დამატებითი ნორმალური ინსტანციებისთვის სრული ფასის გადახდის გარეშე.

და მაინც არ დასრულებულა! სინამდვილეში, დარწმუნებული ვარ, არავინ ატარებს ტესტებს 12 საათის განმავლობაში შესვენების გარეშე. და თუ ასეა, მაშინ შეგიძლიათ ავტომატურად გაუშვათ და შეაჩეროთ ვირტუალური მანქანები, როდესაც ისინი საჭირო არ არის. ფაქტობრივი გამოყენების დრო შეიძლება შემცირდეს 6 საათამდე დღეში. მაშინ გადახდა ჩვენი ამოცანის კონტექსტში შემცირდება 11 დოლარამდე თვეში 8 ბრაუზერისთვის. ეს მშვენიერი არ არის? მაგრამ პრევენციული მანქანებით ჩვენ უნდა ვიყოთ ფრთხილად და მომზადებული შეფერხებებისა და არასტაბილურობისთვის, თუმცა ეს სიტუაციები შეიძლება უზრუნველყოფილი იყოს და დამუშავდეს პროგრამული უზრუნველყოფის საშუალებით. Ღირს!

მაგრამ არავითარ შემთხვევაში არ ვამბობ "არასოდეს გამოიყენო ღრუბლოვანი სატესტო ფერმები". მათ აქვთ მთელი რიგი უპირატესობები. უპირველეს ყოვლისა, ეს არ არის მხოლოდ ვირტუალური მანქანა, არამედ სრულფასოვანი სატესტო ავტომატიზაციის გადაწყვეტა ფუნქციონალობის კომპლექტით: დისტანციური წვდომა, ჟურნალები, ეკრანის ანაბეჭდები, ვიდეო ჩაწერა, სხვადასხვა ბრაუზერები და ფიზიკური მობილური მოწყობილობები. ბევრ სიტუაციაში, ეს შეიძლება იყოს აუცილებელი ელეგანტური ალტერნატივა. ტესტირების პლატფორმები განსაკუთრებით სასარგებლოა IOS ავტომატიზაციისთვის, როდესაც საჯარო ღრუბლებს შეუძლიათ მხოლოდ Linux/Windows სისტემების შეთავაზება. მაგრამ iOS-ზე ვისაუბრებთ შემდეგ სტატიებში. გირჩევთ, ყოველთვის შეხედოთ სიტუაციას და დაიწყოთ ამოცანებიდან: ზოგიერთ შემთხვევაში უფრო იაფი და ეფექტურია საჯარო ღრუბლების გამოყენება, ზოგში კი სატესტო პლატფორმები ნამდვილად ღირს დახარჯული ფული.

ინფრასტრუქტურის ამჟამინდელი მდგომარეობის ილუსტრაცია

ბმულები შესასწავლად

• სწორი კლინიკური პრაქტიკის
• GCP: წინასწარი შეზღუდვა
• GCP: VM ფასი
• SauceLabs
• ღრუბლოვანი პროვაიდერების შედარება

მსგავსი ინსტრუმენტები:

• AWS 
• Azure

6. ორკესტრირება

ტექნოლოგიის მოკლე აღწერა

კარგი ამბავი მაქვს - ჩვენ თითქმის სტატიის ბოლოს ვართ! ამ დროისთვის, ჩვენი ავტომატიზაციის ინფრასტრუქტურა შედგება ვებსა და ანდროიდის ტესტებისგან, რომლებსაც პარალელურად ვაწარმოებთ GitLab CI-ის მეშვეობით, Docker-ზე ჩართული ინსტრუმენტების გამოყენებით: Selenium grid და Selenoid. უფრო მეტიც, ჩვენ ვიყენებთ GCP-ის საშუალებით შექმნილ ვირტუალურ მანქანებს ბრაუზერებისა და ემულატორების კონტეინერების განსათავსებლად. ხარჯების შესამცირებლად, ჩვენ ვიწყებთ ამ ვირტუალურ მანქანებს მხოლოდ მოთხოვნით და ვაჩერებთ მათ, როდესაც ტესტირება არ განხორციელდება. არის კიდევ რამე, რაც ჩვენს ინფრასტრუქტურას გააუმჯობესებს? პასუხი არის დიახ! გაიცანით Kubernetes (K8s)!

ჯერ ვნახოთ, როგორ უკავშირდება ერთმანეთს სიტყვები ორკესტრი, კლასტერი და კუბერნეტები. მაღალ დონეზე, ორკესტრირება არის სისტემა, რომელიც განათავსებს და მართავს აპლიკაციებს. სატესტო ავტომატიზაციისთვის, ასეთი კონტეინერირებული აპლიკაციებია სელენის ბადე და სელენოიდი. Docker და K8 ავსებენ ერთმანეთს. პირველი გამოიყენება აპლიკაციის განსათავსებლად, მეორე ორკესტრირებისთვის. თავის მხრივ, K8s არის კლასტერი. კლასტერის ამოცანაა ვირტუალური მეხსიერების კვანძების სახით გამოყენება, რაც საშუალებას გაძლევთ დააინსტალიროთ სხვადასხვა ფუნქციები, პროგრამები და სერვისები ერთ სერვერზე (კლასტერში). თუ რომელიმე კვანძი ვერ მოხერხდა, სხვა კვანძები აიღებენ, რაც უზრუნველყოფს ჩვენი აპლიკაციის შეუფერხებელ მუშაობას. გარდა ამისა, K8-ს აქვს სკალირებასთან დაკავშირებული მნიშვნელოვანი ფუნქციონირება, რომლის წყალობითაც ჩვენ ავტომატურად ვიღებთ რესურსების ოპტიმალურ რაოდენობას დატვირთვის საფუძველზე და ვაყენებთ ლიმიტებს.

სინამდვილეში, Kubernetes-ის ხელით განლაგება ნულიდან სულაც არ არის ტრივიალური ამოცანა. მე დავტოვებ ბმულს ცნობილ სახელმძღვანელოს "Kubernetes The Hard Way"-ს და თუ დაგაინტერესებთ, შეგიძლიათ ივარჯიშოთ. მაგრამ, საბედნიეროდ, არსებობს ალტერნატიული მეთოდები და ინსტრუმენტები. უმარტივესი გზაა Google Kubernetes Engine-ის (GKE) გამოყენება GCP-ში, რაც საშუალებას მოგცემთ მიიღოთ მზა კლასტერი რამდენიმე დაწკაპუნებით. მე გირჩევთ გამოიყენოთ ეს მიდგომა სწავლის დასაწყებად, რადგან ის საშუალებას მოგცემთ ფოკუსირება მოახდინოთ იმაზე, თუ როგორ გამოიყენოთ K8 თქვენი ამოცანებისთვის, იმის ნაცვლად, რომ ისწავლოთ, თუ როგორ უნდა იყოს ინტეგრირებული შიდა კომპონენტები ერთმანეთთან. 

ღირებულება ავტომატიზაციის ინფრასტრუქტურისთვის

მოდით შევხედოთ რამდენიმე მნიშვნელოვან მახასიათებელს, რომელსაც K8s უზრუნველყოფს:

• აპლიკაციის განლაგება: VM-ების ნაცვლად მრავალ კვანძის კლასტერის გამოყენება;
• დინამიური მასშტაბირება: ამცირებს რესურსების ღირებულებას, რომლებიც გამოიყენება მხოლოდ მოთხოვნით;
• თვითგანკურნება: წიპწების ავტომატური აღდგენა (რის შედეგადაც ხდება კონტეინერების აღდგენა);
• განახლებების გავრცელება და ცვლილებების დაბრუნება შეფერხების გარეშე: ხელსაწყოების, ბრაუზერებისა და ემულატორების განახლება არ აფერხებს მიმდინარე მომხმარებლების მუშაობას

მაგრამ K8s მაინც არ არის ვერცხლის ტყვია. იმისათვის, რომ გავიგოთ ყველა უპირატესობა და შეზღუდვა იმ ხელსაწყოების კონტექსტში, რომლებსაც განვიხილავთ (სელენიუმის ბადე, სელენოიდი), მოკლედ განვიხილავთ K8-ების სტრუქტურას. კლასტერი შეიცავს კვანძების ორ ტიპს: Master Nodes და Workers Nodes. სამაგისტრო კვანძები პასუხისმგებელნი არიან მენეჯმენტზე, განლაგების და დაგეგმვის გადაწყვეტილებებზე. მუშათა კვანძები არის აპლიკაციების გაშვება. კვანძები ასევე შეიცავს კონტეინერის გაშვების გარემოს. ჩვენს შემთხვევაში, ეს არის Docker, რომელიც პასუხისმგებელია კონტეინერებთან დაკავშირებულ ოპერაციებზე. მაგრამ ასევე არსებობს ალტერნატიული გადაწყვეტილებები, მაგალითად კონტეინერი. მნიშვნელოვანია გვესმოდეს, რომ სკალირება ან თვითგანკურნება უშუალოდ კონტეინერებზე არ ვრცელდება. ეს კეთდება ტოტების რაოდენობის დამატებით/შემცირებით, რომლებიც, თავის მხრივ, შეიცავს კონტეინერებს (ჩვეულებრივ თითო კონტეინერი, მაგრამ დავალების მიხედვით შეიძლება იყოს მეტი). მაღალი დონის იერარქია შედგება მუშათა კვანძებისგან, რომელთა შიგნით არის ძაფები, რომელთა შიგნით აწეულია კონტეინერები.

სკალირების ფუნქცია საკვანძოა და შეიძლება გამოყენებულ იქნას ორივე კვანძზე კლასტერული კვანძის აუზში და კვანძებში კვანძში. არსებობს სკალირების 2 ტიპი, რომელიც ვრცელდება როგორც კვანძებზე, ასევე კვანძებზე. პირველი ტიპი ჰორიზონტალურია - სკალირება ხდება კვანძების/პოდების რაოდენობის გაზრდით. ეს ტიპი უფრო სასურველია. მეორე ტიპი, შესაბამისად, ვერტიკალურია. სკალირება ხორციელდება კვანძების/პოდების ზომის გაზრდით და არა მათი რაოდენობის.

ახლა მოდით შევხედოთ ჩვენს ინსტრუმენტებს ზემოაღნიშნული ტერმინების კონტექსტში.

სელენის ბადე

როგორც უკვე აღვნიშნეთ, სელენის ბადე არის ძალიან პოპულარული ინსტრუმენტი და გასაკვირი არ არის, რომ ის კონტეინერშია. ამიტომ, გასაკვირი არ არის, რომ სელენის ბადე შეიძლება განთავსდეს K8-ებში. მაგალითი იმისა, თუ როგორ უნდა გავაკეთოთ ეს, შეგიძლიათ იხილოთ ოფიციალურ K8s საცავში. როგორც ყოველთვის, მე ვამაგრებ ბმულებს განყოფილების ბოლოს. გარდა ამისა, გზამკვლევი გვიჩვენებს, თუ როგორ უნდა გავაკეთოთ ეს Terraform-ში. ასევე არსებობს ინსტრუქციები იმის შესახებ, თუ როგორ უნდა მოხდეს პოდების რაოდენობის მასშტაბირება, რომლებიც შეიცავს ბრაუზერის კონტეინერებს. მაგრამ ავტომატური სკალირების ფუნქცია K8s-ის კონტექსტში ჯერ კიდევ არ არის სრულიად აშკარა ამოცანა. როცა სწავლა დავიწყე, ვერ ვიპოვე პრაქტიკული სახელმძღვანელო და რეკომენდაცია. რამდენიმე კვლევისა და ექსპერიმენტის შემდეგ DevOps-ის გუნდის მხარდაჭერით, ჩვენ ავირჩიეთ კონტეინერების ამაღლების მიდგომა საჭირო ბრაუზერებით ერთ პოდში, რომელიც მდებარეობს ერთი მუშა კვანძში. ეს მეთოდი საშუალებას გვაძლევს გამოვიყენოთ კვანძების ჰორიზონტალური მასშტაბირების სტრატეგია მათი რაოდენობის გაზრდით. იმედი მაქვს, რომ ეს შეიცვლება მომავალში და ჩვენ ვიხილავთ უფრო და უფრო მეტ აღწერას უკეთესი მიდგომებისა და მზა გადაწყვეტილებების შესახებ, განსაკუთრებით სელენის ბადე 4-ის გამოშვების შემდეგ, შეცვლილი შიდა არქიტექტურით.

სელენოიდი:

სელენოიდის განლაგება K8-ში ამჟამად ყველაზე დიდი იმედგაცრუებაა. ისინი არ არიან თავსებადი. თეორიულად, ჩვენ შეგვიძლია ავწიოთ სელენოიდის კონტეინერი პოდში, მაგრამ როდესაც Selenoid დაიწყებს კონტეინერების გაშვებას ბრაუზერებით, ისინი კვლავ იქნებიან იმავე პოდში. ეს შეუძლებელს ხდის სკალირებას და, შედეგად, სელენოიდის მუშაობა კლასტერის შიგნით არ განსხვავდება ვირტუალური მანქანის შიგნით მუშაობისგან. Ამბის დასასრული.

მთვარე:

იცოდნენ ამ შეფერხების შესახებ Selenoid-თან მუშაობისას, დეველოპერებმა გამოუშვეს უფრო ძლიერი ინსტრუმენტი სახელწოდებით Moon. ეს ინსტრუმენტი თავდაპირველად შეიქმნა Kubernetes-თან მუშაობისთვის და, შედეგად, ავტოსკალირების ფუნქცია შეიძლება და უნდა იქნას გამოყენებული. უფრო მეტიც, მე ვიტყოდი, რომ ამ მომენტში არის ერთი ინსტრუმენტი სელენის სამყაროში, რომელსაც აქვს K8s კლასტერის მხარდაჭერა ყუთიდან (აღარ არის ხელმისაწვდომი, იხილეთ შემდეგი ინსტრუმენტი ). მთვარის ძირითადი მახასიათებლები, რომლებიც უზრუნველყოფენ ამ მხარდაჭერას, არის: 

სრულიად მოქალაქეობის არმქონე. სელენოიდი მეხსიერებაში ინახავს ინფორმაციას ბრაუზერის მიმდინარე სესიების შესახებ. თუ რაიმე მიზეზით მისი პროცესი ჩაიშლება - მაშინ ყველა გაშვებული სესია იკარგება. მთვარეს პირიქით არ აქვს შიდა მდგომარეობა და მისი გამეორება შესაძლებელია მონაცემთა ცენტრებში. ბრაუზერის სესიები რჩება ცოცხალი მაშინაც კი, თუ ერთი ან მეტი ასლი გაქრება.

ასე რომ, მთვარე შესანიშნავი გამოსავალია, მაგრამ არის ერთი პრობლემა: ის არ არის უფასო. ფასი დამოკიდებულია სესიების რაოდენობაზე. თქვენ შეგიძლიათ მხოლოდ 0-4 სესიის ჩატარება უფასოდ, რაც განსაკუთრებით არ არის სასარგებლო. მაგრამ, მეხუთე სესიიდან დაწყებული, თითოეულში 5 დოლარის გადახდა მოგიწევთ. სიტუაცია შეიძლება განსხვავდებოდეს კომპანიებიდან კომპანიაში, მაგრამ ჩვენს შემთხვევაში მთვარის გამოყენება უაზროა. როგორც ზემოთ აღვწერე, ჩვენ შეგვიძლია გავუშვათ ვირტუალური მანქანები Selenium Grid-ით მოთხოვნით ან გავზარდოთ კვანძების რაოდენობა კლასტერში. დაახლოებით ერთი მილსადენისთვის ჩვენ გავუშვით 500 ბრაუზერი და ყველა რესურსს ვაჩერებთ ტესტების დასრულების შემდეგ. თუ გამოვიყენებდით Moon-ს, თვეში დამატებითი 500 x 5 = 2500 დოლარის გადახდა მოგვიწევდა, რაც არ უნდა ხშირად ჩავატაროთ ტესტები. კიდევ ერთხელ, მე არ ვამბობ, რომ არ გამოიყენოთ Moon. თქვენი ამოცანების შესასრულებლად, ეს შეიძლება იყოს შეუცვლელი გადაწყვეტა, მაგალითად, თუ თქვენ გაქვთ ბევრი პროექტი/გუნდი თქვენს ორგანიზაციაში და გჭირდებათ უზარმაზარი საერთო კლასტერი ყველასთვის. როგორც ყოველთვის, ბოლოს ვტოვებ ბმულს და გირჩევთ, გააკეთოთ ყველა საჭირო გამოთვლა თქვენი ამოცანის კონტექსტში.

Callisto: (ყურადღება! ეს არ არის ორიგინალ სტატიაში და შეიცავს მხოლოდ რუსულ თარგმანში)

როგორც ვთქვი, სელენი არის ძალიან პოპულარული ინსტრუმენტი და IT სფერო ძალიან სწრაფად ვითარდება. სანამ თარგმანზე ვმუშაობდი, ინტერნეტში გამოჩნდა ახალი პერსპექტიული ინსტრუმენტი სახელად Callisto (გამარჯობა კვიპაროსი და სელენის სხვა მკვლელები). ის მუშაობს მშობლიურად K8-ებთან და საშუალებას გაძლევთ გაუშვათ სელენოიდის კონტეინერები კვანძებში, განაწილებული კვანძებში. ყველაფერი მუშაობს ყუთიდან, მათ შორის ავტოსკალირება. ფანტასტიკურია, მაგრამ შესამოწმებელია. მე უკვე მოვახერხე ამ ხელსაწყოს დანერგვა და რამდენიმე ექსპერიმენტის ჩატარება. მაგრამ ჯერ ნაადრევია დასკვნების გამოტანა, შედეგების შორ მანძილზე მიღების შემდეგ, ალბათ, მომავალ სტატიებში გავაკეთებ მიმოხილვას. ამ დროისთვის მე ვტოვებ მხოლოდ ბმულებს დამოუკიდებელი კვლევისთვის.  

ინფრასტრუქტურის ამჟამინდელი მდგომარეობის ილუსტრაცია

ბმულები შესასწავლად

• Kubernetes: დაყენება
• Kubernetes: რთული გზა
• კუბერნეტები: სელენი
• GCP: Kubernetes ძრავა
• მთვარე
• კუბერნეტის წიგნი
• განაწილებული ავტომატიზაცია Kubernetes-ის გამოყენებით
• სელენის ბადე 4
• Callisto GitHub
• Wrike TechClub (Callisto)

მსგავსი იარაღები

• დოკერის ხროვა 
• მარათონი 

7. ინფრასტრუქტურა როგორც კოდი (IaC)

ტექნოლოგიის მოკლე აღწერა

ახლა კი მივედით ბოლო განყოფილებამდე. როგორც წესი, ეს ტექნოლოგია და მასთან დაკავშირებული ამოცანები არ არის ავტომატიზაციის ინჟინრების პასუხისმგებლობა. და ამის მიზეზები არსებობს. პირველ რიგში, ბევრ ორგანიზაციაში ინფრასტრუქტურის საკითხები DevOps დეპარტამენტის კონტროლს ექვემდებარება და განვითარების გუნდებს ნამდვილად არ აინტერესებთ, რა აიძულებს მილსადენის მუშაობას და როგორ უნდა იყოს მასთან დაკავშირებული ყველაფერი. მეორეც, გულწრფელად ვიყოთ, ინფრასტრუქტურის კოდის (IaC) პრაქტიკა ჯერ კიდევ არ არის მიღებული ბევრ კომპანიაში. მაგრამ ის ნამდვილად გახდა პოპულარულ ტრენდად და მნიშვნელოვანია, რომ შევეცადოთ ჩაერთოთ მასთან დაკავშირებულ პროცესებში, მიდგომებსა და ინსტრუმენტებში. ან სულაც იყავით განახლებული.

დავიწყოთ ამ მიდგომის გამოყენების მოტივირებით. ჩვენ უკვე განვიხილეთ, რომ GitlabCI-ში ტესტების გასაშვებად, მინიმუმ დაგვჭირდება რესურსები Gitlab Runner-ის გასაშვებად. და ბრაუზერებით/ემულატორებით კონტეინერების გასაშვებად, ჩვენ გვჭირდება VM-ის ან კლასტერის დაჯავშნა. რესურსების ტესტირების გარდა, ჩვენ გვჭირდება მნიშვნელოვანი ტევადობა განვითარების, დადგმის, წარმოების გარემოს მხარდასაჭერად, რომელიც ასევე მოიცავს მონაცემთა ბაზებს, ავტომატურ განრიგს, ქსელის კონფიგურაციებს, დატვირთვის ბალანსერებს, მომხმარებლის უფლებებს და ა.შ. მთავარი საკითხი არის ძალისხმევა, რომელიც საჭიროა ამ ყველაფრის მხარდასაჭერად. ცვლილებების შეტანისა და განახლებების გამოქვეყნების რამდენიმე გზა არსებობს. მაგალითად, GCP-ის კონტექსტში, ჩვენ შეგვიძლია გამოვიყენოთ UI კონსოლი ბრაუზერში და შევასრულოთ ყველა მოქმედება ღილაკების დაწკაპუნებით. ალტერნატივა იქნება API ზარების გამოყენება ღრუბლის ერთეულებთან ურთიერთობისთვის, ან gcloud ბრძანების ხაზის გამოყენება სასურველი მანიპულაციების შესასრულებლად. მაგრამ სხვადასხვა ერთეულებისა და ინფრასტრუქტურის ელემენტების მართლაც დიდი რაოდენობით, რთული ან თუნდაც შეუძლებელი ხდება ყველა ოპერაციის ხელით შესრულება. უფრო მეტიც, ყველა ეს ხელით მოქმედება უკონტროლოა. ჩვენ არ შეგვიძლია მათი განხილვა შესრულებამდე, გამოვიყენოთ ვერსიის კონტროლის სისტემა და სწრაფად გავაუქმოთ ცვლილებები, რამაც გამოიწვია ინციდენტი. ასეთი პრობლემების გადასაჭრელად ინჟინერებმა შექმნეს და შექმნეს ავტომატური bash/shell სკრიპტები, რომლებიც არ არის ბევრად უკეთესი წინა მეთოდებთან შედარებით, რადგან არც ისე ადვილია მათი სწრაფად წაკითხვა, გაგება, შენარჩუნება და შეცვლა პროცედურულ სტილში.

ამ სტატიაში და სახელმძღვანელოში, მე ვიყენებ IaC პრაქტიკასთან დაკავშირებულ 2 ინსტრუმენტს. ეს არის Terraform და Ansible. ზოგიერთს მიაჩნია, რომ აზრი არ აქვს მათ ერთდროულად გამოყენებას, რადგან მათი ფუნქციონირება მსგავსია და ურთიერთშემცვლელნი არიან. მაგრამ ფაქტია, რომ თავდაპირველად მათ სრულიად განსხვავებული დავალებები ეძლევათ. და ის ფაქტი, რომ ეს ხელსაწყოები ერთმანეთს უნდა ავსებდნენ, დაადასტურა ერთობლივი პრეზენტაციაზე HashiCorp-ისა და RedHat-ის წარმომადგენლობით დეველოპერებმა. კონცეპტუალური განსხვავება ისაა, რომ Terraform არის უზრუნველყოფის ინსტრუმენტი თავად სერვერების მართვისთვის. მიუხედავად იმისა, რომ Ansible არის კონფიგურაციის მართვის ინსტრუმენტი, რომლის ამოცანაა ამ სერვერებზე პროგრამული უზრუნველყოფის ინსტალაცია, კონფიგურაცია და მართვა.

ამ ხელსაწყოების კიდევ ერთი მთავარი განმასხვავებელი თვისებაა კოდირების სტილი. Bash-ისა და Ansible-ისგან განსხვავებით, Terraform იყენებს დეკლარაციულ სტილს, რომელიც დაფუძნებულია შესრულების შედეგად მიღწეული სასურველი საბოლოო მდგომარეობის აღწერაზე. მაგალითად, თუ ვაპირებთ 10 VM-ის შექმნას და ცვლილებების გამოყენებას Terraform-ის საშუალებით, მაშინ მივიღებთ 10 VM-ს. თუ სკრიპტს ხელახლა გავუშვით, არაფერი მოხდება, რადგან ჩვენ უკვე გვაქვს 10 VM და Terraform-მა იცის ამის შესახებ, რადგან ის ინახავს ინფრასტრუქტურის მიმდინარე მდგომარეობას სახელმწიფო ფაილში. მაგრამ Ansible იყენებს პროცედურულ მიდგომას და, თუ მას სთხოვთ შექმნას 10 VM, მაშინ პირველ გაშვებაზე მივიღებთ 10 VM-ს, Terraform-ის მსგავსს. მაგრამ გადატვირთვის შემდეგ უკვე გვექნება 20 VM. ეს არის მნიშვნელოვანი განსხვავება. პროცედურული სტილით, ჩვენ არ ვინახავთ მიმდინარე მდგომარეობას და უბრალოდ აღვწერთ ნაბიჯების თანმიმდევრობას, რომელიც უნდა შესრულდეს. რა თქმა უნდა, ჩვენ შეგვიძლია გავუმკლავდეთ სხვადასხვა სიტუაციებს, დავამატოთ რამდენიმე შემოწმება რესურსების არსებობისა და არსებული მდგომარეობის შესახებ, მაგრამ აზრი არ აქვს დროის დაკარგვას და ძალისხმევის დახარჯვას ამ ლოგიკის გასაკონტროლებლად. გარდა ამისა, ეს ზრდის შეცდომების დაშვების რისკს. 

ყოველივე ზემოთქმულის შეჯამებით, შეგვიძლია დავასკვნათ, რომ Terraform და დეკლარაციული აღნიშვნა უფრო შესაფერისი ინსტრუმენტია სერვერების უზრუნველყოფისთვის. მაგრამ უმჯობესია კონფიგურაციის მართვის სამუშაოს დელეგირება Ansible-ზე. ამის გამო, მოდით შევხედოთ გამოყენების შემთხვევებს ავტომატიზაციის კონტექსტში.

ღირებულება ავტომატიზაციის ინფრასტრუქტურისთვის

ერთადერთი მნიშვნელოვანი, რაც აქ უნდა გვესმოდეს, არის ის, რომ სატესტო ავტომატიზაციის ინფრასტრუქტურა უნდა განიხილებოდეს, როგორც მთელი კომპანიის ინფრასტრუქტურის ნაწილი. ეს ნიშნავს, რომ ყველა IaC პრაქტიკა უნდა იქნას გამოყენებული გლობალურად მთელი ორგანიზაციის რესურსებზე. ვინ არის პასუხისმგებელი ამაზე, დამოკიდებულია თქვენს პროცესებზე. DevOps-ის გუნდი უფრო გამოცდილია ამ საკითხებში, ისინი ხედავენ სრულ სურათს იმის შესახებ, რაც ხდება. თუმცა, QA ინჟინრები უფრო მეტად არიან ჩართული შენობის ავტომატიზაციის პროცესში და მილსადენის სტრუქტურაში, რაც მათ საშუალებას აძლევს უკეთ დაინახონ ყველა საჭირო ცვლილება და გაუმჯობესების შესაძლებლობა. საუკეთესო ვარიანტია ერთობლივი მუშაობა, ცოდნისა და იდეების გაცვლა მოსალოდნელი შედეგის მისაღწევად. 

აქ მოცემულია Terraform-ისა და Ansible-ის გამოყენების რამდენიმე მაგალითი ტესტის ავტომატიზაციის კონტექსტში და ინსტრუმენტები, რომლებიც ადრე განვიხილეთ:

1. აღწერეთ VM-ების და კლასტერების საჭირო მახასიათებლები და პარამეტრები Terraform-ის გამოყენებით.

2. Ansible-ის გამოყენებით დააინსტალირეთ ტესტირებისთვის საჭირო ხელსაწყოები: docker, Selenoid, Selenium Grid და ჩამოტვირთეთ ბრაუზერების/ემულატორების საჭირო ვერსიები.

3. Terraform-ის გამოყენებით აღწერეთ VM-ის მახასიათებლები, რომელშიც GitLab Runner ამოქმედდება.

4. დააინსტალირეთ GitLab Runner და საჭირო თანმხლები ხელსაწყოები Ansible-ის გამოყენებით, დააყენეთ პარამეტრები და კონფიგურაციები.

ინფრასტრუქტურის ამჟამინდელი მდგომარეობის ილუსტრაცია

ბმულები შესასწავლად:

• Terraform
• შეუძლებელია
• Ansible და Terraform ერთად უკეთესია
• ყოვლისმომცველი გზამკვლევი Terraform
• რატომ ვიყენებთ Terraform-ს და არა Chef-ს, Puppet-ს, Ansible-ს, SaltStack-ს ან CloudFormation-ს
• GCP: IaC

მსგავსი იარაღები

• შეფ
• თოჯინები
• SaltStack
• ვაგროანტი

მოდით შევაჯამოთ!

ნაბიჯი
ტექნიკა
ინსტრუმენტები
ღირებულება ავტომატიზაციის ინფრასტრუქტურისთვის

1
ლოკალური სირბილი
Node.js, Selenium, Appium

• ყველაზე პოპულარული ინსტრუმენტები ვებსა და მობილურისთვის
• მხარს უჭერს ბევრ ენას და პლატფორმას (მათ შორის Node.js)

2
ვერსიის მართვის სისტემები 
წასვლა

• მსგავსი სარგებელი განვითარების კოდით

3
კონტეინერიზაცია
Docker, Selenium Grid, Selenoid (ვებ, Android)

• ტესტების პარალელურად გაშვება
• იზოლირებული გარემო
• მარტივი, მოქნილი ვერსიის განახლებები
• გამოუყენებელი რესურსების დინამიურად შეჩერება
• მარტივი დაყენება

4
CI/CD
Gitlab CI

• ამოწმებს მილსადენის ნაწილს
• სწრაფი გამოხმაურება
• ხილვადობა მთელი კომპანიის/გუნდისთვის

5
Cloud პლატფორმები
Google Cloud პლატფორმა

• რესურსები მოთხოვნით (ვიხდით მხოლოდ საჭიროების შემთხვევაში)
• მარტივი მართვა და განახლება
• ყველა რესურსის ხილვადობა და კონტროლი

6
ორკესტრირება
კუბერნეტები
კონტეინერების კონტექსტში ბრაუზერებით/ემულატორებით პოდებში:

• სკალირება/ავტომატური სკალირება
• თვითგანკურნება
• განახლებები და უკან დაბრუნება შეფერხების გარეშე

7
ინფრასტრუქტურა, როგორც კოდი (IaC)
Terraform, Ansible

• მსგავსი სარგებელი განვითარების ინფრასტრუქტურით
• კოდის ვერსიების ყველა უპირატესობა
• ადვილია ცვლილებების შეტანა და შენარჩუნება
• სრულად ავტომატიზირებული

გონების რუქის დიაგრამები: ინფრასტრუქტურის ევოლუცია

ნაბიჯი 1: ადგილობრივი

ნაბიჯი 2: VCS

ნაბიჯი 3: კონტეინერიზაცია 

ნაბიჯი 4: CI/CD 

ნაბიჯი 5: ღრუბლოვანი პლატფორმები

ნაბიჯი 6: ორკესტრირება

ნაბიჯი 7: IaC

რა არის შემდეგი?

ასე რომ, ეს არის სტატიის დასასრული. მაგრამ დასასრულს, მსურს თქვენთან გარკვეული შეთანხმებების დამყარება.

Შენი მხრიდან
როგორც დასაწყისში ვთქვი, ვისურვებდი, რომ სტატია იყოს პრაქტიკული და დაგეხმაროთ მიღებული ცოდნის რეალურ მუშაობაში გამოყენებაში. ისევ დავამატებ ბმული პრაქტიკულ სახელმძღვანელოზე.

მაგრამ ამის შემდეგაც არ გაჩერდეთ, ივარჯიშეთ, შეისწავლეთ შესაბამისი ლინკები და წიგნები, გაარკვიეთ, როგორ მუშაობს ეს თქვენს კომპანიაში, იპოვეთ ადგილები, რომლებიც შეიძლება გაუმჯობესდეს და მონაწილეობა მიიღოთ მასში. Წარმატებები!

Ჩემი მხრიდან

სათაურიდან ხედავთ, რომ ეს მხოლოდ პირველი ნაწილი იყო. მიუხედავად იმისა, რომ საკმაოდ მასშტაბური აღმოჩნდა, მნიშვნელოვანი თემები აქ მაინც არ არის გაშუქებული. მეორე ნაწილში ვგეგმავ ავტომატიზაციის ინფრასტრუქტურას IOS-ის კონტექსტში შევხედო. Apple-ის შეზღუდვების გამო iOS სიმულატორების მხოლოდ macOS სისტემებზე გაშვებაზე, ჩვენი გადაწყვეტილებების სპექტრი ვიწროვდება. მაგალითად, ჩვენ არ შეგვიძლია გამოვიყენოთ Docker სიმულატორის გასაშვებად ან საჯარო ღრუბლები ვირტუალური მანქანების გასაშვებად. მაგრამ ეს არ ნიშნავს იმას, რომ სხვა ალტერნატივა არ არსებობს. შევეცდები გაგაცნობოთ მოწინავე გადაწყვეტილებებსა და თანამედროვე ხელსაწყოებს!

ასევე, მონიტორინგთან დაკავშირებული საკმაოდ დიდი თემები არ მიხსენებია. მე-3 ნაწილში მე ვაპირებ გადავხედო ინფრასტრუქტურის მონიტორინგის ყველაზე პოპულარულ ინსტრუმენტებს და რა მონაცემებსა და მეტრიკას უნდა გავითვალისწინო.

Და ბოლოს. სამომავლოდ ვგეგმავ ვიდეოკურსის გამოშვებას სატესტო ინფრასტრუქტურისა და პოპულარული ინსტრუმენტების მშენებლობაზე. ამჟამად ინტერნეტში საკმაოდ ბევრი კურსი და ლექციაა DevOps-ზე, მაგრამ ყველა მასალა წარმოდგენილია განვითარების კონტექსტში და არა ტესტის ავტომატიზაციის. ამ საკითხთან დაკავშირებით, მე ნამდვილად მჭირდება გამოხმაურება, იქნება თუ არა ასეთი კურსი საინტერესო და ღირებული ტესტერებისა და ავტომატიზაციის ინჟინრების საზოგადოებისთვის. Წინასწარ გმადლობ!

წყარო: www.habr.com