1. dio: Web / Android
Primijetiti: ovaj članak je prijevod izvornog članka na ruski Međutim, sve ilustracije, poveznice, citati i izrazi sačuvani su na izvornom jeziku kako bi se izbjeglo iskrivljavanje značenja kada se prevode na ruski. Želim ti sretno studiranje!
Trenutno je specijalnost DevOps jedna od najtraženijih u IT industriji. Ako otvorite popularne stranice za traženje poslova i filtrirate prema plaći, vidjet ćete da su poslovi vezani uz DevOps na vrhu popisa. Međutim, važno je razumjeti da se to uglavnom odnosi na 'Senior' poziciju, što podrazumijeva da kandidat ima visoku razinu vještina, znanja o tehnologiji i alatima. Uz to dolazi i visok stupanj odgovornosti povezan s nesmetanim radom proizvodnje. Međutim, počeli smo zaboravljati što je DevOps. U početku to nije bila određena osoba ili odjel. Ako potražimo definicije ovog pojma, naći ćemo mnoge lijepe i točne imenice, kao što su metodologija, prakse, kulturna filozofija, skupina koncepata i tako dalje.
Moja specijalizacija je inženjer automatizacije testiranja (QA automation engineer), ali vjerujem da to ne treba povezivati samo s pisanjem auto-testova ili razvojem arhitekture testnog okvira. U 2020. poznavanje infrastrukture automatizacije također je neophodno. To vam omogućuje da sami organizirate proces automatizacije, od izvođenja testova do pružanja rezultata svim dionicima u skladu s vašim ciljevima. Kao rezultat toga, DevOps vještine su neophodne za obavljanje posla. I sve je to dobro, ali, nažalost, postoji problem (spojler: ovaj članak pokušava pojednostaviti ovaj problem). Poanta je da je DevOps težak. I to je očito, jer tvrtke neće puno platiti za nešto što je lako napraviti... U DevOps svijetu postoji veliki broj alata, pojmova i praksi koje treba savladati. To je posebno teško na početku karijere i ovisi o prikupljenom tehničkom iskustvu.
Izvor:
Ovdje ćemo vjerojatno završiti s uvodnim dijelom i fokusirati se na svrhu ovog članka.
O čemu je ovaj članak?
U ovom ću članku podijeliti svoje iskustvo izgradnje infrastrukture za automatizaciju testiranja. Na Internetu postoji mnogo izvora informacija o raznim alatima i kako ih koristiti, ali ja bih ih želio promatrati isključivo u kontekstu automatizacije. Vjerujem da su mnogi inženjeri automatizacije upoznati sa situacijom kada nitko osim vas ne pokreće razvijene testove niti brine o njihovom održavanju. Kao rezultat toga, testovi postaju zastarjeli i morate trošiti vrijeme na njihovo ažuriranje. Opet, na početku karijere, to može biti prilično težak zadatak: mudro odlučiti koji bi alati trebali pomoći u otklanjanju određenog problema, kako ih odabrati, konfigurirati i održavati. Neki se testeri obraćaju DevOps-u (ljudima) za pomoć i, budimo iskreni, ovaj pristup funkcionira. U mnogim slučajevima ovo može biti jedina opcija budući da nemamo uvid u sve ovisnosti. Ali kao što znamo, DevOps su vrlo zaposleni ljudi, jer moraju razmišljati o infrastrukturi cijele tvrtke, implementaciji, nadzoru, mikroservisima i drugim sličnim zadacima ovisno o organizaciji/timu. Kao što to obično biva, automatizacija nije prioritet. U takvom slučaju moramo pokušati učiniti sve što je moguće s naše strane od početka do kraja. To će smanjiti ovisnosti, ubrzati tijek rada, poboljšati naše vještine i omogućiti nam da vidimo širu sliku onoga što se događa.
Članak predstavlja najpopularnije i najpopularnije alate i pokazuje kako ih koristiti za izgradnju infrastrukture automatizacije korak po korak. Svaka grupa je predstavljena alatima koji su testirani osobnim iskustvom. Ali to ne znači da morate koristiti istu stvar. Sami alati nisu važni, oni se pojavljuju i zastarijevaju. Naš inženjerski zadatak je razumjeti osnovne principe: zašto nam je potrebna ova skupina alata i koje radne probleme možemo riješiti uz njihovu pomoć. Zato na kraju svakog odjeljka ostavljam poveznice na slične alate koji se mogu koristiti u vašoj organizaciji.
Što nije u ovom članku
Još jednom ponavljam da se u članku ne radi o određenim alatima, pa neće biti umetanja koda iz dokumentacije i opisa konkretnih naredbi. Ali na kraju svakog odjeljka ostavljam poveznice za detaljno proučavanje.
Ovo je učinjeno jer:
- ovaj materijal je vrlo lako pronaći u raznim izvorima (dokumentacija, knjige, video tečajevi);
- ako krenemo dublje, morat ćemo napisati 10, 20, 30 dijelova ovog članka (a planovi su 2-3);
- Samo ne želim gubiti vaše vrijeme jer biste možda željeli koristiti druge alate za postizanje istih ciljeva.
Praksa
Stvarno bih želio da ovaj materijal bude koristan svakom čitatelju, a ne samo pročitan i zaboravljen. U svakom studiju praksa je vrlo važna komponenta. Za ovo sam se pripremio. Tu je i domaća zadaća koja vas čeka kako biste bili sigurni da ne kopirate besmisleno retke naredbi koje izvršavate.
plan
Korak
Tehnologija
Alati
1
Lokalno pokretanje (pripremite web/android demo testove i pokrenite ih lokalno)
Node.js, Selenium, Appium
2
Sustavi kontrole verzija
ići
3
Kontejnerizacija
Docker, Selenium mreža, Selenoid (web, Android)
4
CI/CD
Gitlab CI
5
Cloud platforme
Google Cloud Platform
6
orkestracija
Kubernetes
7
Infrastruktura kao šifra (IaC)
Terraform, Ansible
Struktura svakog odjeljka
Kako bi pripovijest bila jasna, svaki odjeljak opisan je prema sljedećem pregledu:
- kratak opis tehnologije,
- vrijednost za infrastrukturu automatizacije,
- prikaz trenutnog stanja infrastrukture,
- poveznice za učenje,
- slični alati.
1. Pokrenite testove lokalno
Kratak opis tehnologije
Ovo je samo pripremni korak za lokalno pokretanje demo testova i provjeru prolaznosti. U praktičnom dijelu koristi se Node.js, no programski jezik i platforma također nisu bitni i možete koristiti one koji se koriste u vašoj tvrtki.
Međutim, kao alate za automatizaciju preporučujem korištenje Selenium WebDrivera za web platforme i Appiuma za Android-platforme, budući da ćemo u sljedećim koracima koristiti Docker slike koje su posebno dizajnirane za rad s tim alatima. Štoviše, prema zahtjevima oglasa za posao, ovi alati su najtraženiji na tržištu.
Kao što ste možda primijetili, gledamo samo web i Android-testovi. Nažalost, iOS je potpuno druga priča (zahvaljujući Appleu). Planiram u budućim člancima demonstrirati rješenja i prakse vezane uz iOS.
Vrijednost za infrastrukturu automatizacije
Iz perspektive infrastrukture, lokalno pokretanje ne daje nikakvu vrijednost. Provjeravate samo izvode li se testovi na lokalnom računalu u lokalnim preglednicima i simulatorima. No, u svakom slučaju, ovo je nužno polazište.
Prikaz trenutnog stanja infrastrukture
Veze za istraživanje
Slični alati
- bilo koji programski jezik koji želite u kombinaciji sa Selenium/Appium testovima;
- bilo koji testovi;
- bilo koji ispitni trkač.
2. Sustavi kontrole verzija (Git)
Kratak opis tehnologije
Nikome neće biti veliko otkriće ako kažem da je kontrola verzija iznimno važan dio razvoja, kako timskog, tako i individualnog. Na temelju raznih izvora, slobodno se može reći da je Git najpopularniji predstavnik. Sustav kontrole verzija pruža mnoge prednosti, kao što je dijeljenje koda, pohranjivanje verzija, vraćanje na prethodne grane, praćenje povijesti projekta i sigurnosne kopije. Nećemo detaljno raspravljati o svakoj točki jer sam siguran da ste dobro upoznati s njom i da je koristite u svom svakodnevnom radu. Ali ako odjednom ne, onda preporučujem pauzu s čitanjem ovog članka i popunjavanje ove praznine što je prije moguće.
Vrijednost za infrastrukturu automatizacije
I ovdje možete postaviti razumno pitanje: “Zašto nam govori o Gitu? Svi to znaju i koriste to i za razvojni kod i za kod za automatsko testiranje.” Bit ćete potpuno u pravu, ali u ovom članku govorimo o infrastrukturi i ovaj odjeljak služi kao pregled za odjeljak 7: “Infrastruktura kao kod (IaC)”. Za nas to znači da je cijela infrastruktura, uključujući testiranje, opisana u obliku koda, tako da i na nju možemo primijeniti sustave verzioniranja i dobiti slične pogodnosti kao kod koda za razvoj i automatizaciju.
Pogledat ćemo detaljnije IaC u koraku 7, ali čak i sada možete početi koristiti Git lokalno stvaranjem lokalnog repozitorija. Opća slika bit će proširena kada infrastrukturi dodamo udaljeni repozitorij.
Prikaz trenutnog stanja infrastrukture
Veze za istraživanje
Slični alati
3. Kontejnerizacija (Docker)
Kratak opis tehnologije
Da bismo pokazali kako je kontejnerizacija promijenila pravila igre, vratimo se u prošlost nekoliko desetljeća. Tada su ljudi kupovali i koristili poslužiteljske strojeve za pokretanje aplikacija. Ali u većini slučajeva potrebni resursi za pokretanje nisu bili unaprijed poznati. Kao rezultat toga, tvrtke su trošile novac na kupnju skupih, moćnih poslužitelja, ali dio tih kapaciteta nije bio u potpunosti iskorišten.
Sljedeći stupanj evolucije bili su virtualni strojevi (VM), koji su riješili problem rasipanja novca na neiskorištene resurse. Ova je tehnologija omogućila pokretanje aplikacija neovisno jedna o drugoj unutar istog poslužitelja, alocirajući potpuno izoliran prostor. Ali, nažalost, svaka tehnologija ima svoje nedostatke. Pokretanje VM-a zahtijeva puni operativni sustav, koji troši CPU, RAM, pohranu i, ovisno o OS-u, potrebno je uzeti u obzir troškove licence. Ti čimbenici utječu na brzinu učitavanja i otežavaju prenosivost.
A sada dolazimo do kontejnerizacije. Još jednom, ova tehnologija rješava prethodni problem, jer spremnici ne koriste puni OS, što oslobađa veliku količinu resursa i pruža brzo i fleksibilno rješenje za prenosivost.
Naravno, tehnologija kontejnerizacije nije ništa novo i prvi put je predstavljena krajem 70-ih. Tada je bilo puno istraživanja, razvoja i eksperimentiranja. Ali Docker je prilagodio ovu tehnologiju i učinio je lako dostupnom masama. Ovih dana, kada govorimo o kontejnerima, uglavnom mislimo na Docker. Kada govorimo o Docker kontejnerima, mislimo na Linux-kontejneri. Možemo koristiti Windows и macOS-sustavi za pokretanje kontejnera, ali važno je razumjeti da to uvodi dodatni sloj. Na primjer, Docker na Macu besprijekorno pokreće kontejnere unutar laganog Linux VM. Vratit ćemo se na ovu temu kada budemo raspravljali o lansiranju. Android- emulatori unutar kontejnera, jer se ovdje pojavljuje vrlo važna nijansa koju je potrebno detaljnije analizirati.
Vrijednost za infrastrukturu automatizacije
Otkrili smo da su kontejnerizacija i Docker cool. Pogledajmo ovo u kontekstu automatizacije, jer svaki alat ili tehnologija trebaju riješiti problem. Istaknimo očite probleme automatizacije testiranja u kontekstu testova korisničkog sučelja:
- ogroman broj ovisnosti pri instaliranju Seleniuma i posebno Appiuma;
- problemi s kompatibilnošću između verzija preglednika, simulatora i upravljačkih programa;
- nedostatak izoliranog prostora za preglednike/simulatore, što je posebno kritično za paralelno pokretanje;
- teško upravljati i održavati ako trebate pokrenuti 10, 50, 100 ili čak 1000 preglednika u isto vrijeme.
Ali budući da je Selenium najpopularniji alat za automatizaciju, a Docker najpopularniji alat za kontejnerizaciju, ne bi trebalo čuditi da ih je netko pokušao kombinirati kako bi stvorio moćan alat za rješavanje gore navedenih problema. Razmotrimo takva rješenja detaljnije.
Selenska mreža u dockeru
Ovaj alat je najpopularniji u Selenium svijetu za pokretanje više preglednika na više računala i njihovo upravljanje s centralnog čvora. Za pokretanje potrebno je registrirati barem dvije komponente: Hub i Node(s). Hub je centralni čvor koji prima sve zahtjeve za testiranje i distribuira ih odgovarajućim čvorovima. Za svaki čvor možemo konfigurirati određene postavke, na primjer, odrediti željeni preglednik i njegovu verziju. Međutim, i dalje moramo osigurati da imamo kompatibilne upravljačke programe preglednika i instalirati ih na potrebne čvorove. Iz tog razloga, Selenium Grid se ne koristi u svom čistom obliku, osim kada trebamo raditi s preglednicima koji se ne mogu instalirati na poslužitelj. Linux OS. Za sve ostale slučajeve, korištenje Docker slika za pokretanje Selenium Grid Huba i Nodesa je znatno fleksibilnije i prikladnije rješenje. Ovaj pristup uvelike pojednostavljuje upravljanje čvorovima, jer možemo odabrati željenu sliku s već instaliranim kompatibilnim verzijama preglednika i upravljačkih programa.
Unatoč negativnim recenzijama o stabilnosti, posebno pri paralelnom pokretanju velikog broja čvorova, Selenium grid je još uvijek najpopularniji alat za paralelno pokretanje Selenium testova. Važno je napomenuti da se u open-sourceu stalno pojavljuju razna poboljšanja i modifikacije ovog alata, čime se bore s raznim uskim grlima.
Selenoid za web
Ovaj je alat otkriće u svijetu Seleniuma jer radi odmah nakon vađenja iz kutije i znatno je olakšao život mnogim inženjerima automatizacije. Prije svega, ovo nije još jedna modifikacija Selenium grida. Umjesto toga, programeri su kreirali potpuno novu verziju Selenium Huba u Golangu, koja je u kombinaciji s laganim Docker slikama za različite preglednike dala poticaj razvoju automatizacije testiranja. Štoviše, u slučaju Selenium Grida moramo unaprijed odrediti sve potrebne preglednike i njihove verzije, što nije problem kada radimo samo s jednim preglednikom. Ali kada se radi o višestrukim podržanim preglednicima, Selenoid je rješenje broj jedan zahvaljujući značajci 'preglednik na zahtjev'. Sve što se od nas traži je unaprijed preuzeti potrebne slike s preglednicima i ažurirati konfiguracijsku datoteku s kojom Selenoid komunicira. Nakon što Selenoid primi zahtjev od testova, automatski će pokrenuti željeni spremnik sa željenim preglednikom. Kada se test završi, Selenoid će povući spremnik, oslobađajući tako resurse za buduće zahtjeve. Ovaj pristup potpuno eliminira dobro poznati problem 'degradacije čvora' s kojim se često susrećemo u Selenium gridu.
Ali, nažalost, Selenoid još uvijek nije srebrni metak. Dobili smo značajku "preglednik na zahtjev", ali značajka "resursi na zahtjev" još uvijek nije dostupna. Da bismo koristili Selenoid, moramo ga implementirati na fizički hardver ili na VM, što znači da moramo unaprijed znati koliko resursa treba dodijeliti. Pretpostavljam da to nije problem za male projekte koji pokreću 10, 20 ili čak 30 preglednika paralelno. Ali što ako nam treba 100, 500, 1000 ili više? Nema smisla stalno održavati i plaćati toliko resursa. U odjeljcima 5 i 6 ovog članka raspravljat ćemo o rješenjima koja vam omogućuju skaliranje, čime značajno smanjuju troškove tvrtke.
Selenoid za Android
Nakon uspjeha Selenoida kao alata za web automatizaciju, ljudi su željeli nešto slično za AndroidI dogodilo se – Selenoid je objavljen uz podršku AndroidIz perspektive korisnika više razine, princip rada sličan je web automatizaciji. Jedina je razlika što umjesto kontejnera temeljenih na pregledniku, Selenoid pokreće kontejnere s Android-emulatori. Po mom mišljenju, ovo je trenutno najmoćniji besplatni alat za pokretanje Android-paralelna testiranja.
Radije ne bih govorio o negativnim aspektima ovog alata, jer mi se jako sviđa. Međutim, i dalje ima iste nedostatke kao i web automatizacija, vezane uz skaliranje. Osim toga, trebao bih spomenuti još jedno ograničenje koje bi moglo biti iznenađenje ako prvi put postavljamo alat. Za pokretanje Android-slike, potreban nam je fizički stroj ili virtualni stroj s podrškom za ugniježđenu virtualizaciju. U praktičnom vodiču pokazujem kako to omogućiti na Linux VM. Međutim, ako ste macOS korisnik i želite lokalno implementirati Selenoid, a zatim pokrenuti Android-testovi će biti nemogući. Ali uvijek možete pokrenuti Linux VM lokalno s konfiguriranom 'ugniježđenom virtualizacijom' i implementacijom Selenoida unutra.
Prikaz trenutnog stanja infrastrukture
U kontekstu ovog članka, dodat ćemo dva alata za ilustraciju infrastrukture: Selenium Grid za web testove i Selenoid za Android-testovi. U GitHub vodiču ću vam također pokazati kako koristiti Selenoid za pokretanje web testova.
Veze za istraživanje
Slični alati
- Postoje i drugi alati za kontejnerizaciju, ali Docker je najpopularniji. Ako želite isprobati nešto drugo, imajte na umu da alati koje smo pokrili za paralelno izvođenje Selenium testova neće raditi odmah.
- Kao što je već rečeno, postoje mnoge modifikacije Selenium grida, npr..
4.CI/CD
Kratak opis tehnologije
Praksa kontinuirane integracije prilično je popularna u razvoju i na razini je sustava kontrole verzija. Unatoč tome, osjećam da postoji zabuna u terminologiji. U ovom odlomku želio bih opisati 3 modifikacije ove tehnologije s moje točke gledišta. Na internetu ćete naći mnogo članaka s različitim tumačenjima i sasvim je normalno da se vaše mišljenje razlikuje. Najvažnije je da ste na istoj strani sa svojim kolegama.
Dakle, postoje 3 pojma: CI - Continuous Integration, CD - Continuous Delivery i opet CD - Continuous Deployment. (U nastavku ću koristiti ove izraze na engleskom jeziku). Svaka izmjena dodaje nekoliko dodatnih koraka vašem razvoju. Ali riječ stalan (kontinuirano) je najvažnija stvar. U ovom kontekstu mislimo na nešto što se događa od početka do kraja, bez prekida ili ručne intervencije. Pogledajmo CI & CD i CD u ovom kontekstu.
- Kontinuirana integracija ovo je početni korak evolucije. Nakon slanja novog koda na poslužitelj, očekujemo brzu povratnu informaciju da su naše promjene u redu. Tipično, CI uključuje pokretanje alata za analizu statičkog koda i jediničnih/internih API testova. To nam omogućuje dobivanje informacija o našem kodu unutar nekoliko sekundi/minuta.
- Kontinuirano isporuke je napredniji korak u kojem izvodimo testove integracije/UI. Međutim, u ovoj fazi ne dobivamo rezultate tako brzo kao s CI. Prvo, ove vrste testova zahtijevaju više vremena da se završe. Drugo, prije pokretanja moramo implementirati naše promjene u testno/scensko okruženje. Štoviše, ako govorimo o mobilnom razvoju, onda se pojavljuje dodatni korak za izradu build-a naše aplikacije.
- Kontinuirano postavljanje pretpostavlja da automatski puštamo naše promjene u proizvodnju ako su svi testovi prihvaćanja prošli u prethodnim fazama. Osim toga, nakon faze izdavanja, možete konfigurirati različite faze, kao što je izvođenje testova dima u proizvodnji i prikupljanje metrike od interesa. Kontinuirana implementacija moguća je samo uz dobru pokrivenost automatiziranim testovima. Ako su potrebni bilo kakvi ručni zahvati, uključujući testiranje, onda to više nije Stalan (stalan). Tada možemo reći da je naš cjevovod u skladu samo s praksom kontinuirane isporuke.
Vrijednost za infrastrukturu automatizacije
U ovom odjeljku trebao bih pojasniti da kada govorimo o end-to-end testovima korisničkog sučelja, to znači da bismo trebali implementirati naše promjene i povezane usluge u testna okruženja. Kontinuirana integracija - proces nije primjenjiv za ovaj zadatak i moramo se pobrinuti za implementaciju barem prakse kontinuirane isporuke. Kontinuirana implementacija također ima smisla u kontekstu testova korisničkog sučelja ako ih namjeravamo izvoditi u proizvodnji.
Prije nego što pogledamo ilustraciju promjene arhitekture, želim reći nekoliko riječi o GitLab CI. Za razliku od drugih CI/CD alata, GitLab nudi udaljeno spremište i mnoge druge dodatne značajke. Stoga je GitLab više od CI-ja. Uključuje upravljanje izvornim kodom, agilno upravljanje, CI/CD cjevovode, alate za bilježenje i prikupljanje metrika odmah po otvaranju. GitLab arhitektura se sastoji od Gitlab CI/CD i GitLab Runner. Evo kratkog opisa sa službene web stranice:
Gitlab CI/CD je web aplikacija s API-jem koja pohranjuje svoje stanje u bazu podataka, upravlja projektima/izgradnjama i pruža korisničko sučelje. GitLab Runner je aplikacija koja obrađuje buildove. Može se zasebno implementirati i radi s GitLab CI/CD putem API-ja. Za izvođenje testova potrebni su vam Gitlab instanca i Runner.
Prikaz trenutnog stanja infrastrukture
Veze za istraživanje
Slični alati
- I mnogi drugi
5. Cloud platforme
Kratak opis tehnologije
U ovom dijelu govorit ćemo o popularnom trendu koji se zove 'javni oblaci'. Unatoč golemim prednostima koje gore opisane tehnologije virtualizacije i kontejnerizacije pružaju, još uvijek su nam potrebni računalni resursi. Tvrtke kupuju skupe servere ili iznajmljuju podatkovne centre, no u tom slučaju potrebno je napraviti kalkulacije (ponekad nerealne) koliko će nam resursa trebati, hoćemo li ih koristiti 24/7 i u koje svrhe. Na primjer, produkcija zahtijeva poslužitelj koji radi XNUMX/XNUMX, no trebaju li nam slični resursi za testiranje izvan radnog vremena? Također ovisi o vrsti testiranja koje se provodi. Primjer bi bili testovi opterećenja/stresa koje planiramo provesti u neradno vrijeme kako bismo dobili rezultate sljedeći dan. Ali definitivno dostupnost poslužitelja XNUMX/XNUMX nije potrebna za end-to-end automatizirane testove, a pogotovo ne za okruženja za ručno testiranje. Za takve situacije bilo bi dobro nabaviti onoliko resursa koliko je potrebno na zahtjev, koristiti ih i prestati plaćati kada više nisu potrebni. Štoviše, bilo bi sjajno primiti ih odmah s nekoliko klikova mišem ili pokretanjem nekoliko skripti. To je ono za što se koriste javni oblaci. Pogledajmo definiciju:
“Javni oblak definira se kao računalne usluge koje nude davatelji trećih strana putem javnog interneta, čineći ih dostupnima svima koji ih žele koristiti ili kupiti. Mogu biti besplatni ili prodani na zahtjev, omogućujući korisnicima da plate samo po korištenju za CPU cikluse, pohranu ili propusnost koju troše."
Postoji mišljenje da su javni oblaci skupi. Ali njihova je ključna ideja smanjiti troškove tvrtke. Kao što je ranije spomenuto, javni oblaci vam omogućuju da dobijete resurse na zahtjev i plaćate samo za vrijeme koje ih koristite. Također, ponekad zaboravimo da zaposlenici primaju plaće, a stručnjaci su također skup resurs. Mora se uzeti u obzir da javni oblaci znatno olakšavaju infrastrukturnu podršku, što omogućuje inženjerima da se usredotoče na važnije zadatke.
Vrijednost za infrastrukturu automatizacije
Koji su nam specifični resursi potrebni za end-to-end testove korisničkog sučelja? U osnovi su to virtualni strojevi ili klasteri (o Kubernetesu ćemo govoriti u sljedećem odjeljku) za pokretanje preglednika i emulatora. Što više preglednika i emulatora želimo pokrenuti istovremeno, potrebno je više procesora i memorije i više novca moramo platiti za to. Dakle, javni oblaci u kontekstu automatizacije testiranja omogućuju nam pokretanje velikog broja (100, 200, 1000...) preglednika/emulatora na zahtjev, dobivanje rezultata testiranja što je brže moguće i prestanak plaćanja za tako suludo zahtjevne resurse vlast.
Najpopularniji pružatelji usluga u oblaku su Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Vodič s uputama pruža primjere kako koristiti GCP, ali općenito nije važno što koristite za zadatke automatizacije. Svi oni pružaju približno istu funkcionalnost. Obično se pri odabiru pružatelja uprava usredotočuje na cjelokupnu infrastrukturu i poslovne zahtjeve tvrtke, što je izvan opsega ovog članka. Za inženjere automatizacije bit će zanimljivije usporediti korištenje pružatelja usluga oblaka s korištenjem platformi u oblaku posebno u svrhu testiranja, kao što su Sauce Labs, BrowserStack, BitBar i tako dalje. Pa učinimo i mi to! Po mom mišljenju, Sauce Labs je najpoznatija farma za testiranje oblaka, zbog čega sam ga koristio za usporedbu.
GCP u odnosu na Sauce Labs za potrebe automatizacije:
Zamislimo da trebamo pokrenuti 8 web testova i 8 testova istovremeno. Android-testovi. Za to ćemo koristiti GCP i pokrenuti dva virtualna stroja sa Selenoidom. Na prvom ćemo pokrenuti osam kontejnera preglednika. Na drugom osam kontejnera emulatora. Pogledajmo cijene:
Da bismo pokrenuli jedan spremnik s Chromeom, trebamo n1-standard-1 automobil. U slučaju Android bit će n1-standard-4 za jedan emulator. Zapravo, fleksibilniji i jeftiniji način je postavljanje specifičnih korisničkih vrijednosti za CPU/memoriju, ali to trenutno nije važno za usporedbu sa Sauce Labs.
A evo i tarifa za korištenje Sauce Labsa:
Vjerujem da ste već primijetili razliku, ali ipak ću dati tablicu s izračunima za naš zadatak:
Potrebni resursi
Mjesečno
Radni sati(8 - 8 sati)
Radni sati+mogućnost preuzimanja
GCP za web
n1-standard-1 x 8 = n1-standard-8
$194.18
23 dana * 12 sati * 0.38 = 104.88 USD
23 dana * 12 sati * 0.08 = 22.08 USD
Sauce Labs za web
Virtualni Cloud8 paralelni testovi
$1.559
-
-
GCP za Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 dana * 12 sati * 1.52 = 419.52 USD
23 dana * 12 sati * 0.32 = 88.32$
Sauce Labs za Android
Real Device Cloud 8 paralelni testovi
$1.999
-
-
Kao što vidite, razlika u cijeni je ogromna, pogotovo ako testove izvodite samo tijekom dvanaestosatnog radnog vremena. Ali možete još više smanjiti troškove ako koristite strojeve s mogućnošću preopterećenja. Što je?
Preemptiable VM je instanca koju možete izraditi i pokrenuti po puno nižoj cijeni od normalnih instanci. Međutim, Compute Engine može prekinuti (preuzeti) ove instance ako zahtijeva pristup tim resursima za druge zadatke. Preemptibilne instance su višak kapaciteta Compute Enginea, pa njihova dostupnost ovisi o upotrebi.
Ako su vaše aplikacije tolerantne na greške i mogu izdržati moguća prioritetna instanca, tada prednostne instance mogu značajno smanjiti vaše troškove Compute Enginea. Na primjer, poslovi skupne obrade mogu se izvoditi na instancama koje se mogu preskočiti. Ako neke od tih instanci prekinu tijekom obrade, posao se usporava, ali se ne zaustavlja u potpunosti. Preemptibilne instance dovršavaju vaše zadatke skupne obrade bez dodatnog opterećenja vaših postojećih instanci i bez potrebe da platite punu cijenu za dodatne normalne instance.
I to nije kraj! Zapravo, siguran sam da nitko ne izvodi testove 12 sati bez prestanka. A ako je to slučaj, možete automatski pokretati i zaustavljati virtualne strojeve kada nisu potrebni. Stvarna upotreba mogla bi pasti na 6 sati dnevno. Tada bi, za naše potrebe, račun pao na 11$ mjesečno za 8 preglednika. Nije li to divno? Ali s preemptabilnim strojevima moramo biti oprezni i spremni na prekide i nestabilnost, iako se te situacije mogu predvidjeti i programski riješiti. Vrijedi!
Ali nipošto ne kažem 'nikada ne koristite farme za testiranje u oblaku'. Imaju niz prednosti. Prije svega, nisu samo virtualni stroj, već potpuno rješenje za automatizaciju testiranja s nizom značajki koje su odmah dostupne: udaljeni pristup, zapisnici, snimke zaslona, snimanje videa, razni preglednici i fizički mobilni uređaji. U mnogim situacijama ovo može biti nezamjenjiva, luksuzna alternativa. Platforme za testiranje posebno su korisne za automatizaciju iOS-a, gdje javni oblaci mogu ponuditi samo Linux/Windows-sustavi. Ali o iOS-u ćemo raspravljati u budućim člancima. Preporučujem da uvijek procijenite situaciju i usredotočite se na potrebe: u nekim slučajevima javni oblaci su jeftiniji i učinkovitiji, dok se u drugima u testne platforme definitivno isplati uložiti.
Prikaz trenutnog stanja infrastrukture
Veze za istraživanje
Slični alati:
6. Orkestracija
Kratak opis tehnologije
Imam dobre vijesti – gotovo smo na kraju ovog članka! Trenutno se naša infrastruktura za automatizaciju sastoji od weba i AndroidTestove provodimo paralelno putem GitLab CI-ja koristeći Docker-omogućene alate: Selenium grid i Selenoid. Nadalje, koristimo virtualne strojeve kreirane putem GCP-a za pokretanje kontejnera s preglednicima i emulatorima. Kako bismo smanjili troškove, ove virtualne strojeve pokrećemo samo na zahtjev i isključujemo ih kada ne testiramo. Postoji li još nešto što bi moglo poboljšati našu infrastrukturu? Odgovor je da! Dobrodošli u Kubernetes (K8s)!
Prvo, pogledajmo kako su riječi orkestracija, klaster i Kubernetes povezane jedna s drugom. Na visokoj razini, orkestracija je sustav koji postavlja i upravlja aplikacijama. Za automatizaciju testiranja, takve kontejnerske aplikacije su Selenium grid i Selenoid. Docker i K8s se nadopunjuju. Prvi se koristi za implementaciju aplikacije, drugi za orkestraciju. Zauzvrat, K8s je klaster. Zadaća klastera je korištenje VM-ova kao čvorova, što omogućuje instaliranje raznih funkcionalnosti, programa i servisa unutar jednog poslužitelja (klastera). Ako bilo koji od čvorova zakaže, drugi će se čvorovi pokupiti, što osigurava nesmetan rad naše aplikacije. Osim toga, K8s ima važnu funkcionalnost vezanu uz skaliranje, zahvaljujući kojoj automatski dobivamo optimalnu količinu resursa na temelju opterećenja i postavljenih ograničenja.
Istina, ručna implementacija Kubernetesa od nule uopće nije trivijalan zadatak. Ostavit ću poveznicu na poznati vodič s uputama "Kubernetes The Hard Way" i ako ste zainteresirani, možete ga vježbati. Ali, na sreću, postoje alternativne metode i alati. Najlakši način je koristiti Google Kubernetes Engine (GKE) u GCP-u, koji će vam omogućiti da dobijete gotov klaster u nekoliko klikova. Preporučam korištenje ovog pristupa za početak učenja, jer će vam omogućiti da se usredotočite na učenje kako koristiti K8s za svoje zadatke umjesto da naučite kako unutarnje komponente trebaju biti međusobno integrirane.
Vrijednost za infrastrukturu automatizacije
Pogledajmo nekoliko značajnih značajki koje K8s pruža:
- implementacija aplikacije: korištenje klastera s više čvorova umjesto VM-ova;
- dinamičko skaliranje: smanjuje troškove resursa koji se koriste samo na zahtjev;
- samoizlječenje: automatsko obnavljanje mahuna (kao rezultat čega se obnavljaju i spremnici);
- uvođenje ažuriranja i vraćanje promjena bez prekida rada: ažuriranje alata, preglednika i emulatora ne prekida rad trenutnih korisnika
Ali K8s još uvijek nije srebrni metak. Da bismo razumjeli sve prednosti i ograničenja u kontekstu alata koje razmatramo (Selenium grid, Selenoid), ukratko ćemo razmotriti strukturu K8s. Klaster sadrži dvije vrste čvorova: glavne čvorove i radne čvorove. Glavni čvorovi odgovorni su za upravljanje, implementaciju i odluke o rasporedu. Radnički čvorovi su mjesta gdje se pokreću aplikacije. Čvorovi također sadrže runtime okruženje spremnika. U našem slučaju, to je Docker, koji je odgovoran za operacije vezane uz kontejner. Ali postoje i alternativna rješenja, npr. Važno je razumjeti da se stvaranje kamenca ili samozacjeljivanje ne odnosi izravno na posude. Ovo se provodi dodavanjem/smanjenjem broja mahuna, koje zauzvrat sadrže spremnike (obično jedan spremnik po mahuni, ali ovisno o zadatku može ih biti više). Hijerarhija visoke razine sastoji se od radnih čvorova unutar kojih se nalaze podovi unutar kojih se podižu spremnici.
Značajka skaliranja je ključna i može se primijeniti na oba čvora unutar skupa čvorova klastera i podove unutar čvora. Postoje 2 vrste skaliranja koje se primjenjuju i na čvorove i na podove. Prvi tip je vodoravni - skaliranje se događa povećanjem broja čvorova/podova. Ova vrsta je poželjnija. Drugi tip je, prema tome, okomit. Skaliranje se provodi povećanjem veličine čvorova/podova, a ne njihovog broja.
Sada pogledajmo naše alate u kontekstu gornjih pojmova.
Selenska rešetka
Kao što je ranije spomenuto, Selenium grid je vrlo popularan alat i nije iznenađenje da je kontejneriziran. Stoga ne čudi da se Selenium grid može implementirati u K8s. Primjer kako to učiniti može se pronaći u službenom repozitoriju K8s. Kao i obično, prilažem poveznice na kraju odjeljka. Osim toga, vodič s uputama pokazuje kako to učiniti u Terraformu. Postoje i upute o tome kako skalirati broj podova koji sadrže spremnike preglednika. Ali funkcija automatskog skaliranja u kontekstu K8s još uvijek nije posve očita zadaća. Kad sam počeo učiti, nisam našao nikakve praktične upute ili preporuke. Nakon nekoliko studija i eksperimenata uz podršku DevOps tima, odabrali smo pristup podizanja spremnika s potrebnim preglednicima unutar jednog pod-a koji se nalazi unutar jednog radnog čvora. Ova metoda nam omogućuje primjenu strategije horizontalnog skaliranja čvorova povećanjem njihovog broja. Nadam se da će se to promijeniti u budućnosti i da ćemo vidjeti sve više opisa boljih pristupa i gotovih rješenja, pogotovo nakon izlaska Selenium grida 4 s promijenjenom internom arhitekturom.
Selenoid:
Implementacija selenoida u K8 trenutno je najveće razočaranje. Nisu kompatibilni. U teoriji, možemo podignuti Selenoid kontejner unutar modula, ali kada Selenoid počne pokretati spremnike s preglednicima, oni će i dalje biti unutar istog modula. To onemogućuje skaliranje i, kao rezultat toga, rad Selenoida unutar klastera neće se razlikovati od rada unutar virtualnog stroja. Kraj priče.
Mjesec:
Znajući za ovo usko grlo u radu sa Selenoidom, programeri su izdali moćniji alat pod nazivom Moon. Ovaj je alat izvorno dizajniran za rad s Kubernetesom i, kao rezultat toga, značajka automatskog skaliranja može se i treba koristiti. Štoviše, rekao bih da u ovom trenutku jest jedini alat u svijetu Seleniuma, koji ima nativnu podršku za K8s klaster odmah po otvaranju (više nije dostupan, pogledajte sljedeći alat ). Ključne značajke Moona koje pružaju ovu podršku su:
Potpuno bez državljanstva. Selenoid pohranjuje u memoriju informacije o trenutno pokrenutim sesijama preglednika. Ako se iz nekog razloga njegov proces sruši — tada se gube sve pokrenute sesije. Naprotiv, Moon nema unutarnje stanje i može se replicirati u podatkovnim centrima. Sesije preglednika ostaju aktivne čak i ako se jedna ili više replika pokvari.
Dakle, Moon je odlično rješenje, ali postoji jedan problem: nije besplatno. Cijena ovisi o broju termina. Možete pokrenuti samo 0-4 sesije besplatno, što nije posebno korisno. No, počevši od pete sesije, morat ćete platiti 5 USD za svaku. Situacija se može razlikovati od tvrtke do tvrtke, ali u našem slučaju korištenje Moona je besmisleno. Kao što sam gore opisao, možemo pokrenuti VM sa Selenium Gridom na zahtjev ili povećati broj čvorova u klasteru. Za približno jedan cjevovod pokrećemo 500 preglednika i zaustavljamo sve resurse nakon završetka testova. Ako bismo koristili Moon, morali bismo platiti dodatnih 500 x 5 = 2500 dolara mjesečno, bez obzira koliko često provodimo testove. Opet, ne kažem da ne koristite Moon. Za vaše zadatke, ovo može biti nezamjenjivo rješenje, na primjer, ako imate mnogo projekata/timova u svojoj organizaciji i trebate veliki zajednički klaster za sve. Kao i uvijek, ostavljam vezu na kraju i preporučam da napravite sve potrebne izračune u kontekstu vašeg zadatka.
Kalisto: (Pažnja! Ovoga nema u izvornom članku i sadržano je samo u ruskom prijevodu)
Kao što sam rekao, Selenium je vrlo popularan alat, a IT polje se vrlo brzo razvija. Dok sam radio na prijevodu, na webu se pojavio novi obećavajući alat pod nazivom Callisto (pozdrav Cypressu i ostalim ubojicama selena). Izvorno radi s K8 i omogućuje vam pokretanje Selenoid spremnika u podovima, raspoređenih po čvorovima. Sve radi odmah po izlasku iz kutije, uključujući automatsko skaliranje. Fantastično, ali treba ga isprobati. Već sam uspio implementirati ovaj alat i pokrenuti nekoliko eksperimenata. Ali prerano je donositi zaključke, nakon što dobijem rezultate na velikoj udaljenosti, možda ću napraviti pregled u budućim člancima. Za sada ostavljam samo linkove za samostalno istraživanje.
Prikaz trenutnog stanja infrastrukture
Veze za istraživanje
Slični alati
7. Infrastruktura kao kod (IaC)
Kratak opis tehnologije
I sada dolazimo do posljednjeg dijela. Obično ova tehnologija i srodni zadaci nisu odgovornost inženjera automatizacije. I za to postoje razlozi. Prvo, u mnogim su organizacijama pitanja infrastrukture pod kontrolom DevOps odjela, a razvojni timovi zapravo ne mare za to što cjevovod funkcionira i kako treba podržati sve što je s njim povezano. Drugo, budimo iskreni, praksa Infrastrukture kao kodeksa (IaC) još uvijek nije usvojena u mnogim tvrtkama. Ali definitivno je postao popularan trend i važno je pokušati biti uključen u procese, pristupe i alate povezane s njim. Ili barem ostanite u toku.
Počnimo s motivacijom za korištenje ovog pristupa. Već smo razgovarali o tome da će nam za pokretanje testova u GitlabCI-ju trebati barem resursi za pokretanje Gitlab Runnera. A da bismo pokrenuli spremnike s preglednicima/emulatorima, moramo rezervirati VM ili klaster. Uz resurse za testiranje, potrebna nam je značajna količina kapaciteta za podršku razvojnim, scenskim i produkcijskim okruženjima, što također uključuje baze podataka, automatske rasporede, mrežne konfiguracije, balansere opterećenja, korisnička prava i tako dalje. Ključno pitanje je napor potreban da se sve to podrži. Postoji nekoliko načina na koje možemo napraviti promjene i uvesti ažuriranja. Na primjer, u kontekstu GCP-a, možemo koristiti UI konzolu u pregledniku i izvršavati sve radnje klikom na gumbe. Alternativa bi bila korištenje API poziva za interakciju s entitetima u oblaku ili korištenje uslužnog programa naredbenog retka gcloud za izvođenje željenih manipulacija. Ali sa stvarno velikim brojem različitih entiteta i infrastrukturnih elemenata, postaje teško ili čak nemoguće izvršiti sve operacije ručno. Štoviše, sve te ručne radnje ne mogu se kontrolirati. Ne možemo ih poslati na pregled prije izvršenja, koristiti sustav kontrole verzija i brzo vratiti promjene koje su dovele do incidenta. Kako bi riješili takve probleme, inženjeri su kreirali i stvaraju automatske bash/shell skripte, koje nisu puno bolje od prethodnih metoda, budući da ih nije tako lako brzo pročitati, razumjeti, održavati i modificirati u proceduralnom stilu.
U ovom članku i vodiču s uputama koristim 2 alata povezana s IaC praksom. To su Terraform i Ansible. Neki ljudi vjeruju da ih nema smisla koristiti u isto vrijeme, jer su njihove funkcionalnosti slične i međusobno su zamjenjive. Ali činjenica je da im se u početku daju potpuno drugačiji zadaci. A da bi se ovi alati trebali nadopunjavati potvrdili su na zajedničkoj prezentaciji programeri koji predstavljaju HashiCorp i RedHat. Konceptualna razlika je u tome što je Terraform alat za pružanje usluga za upravljanje samim poslužiteljima. Dok je Ansible alat za upravljanje konfiguracijom čiji je zadatak instalirati, konfigurirati i upravljati softverom na tim poslužiteljima.
Druga ključna značajka razlikovanja ovih alata je stil kodiranja. Za razliku od basha i Ansiblea, Terraform koristi deklarativni stil temeljen na opisu željenog krajnjeg stanja koje treba postići kao rezultat izvršenja. Na primjer, ako ćemo kreirati 10 VM-ova i primijeniti promjene kroz Terraform, tada ćemo dobiti 10 VM-ova. Ako ponovno pokrenemo skriptu, ništa se neće dogoditi jer već imamo 10 VM-ova, a Terraform zna za to jer pohranjuje trenutno stanje infrastrukture u datoteku stanja. Ali Ansible koristi proceduralni pristup i, ako tražite da stvori 10 VM-ova, tada ćemo pri prvom pokretanju dobiti 10 VM-ova, slično Terraformu. Ali nakon ponovnog pokretanja već ćemo imati 20 VM-ova. Ovo je bitna razlika. U proceduralnom stilu, ne pohranjujemo trenutno stanje i jednostavno opisujemo niz koraka koji se moraju izvršiti. Naravno, možemo rješavati razne situacije, dodati nekoliko provjera postojanja resursa i trenutnog stanja, ali nema smisla gubiti vrijeme i truditi se kontrolirati ovu logiku. Osim toga, time se povećava rizik od pogrešaka.
Rezimirajući sve navedeno, možemo zaključiti da su Terraform i deklarativna notacija prikladniji alat za pružanje poslužitelja. Ali bolje je delegirati posao upravljanja konfiguracijom Ansibleu. Uklonivši to s puta, pogledajmo slučajeve upotrebe u kontekstu automatizacije.
Vrijednost za infrastrukturu automatizacije
Jedina važna stvar koju ovdje treba razumjeti jest da se infrastruktura za automatizaciju testiranja treba smatrati dijelom cjelokupne infrastrukture tvrtke. To znači da se sve prakse IAC-a moraju globalno primijeniti na resurse cijele organizacije. Tko je za to odgovoran ovisi o vašim procesima. DevOps tim je iskusniji u ovim pitanjima, oni vide cijelu sliku onoga što se događa. Međutim, QA inženjeri su više uključeni u proces automatizacije zgrade i strukturu cjevovoda, što im omogućuje da bolje vide sve potrebne promjene i prilike za poboljšanje. Najbolja opcija je zajednički rad, razmjena znanja i ideja kako bi se postigao očekivani rezultat.
Evo nekoliko primjera korištenja Terraforma i Ansiblea u kontekstu automatizacije testiranja i alata o kojima smo prije govorili:
1. Opišite potrebne karakteristike i parametre VM-ova i klastera koji koriste Terraform.
2. Koristeći Ansible instalirati alate potrebne za testiranje: docker, Selenoid, Selenium Grid i preuzeti potrebne verzije preglednika/emulatora.
3. Koristeći Terraform, opišite karakteristike VM-a u kojem će se pokrenuti GitLab Runner.
4. Instalirajte GitLab Runner i potrebne popratne alate koristeći Ansible, postavite postavke i konfiguracije.
Prikaz trenutnog stanja infrastrukture
Veze za istraživanje:
Slični alati
Sažmimo to!
Korak
Tehnologija
Alati
Vrijednost za infrastrukturu automatizacije
1
Lokalno trčanje
Node.js, Selenium, Appium
- Najpopularniji alati za web i mobitel
- Podržava mnoge jezike i platforme (uključujući Node.js)
2
Sustavi kontrole verzija
ići
- Slične prednosti s razvojnim kodom
3
Kontejnerizacija
Docker, Selenium mreža, Selenoid (web, Android)
- Paralelno izvođenje testova
- Izolirana okruženja
- Jednostavne, fleksibilne nadogradnje verzija
- Dinamičko zaustavljanje neiskorištenih resursa
- Jednostavno postavljanje
4
CI/CD
Gitlab CI
- Ispituje dio cjevovoda
- Brze povratne informacije
- Vidljivost za cijelu tvrtku/tim
5
Cloud platforme
Google Cloud Platform
- Resursi na zahtjev (plaćamo samo kada je potrebno)
- Jednostavan za upravljanje i ažuriranje
- Preglednost i kontrola svih resursa
6
orkestracija
Kubernetes
U kontekstu spremnika s preglednicima/emulatorima unutar podova:
- Skaliranje/automatsko skaliranje
- Samoizlječenje
- Ažuriranja i vraćanja bez prekida
7
Infrastruktura kao šifra (IaC)
Terraform, Ansible
- Slične prednosti s razvojnom infrastrukturom
- Sve prednosti verzije koda
- Lako se mijenjaju i održavaju
- Potpuno automatizirano
Dijagrami umnih mapa: evolucija infrastrukture
korak 1: Lokalno
korak 2: VCS
korak 3: Kontejnerizacija
korak 4: CI/CD
korak 5: Cloud Platforme
korak 6: Orkestracija
korak 7: IaC
Što je sljedeće?
Dakle, ovo je kraj članka. Ali u zaključku, želio bih uspostaviti neke dogovore s vama.
S tvoje strane
Kao što je rečeno na početku, želio bih da članak bude od praktične koristi i da vam pomogne u primjeni stečenog znanja u stvarnom radu. Opet dodajem.
Ali ni nakon toga nemojte stati, vježbajte, proučavajte relevantne linkove i knjige, saznajte kako to funkcionira u vašoj tvrtki, pronađite mjesta koja se mogu poboljšati i sudjelujte u tome. Sretno!
S moje strane
Kao što naslov sugerira, ovo je bio samo prvi dio. Iako je prilično dug, još uvijek ne pokriva važne teme. U drugom dijelu planiram ispitati infrastrukturu automatizacije u kontekstu iOS-a. Zbog Appleovih ograničenja u vezi s pokretanjem iOS simulatora samo na macOS U sustavima je naš skup rješenja ograničen. Na primjer, ne možemo koristiti Docker za pokretanje simulatora ili javne oblake za pokretanje virtualnih strojeva. Ali to ne znači da ne postoje druge alternative. Pokušat ću vas obavještavati o najsuvremenijim rješenjima i modernim alatima!
Također, nisam spomenuo dosta velike teme vezane uz monitoring. U 3. dijelu pogledat ću najpopularnije alate za praćenje infrastrukture te koje podatke i metrike treba uzeti u obzir.
I konačno. U budućnosti planiram objaviti videotečaj o izgradnji testne infrastrukture i popularnih alata. Trenutno postoji dosta tečajeva i predavanja o DevOpsu na Internetu, ali svi materijali su predstavljeni u kontekstu razvoja, a ne automatizacije testiranja. Po ovom pitanju stvarno trebam povratnu informaciju o tome hoće li takav tečaj biti zanimljiv i vrijedan za zajednicu testera i inženjera automatizacije. Hvala unaprijed!
Izvor: www.habr.com
