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
alat
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 grid, 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 WebDriver za web platforme i Appium za Android platformu, budući da ćemo u sljedećim koracima koristiti Docker slike koje su posebno prilagođene za rad s ovim alatima. Štoviše, s obzirom na zahtjeve posla, ovi su alati najtraženiji na tržištu.
Kao što ste možda primijetili, uzimamo u obzir samo web i Android testove. Nažalost, iOS je sasvim druga priča (hvala Apple). Planiram predstaviti rješenja i prakse vezane uz IOS u nadolazećim dijelovima.
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 kasnih 70-ih. U to vrijeme provedeno je mnogo istraživanja, razvoja i pokušaja. Ali Docker je bio taj koji je prilagodio ovu tehnologiju i učinio je lako dostupnom masama. Danas, kada govorimo o kontejnerima, u većini slučajeva mislimo na Docker. Kada govorimo o Docker kontejnerima, mislimo na Linux kontejnere. Za pokretanje kontejnera možemo koristiti Windows i macOS sustave, ali važno je razumjeti da se u tom slučaju pojavljuje dodatni sloj. Na primjer, Docker na Macu tiho pokreće spremnike unutar laganog Linux VM-a. Vratit ćemo se ovoj temi kada budemo raspravljali o pokretanju Android emulatora unutar spremnika, tako da ovdje postoji vrlo važna nijansa o kojoj treba detaljnije razgovarati.
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 je alat najpopularniji u svijetu Selenium za pokretanje više preglednika na više strojeva i upravljanje njima iz središnjeg čvorišta. Za početak morate registrirati najmanje 2 dijela: Hub i Node(s). Hub je središnji čvor koji prima sve zahtjeve od testova i distribuira ih odgovarajućim čvorovima. Za svaki čvor možemo konfigurirati određenu konfiguraciju, na primjer, navođenjem željenog preglednika i njegove verzije. Međutim, i dalje se moramo sami pobrinuti za kompatibilne upravljačke programe preglednika i instalirati ih na željene čvorove. Zbog toga se Selenium grid ne koristi u svom čistom obliku, osim kada trebamo raditi s preglednicima koji se ne mogu instalirati na Linux OS. Za sve druge slučajeve, značajno fleksibilno i ispravno rješenje bilo bi korištenje Docker slika za pokretanje Selenium grid Huba i čvorova. Ovaj pristup uvelike pojednostavljuje upravljanje čvorom, budući da možemo odabrati sliku koja nam je potrebna s kompatibilnim verzijama preglednika i već instaliranih 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 htjeli nešto slično za Android. I to se dogodilo - Selenoid je izdan s Android podrškom. Sa stajališta korisnika na visokoj razini, princip rada sličan je web automatizaciji. Jedina je razlika u tome što umjesto spremnika preglednika Selenoid pokreće spremnike Android emulatora. Po mom mišljenju, ovo je trenutno najmoćniji besplatni alat za paralelno pokretanje Android testova.
Ne bih želio govoriti o negativnim aspektima ovog alata, jer mi se stvarno sviđa. Ipak, postoje isti nedostaci koji se odnose na web automatizaciju i povezani su sa skaliranjem. Uz ovo, moramo govoriti o još jednom ograničenju koje može biti iznenađenje ako alat postavljamo prvi put. Za pokretanje Android slika potreban nam je fizički stroj ili VM s podrškom za ugniježđenu virtualizaciju. U vodiču s uputama pokazujem kako to omogućiti na Linux VM-u. Međutim, ako ste korisnik macOS-a i želite lokalno implementirati Selenoid, to neće biti moguće za pokretanje Android testova. Ali uvijek možete pokrenuti Linux VM lokalno s konfiguriranom 'ugniježđenom virtualizacijom' i implementirati Selenoid unutra.
Prikaz trenutnog stanja infrastrukture
U kontekstu ovog članka, dodat ćemo 2 alata za ilustraciju infrastrukture. To su Selenium grid za web testove i Selenoid za Android testove. U vodiču za GitHub također ću vam 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 moramo pokrenuti 8 web testova i 8 Android testova istovremeno. Za ovo ćemo koristiti GCP i pokrenuti 2 virtualna računala sa Selenoidom. Na prvom ćemo podići 8 kontejnera s preglednicima. Na drugom se nalazi 8 spremnika s emulatorima. Pogledajmo cijene:
Da bismo pokrenuli jedan spremnik s Chromeom, trebamo n1-standard-1 automobil. U slučaju Androida 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 USD
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 još uvijek nije gotovo! U stvarnosti, siguran sam da nitko ne izvodi testove 12 sati bez pauze. A ako je tako, tada možete automatski pokretati i zaustavljati virtualne strojeve kada nisu potrebni. Stvarno vrijeme korištenja može se smanjiti na 6 sati dnevno. Tada će se plaćanje u kontekstu našeg zadatka smanjiti na 11 USD mjesečno za 8 preglednika. Nije li ovo divno? Ali sa strojevima s mogućnošću preopterećenja moramo biti oprezni i spremni na prekide i nestabilnost, iako se te situacije mogu predvidjeti i riješiti softverom. Vrijedno je toga!
Ali nipošto ne kažem 'nikada ne koristite testne farme u oblaku'. Imaju niz prednosti. Prije svega, ovo nije samo virtualni stroj, već punopravno rješenje za automatizaciju testiranja sa skupom funkcionalnosti odmah iza kutije: daljinski pristup, zapisnici, snimke zaslona, video snimanje, različiti preglednici i fizički mobilni uređaji. U mnogim situacijama ovo može biti bitna šik alternativa. Platforme za testiranje posebno su korisne za IOS automatizaciju, kada javni oblaci mogu ponuditi samo Linux/Windows sustave. Ali o iOS-u ćemo govoriti u sljedećim člancima. Preporučam da uvijek sagledate situaciju i krenete od zadataka: u nekim slučajevima je jeftinije i učinkovitije koristiti javne oblake, au drugima su testne platforme definitivno vrijedne potrošenog novca.
Prikaz trenutnog stanja infrastrukture
Veze za istraživanje
Slični alati:
6. Orkestracija
Kratak opis tehnologije
Imam dobre vijesti – skoro smo pri kraju članka! Trenutačno se naša infrastruktura za automatizaciju sastoji od web i Android testova, koje paralelno izvodimo kroz GitLab CI, koristeći alate omogućene za Docker: Selenium grid i Selenoid. Štoviše, koristimo virtualne strojeve stvorene putem GCP-a za smještaj spremnika s preglednicima i emulatorima. Kako bismo smanjili troškove, te virtualne strojeve pokrećemo samo na zahtjev i zaustavljamo ih kada se testiranje ne provodi. Postoji li još nešto što može poboljšati našu infrastrukturu? Odgovor je da! Upoznajte 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
alat
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 grid, 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
Iz naslova se vidi da je ovo bio samo prvi dio. Unatoč činjenici da se pokazalo prilično velikim, važne teme još uvijek nisu pokrivene ovdje. U drugom dijelu planiram pogledati infrastrukturu automatizacije u kontekstu IOS-a. Zbog Appleovih ograničenja pokretanja iOS simulatora samo na macOS sustavima, naš raspon rješenja je suž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. Nastojat ću vas držati u tijeku s naprednim 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