Partea 1: Web / Android
Notă: această articol este o traducere în limba română a articolului original Cu toate acestea, toate ilustrațiile, linkurile, citatele și termenii sunt păstrați în limba originală, pentru a evita distorsionarea sensului în traducerea în limba română. Îți doresc un studiu plăcut!
În prezent, specialitatea DevOps este una dintre cele mai căutate în industria IT. Dacă deschizi site-uri populare de căutare a locurilor de muncă și aplici un filtru după salarii, vei observa că joburile legate de DevOps sunt la începutul listei. Totuși, este important de înțeles că aceasta se referă în principal la poziția 'Senior', ceea ce implică faptul că solicitantul are un nivel înalt de abilități, cunoștințe despre tehnologii și instrumente. De asemenea, vine cu un grad înalt de responsabilitate, legată de continuitatea operațiunilor de producție. Cu toate acestea, am început să uităm ce înseamnă DevOps. La început, acesta nu a fost o persoană sau un departament anume. Dacă căutăm definițiile acestui termen, vom găsi multe substantive frumoase și corecte, cum ar fi metodologie, practici, filosofie culturală, grup de concepte și așa mai departe.
Specializarea mea este inginer de automatizare a testării (QA automation engineer), dar cred că nu ar trebui să fie legată doar de scrierea testelor automate sau de dezvoltarea arhitecturii framework-ului de testare. În 2020, cunoștințele despre infrastructura de automatizare sunt, de asemenea, necesare. Aceasta permite organizarea procesului de automatizare independent, începând de la rularea testelor și terminând cu furnizarea rezultatelor tuturor părților interesate, conform obiectivelor stabilite. Drept urmare, abilitățile DevOps sunt un factor obligatoriu pentru a realiza această muncă. Și toate acestea sunt bune, dar, din păcate, există o problemă (spoiler: acest articol face o încercare de a simplifica această problemă). Problema constă în faptul că DevOps este complicat. Și este evident că firmele nu vor plăti mult pentru ceea ce este ușor de realizat… În lumea DevOps există o mulțime de instrumente, termeni, practici pe care trebuie să le stăpânești. În special, acest lucru este dificil la începutul carierei și depinde de experiența tehnică acumulată.
Sursa:
Aici cred că putem încheia partea introductivă și să ne concentrăm asupra scopului acestui articol.
Despre ce este acest articol
În acest articol, voi împărtăși experiența mea în construirea unei infrastructuri pentru automatizarea testării. În mediul online există multe surse de informații despre diverse instrumente și modul de utilizare a acestora, dar aș dori să le discut exclusiv în contextul automatizării. Cred că mulți ingineri de automatizare se confruntă cu situația în care testele create de ei nu sunt rulate și întreținute de nimeni altcineva. Ca rezultat, testele devin învechite și trebuie să investești timp pentru a le actualiza. Din nou, la începutul carierei, aceasta poate fi o provocare destul de dificilă: a decide corect ce instrumente ar trebui să te ajute să rezolvi această problemă, cum să le alegi, să le configurezi și să le întreții. Unii testeri apelează la DevOps (persoane) și, să fim sincéri, această abordare funcționează. În multe cazuri, aceasta poate fi singura opțiune, deoarece ne lipsește vizibilitatea tuturor dependențelor. Dar, așa cum știm, DevOps sunt oameni foarte ocupați, deoarece trebuie să se gândească la infrastructura întregii companii, la deployment, monitorizare, microservicii și alte sarcini similare, în funcție de organizație / echipă. Așa cum se întâmplă de obicei, automatizarea nu este o prioritate. În acest caz, trebuie să încercăm să facem tot posibilul din partea noastră de la început până la sfârșit. Acest lucru va reduce dependențele, va accelera fluxul de lucru, va îmbunătăți abilitățile noastre și ne va permite să vedem o imagine mai largă a ceea ce se întâmplă.
Articolul prezintă instrumentele cele mai solicitate și populare, arătând cum să le folosești pentru a construi pas cu pas infrastructura pentru automatizare. Fiecare grup este reprezentat de instrumente care au fost testate personal. Dar asta nu înseamnă că trebuie să folosești aceleași lucruri. Instrumentele în sine nu sunt importante, ele apar și ajung să fie depășite. Sarcina noastră de inginerie este să înțelegem principiile de bază: de ce avem nevoie de acest grup de instrumente și ce sarcini de lucru putem rezolva cu ajutorul lor. De aceea, la sfârșitul fiecărei secțiuni, las linkuri către instrumente similare care, probabil, sunt utilizate în organizația ta.
Ce nu este în acest articol
Reiterez că articolul nu este despre uneltele specifice, așa că nu vor fi inserții de cod din documentație sau descrierea unor comenzi concrete. Dar la finalul fiecărei secțiuni las linkuri pentru studiu detaliat.
Aceasta s-a făcut din următoarele motive:
- acest material este foarte ușor de găsit în diverse surse (documentație, cărți, cursuri video);
- dacă ne adâncim, va trebui să scriem 10, 20, 30 de părți ale acestui articol (în timp ce în planuri sunt 2-3);
- pur și simplu nu vreau să vă irosesc timpul, deoarece este posibil să doriți să folosiți alte unelte pentru a atinge aceleași obiective.
Practică
Mi-ar plăcea foarte mult ca acest material să fie util pentru fiecare cititor, nu doar să fie citit și uitat. În orice proces de învățare, practica este o componentă foarte importantă. De aceea am pregătit. De asemenea, vă așteaptă teme de casă pentru a fi siguri că nu ați copiat fără să gândiți rândurile comenzilor executate
Plan
Pas
Tehnologie
Instrumente
1
Rulare locală (pregătiți teste demo web / android și rulați-le local)
Node.js, Selenium, Appium
2
Sisteme de control al versiunilor
Git
3
Containerizare
Docker, Selenium grid, Selenoid (Web, Android)
4
CI / CD
Gitlab CI
5
Platforme cloud
Google Cloud Platform
6
Orchestrare
Kubernetes
7
Infrastructură ca cod (IaC)
Terraform, Ansible
Structura fiecărei secțiuni
Pentru a menține narațiunea într-o formă vizibilă, fiecare secțiune este descrisă conform următorului plan:
- descriere scurtă a tehnologiei,
- valoare pentru infrastructura de automatizare,
- ilustrarea stării actuale a infrastructurii,
- linkuri pentru studiu,
- unelte similare.
1. Rularea locală a testelor
Descriere scurtă a tehnologiei
Aceasta este doar o etapă pregătitoare pentru a rula teste demo local și pentru a verifica că acestea trec cu succes. În partea practică se folosește Node.js, dar limbajul de programare și platforma nu sunt importante, se pot folosi cele pe care le utilizează compania dumneavoastră.
Cu toate acestea, ca unelte de automatizare, vă recomand să folosiți Selenium WebDriver pentru platformele web și Appium pentru platforma Android, deoarece în pașii următori vom utiliza imagini Docker care sunt optimizate pentru a lucra specific cu aceste unelte. Mai mult, referindu-se la cerințele din anunțurile de angajare, aceste unelte sunt cele mai solicitate pe piață.
După cum ați observat, ne concentrăm doar pe testele web și Android. Din păcate, IOS este o poveste complet diferită (mulțumesc Apple). Plănuiesc să demonstrez soluțiile și practicile legate de IOS în părțile următoare.
Valoarea pentru infrastructura de automatizare
Din punct de vedere al infrastructurii, rularea locală nu are nicio valoare. Verificați doar că testele funcționează pe mașina locală în browserele locale și simulatoarele. Dar, în orice caz, aceasta este un punct de plecare necesar.
Ilustrarea stării curente a infrastructurii
Linkuri pentru studiu
Instrumente similare
- orice limbaj de programare preferați, împreună cu testele Selenium/Appium;
- orice teste;
- orice runner de teste.
2. Sisteme de control al versiunilor (Git)
Descriere scurtă a tehnologiei
Nu va fi o mare descoperire pentru nimeni dacă spun că sistemul de control al versiunilor este o parte extrem de importantă a dezvoltării, atât în echipe, cât și individual. Bazându-ne pe diverse surse, putem afirma cu încredere că Git este cel mai popular reprezentant. Sistemul de control al versiunilor oferă multiple avantaje, cum ar fi partajarea codului, stocarea versiunilor, restaurarea pe ramuri anterioare, monitorizarea istoricului proiectului, backup-uri. Nu vom discuta fiecare punct în detaliu, deoarece sunt sigur că sunteți familiarizați cu aceste aspecte și le folosiți în activitatea de zi cu zi. Dar, dacă cumva nu sunteți, vă recomand să întrerupeți lectura acestui articol și să completați această lacună cât mai repede.
Valoarea pentru infrastructura de automatizare
Și aici puteți pune o întrebare rezonabilă: „De ce ne povestește despre Git? Toată lumea știe și folosește pentru dezvoltarea codului, cât și pentru codul testelor automate”. Veți avea absolut dreptate, dar în acest articol discutăm despre infrastructură, iar această secțiune joacă rolul de previzualizare pentru secțiunea 7: „Infrastructura ca cod (IaC)”. Pentru noi, aceasta înseamnă că întreaga infrastructură, inclusiv cea de testare, este descrisă sub formă de cod, astfel încât putem aplica și sistemele de versionare și obține aceleași avantaje ca pentru codul de dezvoltare și automatizare.
Vom analiza IaC mai detaliat în pasul 7, dar chiar și acum se poate începe să folosești Git local, creând un depozit local. Imaginea de ansamblu va fi extinsă odată ce vom adăuga un depozit remote la infrastructură.
Ilustrarea stării curente a infrastructurii
Linkuri pentru studiu
Instrumente similare
3. Contenerizarea (Docker)
Descriere scurtă a tehnologiei
Pentru a demonstra cum a schimbat contenizarea regulile jocului, să călătorim înapoi cu câteva decenii. În acele vremuri, oamenii achiziționau și foloseau servere pentru a rula aplicații. Însă, în cele mai multe cazuri, resursele necesare pentru rulare nu erau cunoscute dinainte. Ca urmare, companiile cheltuiau bani pe achiziționarea de servere puternice, dar o parte din aceste capacități nu erau utilizate complet.
Următoarea etapă a evoluției au fost mașinile virtuale (VM), care au rezolvat problema cheltuielilor pe resursele neutilizate. Această tehnologie a permis rularea aplicațiilor independent una de alta pe un singur server, alocând un spațiu complet izolat. Dar, din păcate, orice tehnologie are dezavantajele sale. Rularea VM-urilor necesită un sistem de operare complet, care consumă CPU, RAM, stocare și, în funcție de OS, trebuie să iei în considerare cheltuielile pentru licență. Acești factori influențează viteza de încărcare și complică portabilitatea.
Și iată ne apropiem de contenizare. Din nou, această tehnologie a rezolvat problema anterioară, deoarece containerele nu folosesc un sistem de operare complet, ceea ce permite eliberarea unui număr semnificativ de resurse și oferă o soluție rapidă și flexibilă pentru portabilitate.
Desigur, tehnologia containerizării nu este ceva nou și a fost introdusă pentru prima dată la sfârșitul anilor '70. Atunci au fost realizate multe studii, progrese și încercări. Dar tocmai Docker a adaptat această tehnologie și a făcut-o ușor accesibilă pentru mase. În ziua de azi, când vorbim despre containere, de cele mai multe ori ne referim la Docker. Atunci când vorbim despre containere Docker, ne gândim la containere Linux. Putem utiliza sisteme Windows și macOS pentru a rula containere, dar este important să înțelegem că, în acest caz, apare un strat suplimentar. De exemplu, Docker pe Mac lansează pe furiș containere în interiorul unei VM Linux ușoare. Vom reveni la acest subiect când vom discuta despre rularea emulatoarelor Android în containere, deoarece aici apare un detaliu foarte important care trebuie analizat mai în detaliu.
Valoarea pentru infrastructura de automatizare
Am stabilit că containerizarea și Docker sunt fantastice. Să vedem acest concept în contextul automatizării, deoarece orice instrument sau tehnologie trebuie să rezolve o problemă. Să identificăm problemele evidente ale automatizării testelor în contextul testelor UI:
- o cantitate uriașă de dependențe la instalarea Selenium și, în special, Appium;
- probleme de compatibilitate între versiunile browserelor, simulatoarelor și driverelor;
- lipsa unui spațiu izolat pentru browsere/simulatoare, ceea ce este deosebit de crucial pentru rularea paralelă;
- dificultăți în gestionare și întreținere, dacă trebuie să rulați 10, 50, 100 sau chiar 1000 de browsere simultan.
Dar, deoarece Selenium este cel mai popular instrument de automatizare, iar Docker este cel mai popular instrument de containerizare, nimeni nu ar trebui să se mire că cineva a încercat să le combine pentru a obține un instrument puternic pentru a rezolva problemele menționate mai sus. Să analizăm aceste soluții în detaliu.
Selenium grid în docker
Acest instrument este cel mai popular din lume pentru Selenium, folosit pentru a rula mai multe browsere pe mai multe mașini și a le gestiona dintr-un nod central. Pentru a-l porni, este necesar să înregistrăm cel puțin 2 componente: Hub și Node(s). Hub-ul este nodul central care primește toate cererile de la teste și le distribuie către Node-urile corespunzătoare. Pentru fiecare Node, putem configura o configurație specifică, de exemplu, specificând browserul dorit și versiunea acestuia. Cu toate acestea, trebuie să ne ocupăm personal de driverele compatibile pentru browsere și să le instalăm pe Node-urile necesare. Din acest motiv, Selenium Grid nu este folosit în forma sa pură, exceptând cazurile când avem de-a face cu browsere care nu pot fi instalate pe Linux OS. Pentru toate celelalte cazuri, o soluție mult mai flexibilă și corectă este utilizarea imaginilor Docker pentru a lansa Hub-ul și Node-urile Selenium Grid. Această abordare simplifică gestionarea nodurilor, deoarece putem alege imaginea dorită, care are deja instalate versiunile compatibile ale browserelor și driverelor.
În ciuda recenziilor negative privind stabilitatea funcționării, în special atunci când se lansează un număr mare de Node-uri în paralel, Selenium Grid rămâne cel mai popular instrument pentru rularea paralelă a testelor Selenium. Este important de menționat că, în open-source, apar constant diverse îmbunătățiri și modificări ale acestui instrument, care abordează diferitele colțuri neagră.
Selenoid pentru Web
Acest instrument reprezintă o inovație în lumea Selenium, funcționând imediat din cutie și facilitând semnificativ viața multor ingineri de automatizare. În primul rând, nu este o simplă modificare a Selenium Grid. În schimb, dezvoltatorii au creat o versiune complet nouă a Selenium Hub în limbajul Golang, ceea ce, împreună cu imaginile Docker ușoare pentru diverse browsere, a accelerat dezvoltarea automatizării testării. Mai mult decât atât, în cazul Selenium Grid, trebuie să definim din timp toate browserele și versiunile necesare, ceea ce nu reprezintă o problemă atunci când lucrăm cu un singur browser. Însă, când vine vorba de mai multe browsere suportate, Selenoid este soluția numărul unu, datorită funcției 'browser la cerere'. Tot ce trebuie să facem este să descărcăm din timp imaginile necesare cu browserele și să actualizăm fișierul de configurare cu care interacționează Selenoid. Odată ce Selenoid primește o solicitare de la teste, va lansa automat containerul necesar cu browserul dorit. După ce testul se finalizează, Selenoid va închide containerul, eliberând astfel resursele pentru următoarele solicitări. Astfel de abordare elimină complet problema cunoscută a 'degradării nodurilor', cu care ne întâlnim frecvent în Selenium Grid.
Dar, din păcate, Selenoid nu este încă un panaceu. Am obținut funcția 'browser la cerere', dar funcția 'resurse la cerere' nu este încă disponibilă. Pentru a utiliza Selenoid, trebuie să-l desfășurăm pe hardware fizic sau pe VM, ceea ce înseamnă că trebuie să știm din timp câte resurse trebuie alocate. Consider că nu este o problemă pentru proiectele mici care rulează 10, 20 sau chiar 30 de browsere simultan. Dar ce se întâmplă dacă avem nevoie de 100, 500, 1000 și mai mult? Nu are sens să menținem și să plătim pentru un astfel de număr de resurse constant. În secțiunile 5 și 6 ale acestui articol, vom discuta soluții care permit scalarea, reducând astfel semnificativ costurile companiei.
Selenoid pentru Android
După succesul Selenoid ca instrument pentru automatizarea web, oamenii au dorit să obțină ceva similar pentru Android. Și acest lucru s-a întâmplat – Selenoid a fost lansat cu suport pentru Android. Din perspectiva utilizatorului, principiul de funcționare este similar cu cel al automatizării web. Singura diferență este că, în loc de containere cu browsere, Selenoid rulează containere cu emulatori Android. Din punctul meu de vedere, în prezent, acesta este cel mai puternic instrument gratuit pentru a rula teste Android în paralel.
Nu mi-ar plăcea deloc să vorbesc despre laturile negative ale acestui instrument, deoarece chiar îmi place foarte mult. Totuși, există aceleași dezavantaje care se referă și la automatizarea web, legate de scalabilitate. În plus, trebuie să menționez o altă limitare, care poate deveni o surpriză dacă configurăm instrumentul pentru prima dată. Pentru a rula imaginile Android, avem nevoie de o mașină fizică sau de o VM cu suport pentru virtualizare încorporată. În ghidul practic, voi demonstra cum să activăm acest lucru pe o VM Linux. Totuși, dacă ești utilizator macOS și vrei să desfășori Selenoid local, nu va fi posibil să rulezi teste Android. Dar poți rula întotdeauna o VM Linux local cu virtualizarea încorporată configurată și să desfășori Selenoid în interior.
Ilustrarea stării curente a infrastructurii
În contextul acestui articol, vom adăuga 2 instrumente pentru a ilustra infrastructura. Acestea sunt Selenium Grid pentru teste web și Selenoid pentru teste Android. În ghidul de pe GitHub, voi arăta, de asemenea, cum să folosești Selenoid pentru a rula teste web.
Linkuri pentru studiu
Instrumente similare
- Există și alte instrumente de containerizare, dar Docker este cel mai popular. Dacă dorești să încerci ceva diferit, reține că instrumentele pe care le-am discutat pentru rularea paralelă a testelor Selenium nu vor funcționa din cutie.
- Așa cum am spus, există multe modificări ale Selenium Grid, de exemplu,.
4. CI / CD
Descriere scurtă a tehnologiei
Practicile de integrare continuă sunt destul de populare în dezvoltare și se află la fel de importante ca și sistemele de control al versiunilor. Cu toate acestea, simt că există confuzie în termeni. În acest paragraf, aș dori să descriu 3 modificări ale acestei tehnologii din perspectiva mea. Pe internet, veți găsi multe articole cu diverse interpretări, iar acest lucru este absolut normal dacă opinia dumneavoastră este diferită. Cel mai important este să fiți pe aceeași lungime de undă cu colegii dumneavoastră.
Așadar, există 3 termeni: CI — Continuous Integration (integrare continuă), CD — Continuous Delivery (livrare continuă) și din nou CD — Continuous Deployment (implementare continuă). (În continuare, voi folosi acești termeni în limba engleză). Fiecare modificare adaugă câteva etape suplimentare în procesul dumneavoastră de dezvoltare. Însă cuvântul continuous este cel mai important. În acest context, ne referim la ceva care se desfășoară de la început până la sfârșit, fără întreruperi sau intervenții manuale. Să analizăm CI & CD și CD în acest context.
- Continuous Integration – este primul pas în evoluție. După ce trimitem un cod nou pe server, ne așteptăm să primim rapid feedback că modificările noastre sunt în regulă. De obicei, CI include rularea instrumentelor de analiză statică a codului și teste unitare/intern API. Aceasta ne permite să obținem informații despre codul nostru la câteva secunde/minute după.
- Continuous Delivery este un pas mai avansat, în care rulăm teste de integrare/UI. Totuși, în această etapă nu obținem rezultatele la fel de repede ca în cazul CI. În primul rând, aceste tipuri de teste necesită mai mult timp pentru a fi executate. În al doilea rând, înainte de a rula, trebuie să desfășurăm modificările noastre pe medii de testare/staging. Mai mult, dacă vorbim despre dezvoltarea de aplicații mobile, apare o etapă suplimentară de creare a versiuni aplicației noastre.
- Continuous Deployment presupune că eliberăm automat (release) modificările noastre în production, dacă toate testele de acceptare au fost finalizate în etapele anterioare. În plus, după etapa release, se pot configura diverse etape, cum ar fi lansarea testelor smoke pe production și colectarea metrilor de interes. Continuous Deployment este posibil doar cu o acoperire bună a testelor automatizate. Dacă sunt necesare intervenții manuale, inclusiv testarea, atunci aceasta nu mai este Continu (continu). Atunci putem spune că pipeline-ul nostru respectă doar practica Continuous Delivery.
Valoarea pentru infrastructura de automatizare
În această secțiune trebuie să clarific că, atunci când vorbim despre teste UI end-to-end, înseamnă că trebuie să desfășurăm modificările noastre și serviciile asociate pe medii de testare. Continuous Integration - procesul nu este aplicabil pentru această sarcină și trebuie să ne asumăm implementarea măcar a practicilor Continuous Delivery. Continuous Deployment are de asemenea sens în contextul testelor UI, dacă intenționăm să le rulăm pe production.
Și înainte de a ne uita la ilustrarea modificării arhitecturii, vreau să spun câteva cuvinte despre GitLab CI. Spre deosebire de alte instrumente CI/CD, GitLab oferă un repository remote și multe alte funcționalități suplimentare. Astfel, GitLab este mai mult decât CI. Include din cutie gestionarea codului sursă, management Agile, pipeline-uri CI/CD, unelte de logging și colectare de metrici. Arhitectura GitLab constă în Gitlab CI/CD și GitLab Runner. Iată o descriere scurtă de pe site-ul oficial:
Gitlab CI/CD este o aplicație web cu un API care își stochează starea într-o bază de date, gestionează proiecte/build-uri și oferă o interfață utilizator. GitLab Runner este o aplicație care procesează build-urile. Poate fi desfășurat separat și lucrează cu GitLab CI/CD printr-un API. Pentru rularea testelor ai nevoie atât de instanța Gitlab, cât și de Runner.
Ilustrarea stării curente a infrastructurii
Linkuri pentru studiu
Instrumente similare
- Și multe altele
5. Platforme cloud
Descriere scurtă a tehnologiei
În această secțiune, vom discuta despre o tendință populară numită 'cloud-uri publice'. Cu toate că tehnologiile de virtualizare și containerizare menționate mai sus oferă beneficii enorme, avem în continuare nevoie de resurse computaționale. Companiile cumpără servere scumpe sau închiriază centre de date, dar în acest caz trebuie să facă calcule (uneori nerealiste) cu privire la cât de multe resurse ne vor fi necesare, dacă le vom folosi 24/7 și în ce scopuri. De exemplu, pentru producție, este necesar un server care funcționează nonstop, dar avem nevoie de resurse similare pentru testare în afara orelor de lucru? Acest lucru depinde și de tipul testării efectuate. Un exemplu sunt testele de sarcină/stres, pe care le planificăm să le rulăm în afara orelor de lucru pentru a obține rezultate în ziua următoare. Cu toate acestea, disponibilitatea non-stop a serverelor nu este necesară pentru testele auto-end-to-end, mai ales pentru mediile de testare manuală. Pentru astfel de situații, ar fi util să obținem resurse conforme cerințelor pe care să le utilizăm și să nu mai plătim când nu mai sunt necesare. Mai mult, ar fi grozav să le obținem instantaneu, făcând câteva clicuri sau rulând câteva scripturi. Aici intervin cloud-urile publice. Să vedem definiția:
«Cloud-ul public este definit ca servicii de computing oferite de furnizori terți prin Internetul public, făcându-le disponibile oricui dorește să le folosească sau să le achiziționeze. Acestea pot fi gratuite sau vândute la cerere, permițând clienților să plătească doar pentru utilizarea ciclurilor CPU, a spațiului de stocare sau a lățimii de bandă pe care le consumă».
Există o părere că cloud-urile publice sunt scumpe. Dar ideea lor principală este reducerea cheltuielilor companiei. Așa cum s-a menționat anterior, cloud-urile publice permit obținerea de resurse la cerere și plata doar pentru timpul în care sunt folosite. De asemenea, uneori uităm că angajații primesc salarii, iar specialiștii sunt, de asemenea, o resursă scumpă. Este important de reținut că cloud-urile publice facilitează semnificativ întreținerea infrastructurii, permițând inginerilor să se concentreze pe sarcini mai importante.
Valoarea pentru infrastructura de automatizare
Ce resurse specifice ne sunt necesare pentru teste UI end-to-end? În principal, acestea sunt mașini virtuale sau clustere (vom discuta despre Kubernetes în secțiunea următoare) pentru a rula browsere și emulatori. Cu cât dorim să rulăm mai multe browsere și emulatori simultan, cu atât mai mult CPU și memorie sunt necesare, iar costurile vor crește. Astfel, cloud-urile publice în contextul automatizării testării ne permit să lansăm un număr mare (100, 200, 1000...) de browsere/emulatori la cerere, pentru a obține rezultate ale testelor cât mai repede și pentru a nu mai plăti pentru astfel de resurse extrem de costisitoare.
Cei mai populari furnizori de cloud sunt Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). În ghidul practic sunt prezentate exemple de utilizare a GCP, dar în general nu contează ce anume veți folosi pentru sarcinile de automatizare. Toți oferă cam același set de funcționalități. De obicei, pentru a alege un furnizor, ghidul se concentrează pe întreaga infrastructură a companiei și cerințele de afaceri, ceea ce este dincolo de subiectul acestui articol. Pentru inginerii de automatizare ar fi mai interesant să comparăm utilizarea furnizorilor de cloud cu utilizarea platformelor cloud specifice pentru teste, cum ar fi Sauce Labs, BrowserStack, BitBar și așa mai departe. Așadar, să facem asta! Din punctul meu de vedere, Sauce Labs este cea mai cunoscută fermă de testare în cloud, așa că am ales-o pentru comparație.
GCP vs Sauce Labs pentru scopurile de automatizare:
Să presupunem că trebuie să rulăm simultan 8 teste web și 8 teste Android. Pentru aceasta, vom folosi GCP și vom lansa 2 mașini virtuale cu Selenoid. Pe prima vom ridica 8 containere cu browsere. Pe a doua – 8 containere cu emulatori. Hai să ne uităm la prețuri:
Pentru a lansa un container cu Chrome, avem nevoie de n1-standard-1 mașină. În cazul Android, va fi n1-standard-4 pentru un emulator. De fapt, o metodă mai flexibilă și mai ieftină este stabilirea unor valori personalizate specifice pentru CPU/Memorie, dar în prezent, pentru comparația cu Sauce Labs, acest aspect nu este esențial.
Iată tarifele pentru utilizarea Sauce Labs:
Presupun că ați observat deja diferența, dar voi prezenta totuși un tabel cu calcule pentru sarcina noastră:
Resurse necesare
Lunar
Ore de lucru(8 a.m — 8 p.m)
Ore de lucru+ Preemptible
GCP pentru Web
n1-standard-1 x 8 = n1-standard-8
$194.18
23 de zile * 12h * 0.38 = 104.88$
23 de zile * 12h * 0.08 = 22.08$
Sauce Labs pentru Web
Testări paralele în Cloud Virtual8
$1.559
—
—
GCP pentru Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 de zile * 12h * 1.52 = 419.52$
23 de zile * 12h * 0.32 = 88.32$
Sauce Labs pentru Android
Testări paralele în Real Device Cloud 8
$1.999
—
—
După cum se poate observa, diferența de cost este uriașă, în special dacă testezi doar în intervalul de lucru de 12 ore. Dar poți reduce și mai mult costurile dacă folosești mașini preemptible. Ce sunt acestea?
O VM preemptible este o instanță pe care o poți crea și rula la un preț mult mai mic decât instanțele normale. Totuși, Compute Engine ar putea să termine (preempt) aceste instanțe dacă are nevoie de acces la acele resurse pentru alte sarcini. Instanțele preemptible reprezintă capacitatea excesivă a Compute Engine, așa că disponibilitatea lor variază în funcție de utilizare.
Dacă aplicațiile tale sunt tolerate la erori și pot suporta posibile preemptii ale instanțelor, atunci instanțele preemptible pot reduce semnificativ costurile tale de Compute Engine. De exemplu, lucrările de procesare în loturi pot rula pe instanțe preemptible. Dacă unele dintre acele instanțe sunt terminate în timpul procesării, lucrarea încetinește, dar nu se oprește complet. Instanțele preemptible finalizează sarcinile tale de procesare în loturi fără a pune o sarcină suplimentară pe instanțele tale existente și fără a necesita să plătești prețul întreg pentru instanțe normale adiționale.
Și asta nu este tot! În realitate, sunt sigur că nimeni nu rulează teste timp de 12 ore fără pauză. Și dacă este așa, atunci poți automatiza pornirea și oprirea instanțelor virtuale când nu sunt necesare. Timpul real de utilizare poate scădea la 6 ore pe zi. Atunci, plata în contextul sarcinii noastre ar putea scădea la doar 11$ pe lună pentru 8 browsere. Nu este minunat? Dar cu mașinile preemptible trebuie să fim atenți și pregătiți pentru întreruperi și funcționare instabilă, deși aceste situații pot fi prevăzute și gestionate programatic. Merită!
Dar cu siguranță nu spun 'niciodată nu folosiți ferme de teste cloud'. Acestea au o serie de avantaje. În primul rând, nu este doar o mașină virtuală, ci o soluție completă pentru automatizarea testării, cu un set de funcționalități oferite din cutie: acces de la distanță, jurnalizare, capturi de ecran, înregistrare video, diverse browsere și dispozitive mobile fizice. În multe situații, aceasta poate fi o alternativă extravagantă indispensabilă. În special, platformele de testare sunt utile pentru automatizarea iOS, când cloudurile publice pot oferi doar sisteme Linux/Windows. Dar discuția despre iOS va avea loc în articolele următoare. Recomand întotdeauna să analizăm situația și să ne bazăm pe sarcini: în anumite cazuri, este mai ieftin și mai eficient să folosim clouduri publice, iar în altele, platformele de testare merită cu siguranță banii cheltuiți.
Ilustrarea stării curente a infrastructurii
Linkuri pentru studiu
Instrumente similare:
6. Orchestrare
Descriere scurtă a tehnologiei
Am vești bune – suntem aproape de finalul articolului! În prezent, infrastructura noastră de automatizare constă din teste web și Android, pe care le executăm prin GitLab CI în paralel, folosind instrumente cu suport pentru Docker: Selenium grid și Selenoid. În plus, folosim mașini virtuale create prin GCP pentru a ridica containere cu browsere și simulatoare. Pentru a reduce costurile, activăm aceste mașini virtuale doar la cerere și le oprim când testarea nu este efectuată. Există ceva ce ar putea îmbunătăți infrastructura noastră? Răspunsul este da! O întâmpinăm pe Kubernetes (K8s)!
Pentru început, să analizăm cum sunt legate cuvintele orchestrare, cluster și Kubernetes. La un nivel înalt, orchestrarea este un sistem care desfășoară și gestionează aplicații. Pentru automatizarea testării, aplicațiile containerizabile sunt Selenium grid și Selenoid. Docker și K8s se completează reciproc. Primul este folosit pentru desfășurarea aplicațiilor, iar al doilea – pentru orchestrare. K8s este, în esență, un cluster. Sarcina cluster-ului este de a utiliza VM-uri ca noduri, ceea ce permite instalarea diferitelor funcționalități, programe și servicii într-un singur server (cluster). Dacă vreunul dintre noduri se defectează, alte noduri preiau, asigurând funcționarea neîntreruptă a aplicației noastre. În plus, K8s are funcționalități importante legate de scalare, ceea ce ne oferă automat cantitatea optimă de resurse, bazându-ne pe încărcare și limitele stabilite.
Adevărul este că desfășurarea manuală a Kubernetes de la zero este o sarcină destul de complicată. Voi lăsa un link către binecunoscutul ghid practic „Kubernetes The Hard Way”, iar dacă sunteți interesați, puteți practica. Dar, din fericire, există alternative și instrumente. Cea mai simplă dintre ele este utilizarea Google Kubernetes Engine (GKE) din GCP, ceea ce va permite obținerea unui cluster pregătit după câteva clicuri. Pentru a începe învățarea, recomand să folosiți această abordare, deoarece vă va permite să vă concentrați pe învățarea modului în care să utilizați K8s pentru sarcinile dumneavoastră, în loc să explorați cum trebuie integrate între ele componentele interne.
Valoarea pentru infrastructura de automatizare
Să analizăm câteva funcții semnificative pe care le oferă K8s:
- desfășurarea aplicației: utilizarea unui cluster multi-noduri, în loc de VMs;
- scalarea dinamică: reduce costurile cu resursele utilizate doar la cerere;
- auto-reparare (Self-healing): recuperarea automată a pods (ceea ce duce la recuperarea și containerelor);
- implementarea actualizărilor și reveniri înapoi fără downtime: actualizarea instrumentelor, browserelor și emulatorilor nu întrerupe activitatea utilizatorilor actuali.
Dar K8s nu este încă o soluție ideală. Pentru a înțelege toate avantajele și limitările în contextul instrumentelor discutate (Selenium grid, Selenoid), să discutăm pe scurt structura K8s. Clusterul conține două tipuri de Noduri: Noduri Master și Noduri Worker. Nodurile Master sunt responsabile pentru gestionarea, desfășurarea și deciziile de programare. Nodurile Worker sunt cele în care sunt desfășurate aplicațiile. Nodurile conțin de asemenea mediu de execuție pentru containere. În cazul nostru, acesta este Docker, care se ocupă de operațiile legate de containere. Dar există și soluții alternative, cum ar fi. Este important să înțelegem că scalarea sau auto-repararea nu se referă direct la containere. Acest lucru se realizează prin adăugarea/îndepărtarea numărului de pods, care la rândul lor conțin containere (de obicei un container pe pod, dar în funcție de sarcină poate fi și mai mult). Ierarhia la nivel înalt reprezintă nodurile worker, în interiorul cărora se află pods, în interiorul cărora sunt ridicate containere.
Funcția de scalare este esențială și poate fi aplicată atât la nodurile din pool-ul de noduri al cluster-ului, cât și la pod-uri în interiorul unui nod. Există două tipuri de scalare care se referă atât la noduri, cât și la pod-uri. Primul tip – scalarea orizontală – se realizează prin creșterea numărului de noduri/pod-uri. Acest tip este preferabil. Al doilea tip, respectiv, scalarea verticală. Scalarea se face prin creșterea dimensiunilor nodurilor/pod-urilor, nu prin numărul acestora.
Acum să analizăm instrumentele noastre în contextul termenilor menționați anterior.
Selenium grid
După cum s-a menționat anterior, Selenium grid este un instrument foarte popular, și nu este o surpriză că a fost containerizat. Prin urmare, nu este de mirare că Selenium grid poate fi desfășurat în K8s. Un exemplu de cum se face acest lucru poate fi găsit în depozitul oficial K8s. Așa cum este obișnuința, voi adăuga linkuri la sfârșitul secțiunii. În plus, în ghidul practic este explicat cum se face acest lucru prin Terraform. De asemenea, există instrucțiuni despre cum să scalăm numărul de pod-uri care conțin containere cu browsere. Însă, funcția de scalare automată în contextul K8s este încă o sarcină care nu este pe deplin clară. Când am început studiile, nu am găsit niciun ghid practic sau recomandări. După câteva cercetări și experimente cu suportul echipei DevOps, noi am ales abordarea de a ridica containerele cu browserele necesare într-un singur pod, care se află într-un singur nod lucrător. Această metodă ne permite să aplicăm strategia de scalare orizontală a nodurilor prin creșterea numărului acestora. Sper că în viitor, situația se va schimba și vom vedea din ce în ce mai multe descrieri ale celor mai bune abordări și soluții gata, mai ales după lansarea Selenium grid 4 cu arhitectura internă modificată.
Selenoid:
În prezent, desfășurarea Selenoid în K8s este cea mai mare dezamăgire. Ele nu sunt compatibile. Teoretic, putem ridica un container Selenoid în interiorul unui pod, dar când Selenoid începe să ruleze containere cu browsere, acestea vor rămâne în continuare în interiorul aceluiași pod. Acest lucru face scalarea imposibilă și, ca rezultat, funcționarea Selenoid în cadrul cluster-ului nu va diferi de funcționarea sa într-o mașină virtuală. Sfârșitul poveștii.
Moon:
Știind acest punct slab în utilizarea Selenoid, dezvoltatorii au lansat un instrument mai puternic, pe care l-au numit Moon. Acest instrument a fost inițial gândit pentru a lucra cu Kubernetes și, ca rezultat, se poate și trebuie folosită funcția de autoscalare. Mai mult, aș spune că în prezent este singura instrumentul din lumea Selenium, care are suport pentru cluster K8s nativ din cutie (nu mai este, vezi instrumentul următor ). Caracteristica principală a Moon, care asigură acest suport, este:
Complet fără stare. Selenoid stochează în memorie informații despre sesiunile de browser care rulează în prezent. Dacă dintr-un motiv anume procesul său se blochează — atunci toate sesiunile active sunt pierdute. Moon, în schimb, nu are o stare internă și poate fi replicat între centrele de date. Sesiunile de browser rămân active chiar și dacă una sau mai multe replici cedează.
Deci, Moon este o soluție fantastică, dar cu o problemă: nu este gratuit. Prețul depinde de numărul de sesiuni. Poți rula gratuit doar 0-4 sesiuni, ceea ce nu este foarte util. Dar, începând cu sesiunea a cincea, va trebui să plătești 5$ pentru fiecare. Situația poate varia de la o companie la alta, dar în cazul nostru utilizarea Moon este fără sens. Așa cum am descris mai sus, putem rula VMs cu Selenium Grid la cerere sau putem crește numărul de noduri în cluster. Aproximativ pentru un pipeline rulăm 500 de browsere și oprim toate resursele după finalizarea testelor. Dacă am folosi Moon, ar trebui să plătim 500 x 5 = 2500 $ pe lună, indiferent cât de des rulăm testele. Și din nou, nu spun „nu folosiți Moon”. Pentru nevoile dumneavoastră, ar putea fi o soluție indispensabilă, de exemplu, dacă aveți în organizație multe proiecte/echipe și aveți nevoie de un cluster comun imens pentru toți. Ca de obicei, las un link la final și recomand să faceți toate calculele necesare în contextul sarcinii dumneavoastră.
Callisto: (Atenție! Acest lucru nu se regăsește în articolul original și este conținut doar în traducerea în rusă.)
Așa cum am spus, Selenium este un instrument foarte popular, iar domeniul IT evoluează foarte rapid. În timp ce lucram la traducere, pe internet a apărut un nou instrument promițător numit Callisto (salut Cypress și alți ucigași ai Selenium). Acesta funcționează nativ cu K8s și permite rularea containerelor Selenoid în pods, distribuite pe Nodes. Totul funcționează imediat din cutie, inclusiv scalarea automată. Fantastic, dar trebuie testat. Am reușit deja să implementez acest instrument și să fac câteva experimente. Dar este prea devreme pentru concluzii; după ce obțin rezultatele pe termen lung, este posibil să fac un review în articolele următoare. Până atunci, las doar linkuri pentru cercetări autonome.
Ilustrarea stării curente a infrastructurii
Linkuri pentru studiu
Linkuri pentru studiu
Instrumente similare
7. Infrastructură ca și cod (IaC)
Descriere scurtă a tehnologiei
Și iată că am ajuns la ultima secțiune. De obicei, această tehnologie și sarcinile asociate nu intră în sfera de responsabilitate a inginerilor de automatizare. Și există motive întemeiate pentru asta. În primul rând, în multe organizații, problemele de infrastructură sunt controlate de departamentul DevOps, iar echipele de dezvoltare nu se îngrijesc prea mult de ceea ce face ca pipeline-ul să funcționeze și cum trebuie întreținute toate cele legate de acesta. În al doilea rând, să fim sinceri, practica „Infrastructură ca și cod (IaC)” încă nu este aplicată în multe companii. Dar, fără îndoială, a devenit o tendință populară și este important să ne străduim să fim implicați în procesele, abordările și instrumentele asociate cu aceasta. Sau, cel puțin, să fim la curent cu evenimentele.
Să începem cu motivația pentru utilizarea acestui abordare. Am discutat deja că, pentru a rula teste în GitlabCI, avem nevoie de cel puțin resurse pentru a lansa Gitlab Runner. Iar pentru a rula containere cu browsere/emulatoare, trebuie să rezervăm o VM sau un cluster. Pe lângă resursele pentru testare, avem nevoie de un număr semnificativ de capacități pentru a susține mediile de dezvoltare, staging, production, ceea ce include de asemenea baze de date, programări automate, configurații de rețea, un load balancer, drepturi de utilizator și așa mai departe. Problema cheie constă în eforturile necesare pentru a susține toate acestea. Există mai multe moduri în care putem face modificări și lansa actualizări. De exemplu, în contextul GCP, putem folosi consola UI în browser și efectua toate acțiunile, făcând clic pe butoane. O alternativă poate fi utilizarea apelurilor API pentru a interacționa cu entitățile cloud sau aplicarea utilitarului de linie de comandă gcloud pentru a efectua manipulările necesare. Dar, într-o situație de număr mare de entități și elemente infrastructurale, devine greu sau chiar imposibil să executăm toate operațiunile manual. Mai mult decât atât, toate aceste acțiuni manuale sunt necontrolate. Nu putem să le trimitem la review înainte de execuție, să folosim un sistem de control al versiunilor și să anulăm rapid modificările care au dus la incident. Pentru a rezolva astfel de probleme, inginerii au creat și creează scripturi automate bash/shell, care nu sunt cu mult mai bune decât metodele anterioare, deoarece nu sunt chiar atât de ușor de citit, înțeles, întreținut și modificat în stil procedural.
În acest articol și ghid practic, folosesc 2 unelte care se referă la practica IaC. Acestea sunt Terraform și Ansible. Unii cred că nu are sens să le folosim simultan, deoarece funcționalitățile lor sunt similare și sunt interschimbabile. Dar, de fapt, sarcinile pe care le au inițial sunt complet diferite. Faptul că aceste unelte ar trebui să se completeze reciproc a fost confirmat într-o prezentare comună de către dezvoltatori care reprezintă companiile HashiCorp și RedHat. Diferența conceptuală constă în faptul că Terraform este un instrument de provisioning pentru gestionarea serverelor în sine. În timp ce Ansible este un instrument de management al configurațiilor, având ca sarcină instalarea, configurarea și gestionarea software-ului pe aceste servere.
O altă caracteristică distinctivă importantă a acestor unelte este stilul de scriere a codului. Spre deosebire de bash și Ansible, Terraform folosește un stil declarativ, bazat pe descrierea stării finale dorite, care trebuie atinsă în urma execuției. De exemplu, dacă intenționăm să creăm 10 VMs și să aplicăm modificările prin Terraform, atunci vom obține 10 VMs. Dacă aplicăm din nou scriptul, nu se va întâmpla nimic, deoarece avem deja 10 VMs, iar Terraform știe despre acest lucru, deoarece stochează starea curentă a infrastructurii în fișierul de stare. Pe de altă parte, Ansible folosește o abordare procedurală și, dacă îi cerem să creeze 10 VMs, atunci la prima execuție vom obține 10 VMs, similar cu Terraform. Dar după o re-execuție, vom avea deja 20 VMs. Aceasta este o distincție importantă. În stilul procedural nu stocăm starea curentă și pur și simplu descriem secvența de pași care trebuie urmați. Desigur, putem gestiona diferite situații, putem adăuga câteva verificări privind existența resurselor și starea curentă, dar nu are sens să ne pierdem timpul și să ne străduim să controlăm această logică. În plus, asta crește riscul de a comite greșeli.
Sintezând tot ce s-a spus mai sus, putem concluziona că pentru provisioning-ul serverelor, instrumentul mai potrivit este Terraform și notarea declarativă. Pe de altă parte, gestionarea configurațiilor ar trebui delegată lui Ansible. După ce am înțeles acest lucru, să ne uităm la exemplele de utilizare în contextul automatizării.
Valoarea pentru infrastructura de automatizare
Este important să înțelegem că infrastructura de automatizare a testării trebuie considerată ca parte a întregii infrastructuri a companiei. Asta înseamnă că toate practicile IaC trebuie aplicate global resurselor întregii organizații. Cine este responsabil pentru asta depinde de procesele voastre. Echipa DevOps este mai experimentată în aceste aspecte, deoarece vedem întreaga situație de ansamblu. Cu toate acestea, inginerii QA sunt mai implicați în procesul de construcție a automatizării și structura pipeline-ului, ceea ce le permite să observe mai bine toate modificările necesare și oportunitățile de îmbunătățire. Cel mai bun mod este să colaboreze, să împărtășească cunoștințe și idei pentru a atinge rezultatul dorit.
Iată câteva exemple de utilizare a Terraform și Ansible în contextul automatizării testării și instrumentelor pe care le-am discutat anterior:
1. Să descriem prin Terraform caracteristicile și parametrii necesari pentru VMs și clustere.
2. Să instalăm cu ajutorul Ansible instrumentele necesare pentru testare: docker, Selenoid, Selenium Grid și să încărcăm versiunile corespunzătoare de browsere/emulatoare.
3. Să descriem prin Terraform caracteristicile VM în care va fi rulat GitLab Runner.
4. Să instalăm cu ajutorul Ansible GitLab Runner și instrumentele aferente necesare, să setăm configurațiile și setările.
Ilustrarea stării curente a infrastructurii
Linkuri pentru studiu:
Instrumente similare
Să tragem concluzii!
Pas
Tehnologie
Instrumente
Valoarea pentru infrastructura de automatizare
1
Executare locală
Node.js, Selenium, Appium
- Cele mai populare instrumente pentru web și mobile
- Suport pentru multe limbi și platforme (inclusiv Node.js)
2
Sisteme de control al versiunilor
Git
- Avantaje similare cu codul de dezvoltare
3
Containerizare
Docker, Selenium grid, Selenoid (Web, Android)
- Executarea testelor în paralel
- Mediile izolate
- Actualizări simple și flexibile ale versiunilor
- Oprirea dinamică a resurselor neutilizate
- Ușor de configurat
4
CI / CD
Gitlab CI
- Testele fac parte din pipeline
- Feedback rapid
- Vizibilitate pentru întreaga companie / echipă
5
Platforme cloud
Google Cloud Platform
- Resurse la cerere (plătim doar când sunt necesare)
- Ușor de gestionat și actualizat
- Vizibilitate și control asupra tuturor resurselor
6
Orchestrare
Kubernetes
În contextul containerelor cu browsere/emulatoare în interiorul pods:
- Scalare / auto-scare
- Auto-reparare
- Actualizări și reveniri fără întreruperi
7
Infrastructură ca cod (IaC)
Terraform, Ansible
- Avantaje similare cu infrastructura de dezvoltare
- Toate avantajele versionării codului
- Modificări ușor de realizat și de întreținut
- Complet automatizat
Diagrama hărților mentale: evoluția infrastructurii
pasul 1: Local
pasul 2: VCS
pasul 3: Contenorizare
pasul 4: CI/CD
pasul 5: Platforme Cloud
pasul 6: Orchestrare
pasul 7: IaC
Ce urmează?
Deci, aceasta este sfârșitul articolului. Dar, în concluzie, aș dori să stabilim câteva înțelegeri cu voi.
Din partea voastră
Așa cum am spus la început, mi-ar plăcea ca articolul să fie de folos și să vă ajute să aplicați cunoștințele obținute în activitatea reală. Revin cu.
Dar chiar și după asta, nu vă opriți, exersați, studiați link-urile și cărțile relevante, aflați cum funcționează la voi în companie, găsiți locuri care pot fi îmbunătățite și participați la aceasta. Mult succes!
Din partea mea
Din titlu, este evident că aceasta a fost doar prima parte. Deși a ieșit destul de lungă, încă nu sunt abordate teme importante. În partea a doua, intenționez să discut infrastructura de automatizare în contextul IOS. Din cauza restricțiilor Apple legate de rularea simulatoarelor IOS doar pe sistemele macOS, setul nostru de soluții este restrâns. De exemplu, nu avem posibilitatea de a folosi Docker pentru a rula simulatorul sau cloud-uri publice pentru a lansa mașini virtuale. Dar aceasta nu înseamnă că nu există alte alternative. Voi încerca să vă mențin la curent cu soluțiile de vârf și instrumentele moderne!
De asemenea, nu am menționat teme destul de ample legate de monitorizare. În partea 3, intenționez să discut cele mai populare instrumente pentru monitorizarea infrastructurii, precum și ce date și metrici ar trebui să le luăm în considerare.
Și, în cele din urmă. În viitor, intenționez să lansez un curs video despre construirea infrastructurii de testare și instrumentele sale populare. În prezent, există o mulțime de cursuri și prelegeri online despre DevOps, dar toate materialele sunt prezentate în contextul dezvoltării, nu al automatizării testării. În această privință, am nevoie foarte mult de feedback, dacă un astfel de curs ar fi interesant și valoros pentru comunitatea testerilor și automatizatorilor. Vă mulțumesc anticipat!
Sursa: habr.com
