Del 1: Web/Android
Bemærk: denne artikel er en oversættelse til russisk af den originale artikel Alle illustrationer, links, citater og termer er dog bevaret på originalsproget for at undgå forvrængning af betydningen, når de oversættes til russisk. Jeg ønsker dig glad for at studere!
I øjeblikket er DevOps-specialiteten en af de mest efterspurgte i it-branchen. Hvis du åbner populære jobsøgningssider og filtrerer efter løn, vil du se, at DevOps-relaterede job er øverst på listen. Det er dog vigtigt at forstå, at dette hovedsageligt refererer til en 'Senior' stilling, hvilket indebærer, at kandidaten har et højt niveau af færdigheder, viden om teknologi og værktøjer. Dette kommer også med en høj grad af ansvar forbundet med den uafbrudte drift af produktionen. Vi begyndte dog at glemme, hvad DevOps er. I starten var det ikke en bestemt person eller afdeling. Hvis vi leder efter definitioner af dette udtryk, vil vi finde mange smukke og korrekte navneord, såsom metodologi, praksis, kulturfilosofi, gruppe af begreber og så videre.
Mit speciale er en testautomationsingeniør (QA automation engineer), men jeg mener, at det ikke kun skal forbindes med at skrive autotest eller udvikle testrammearkitektur. I 2020 er viden om automationsinfrastruktur også essentiel. Dette giver dig mulighed for selv at organisere automatiseringsprocessen, fra at køre test til at levere resultater til alle interessenter i overensstemmelse med dine mål. Som et resultat er DevOps-færdigheder et must for at få arbejdet gjort. Og alt dette er godt, men der er desværre et problem (spoiler: denne artikel forsøger at forenkle dette problem). Pointen er, at DevOps er svært. Og det er indlysende, for virksomheder vil ikke betale meget for noget, der er nemt at gøre... I DevOps-verdenen er der en lang række værktøjer, termer og praksisser, der skal mestres. Dette er især svært i begyndelsen af en karriere og afhænger af den akkumulerede tekniske erfaring.
Kilde:
Her vil vi nok slutte af med den indledende del og fokusere på formålet med denne artikel.
Hvad handler denne artikel om?
I denne artikel vil jeg dele min erfaring med at bygge en testautomatiseringsinfrastruktur. Der findes mange informationskilder på internettet om forskellige værktøjer og hvordan man bruger dem, men jeg vil gerne se på dem rent i sammenhæng med automatisering. Jeg tror, at mange automationsingeniører kender til situationen, hvor ingen undtagen dig kører de udviklede tests eller bekymrer sig om at vedligeholde dem. Som følge heraf bliver tests forældede, og du skal bruge tid på at opdatere dem. Igen, i begyndelsen af en karriere, kan dette være en ganske vanskelig opgave: klogt at beslutte, hvilke værktøjer der skal hjælpe med at eliminere et givet problem, hvordan man vælger, konfigurerer og vedligeholder dem. Nogle testere henvender sig til DevOps (mennesker) for at få hjælp, og lad os være ærlige, denne tilgang virker. I mange tilfælde kan dette være den eneste mulighed, da vi ikke har overblik over alle afhængigheder. Men som bekendt er DevOps meget travle fyre, fordi de skal tænke på hele virksomhedens infrastruktur, udrulning, overvågning, mikrotjenester og andre lignende opgaver afhængigt af organisationen/teamet. Som det normalt er tilfældet, er automatisering ikke en prioritet. I et sådant tilfælde skal vi forsøge at gøre alt, hvad der er muligt fra vores side fra start til slut. Dette vil reducere afhængigheder, fremskynde arbejdsgangen, forbedre vores færdigheder og give os mulighed for at se det større billede af, hvad der sker.
Artiklen præsenterer de mest populære og populære værktøjer og viser, hvordan du bruger dem til at bygge en automatiseringsinfrastruktur trin for trin. Hver gruppe er repræsenteret af værktøjer, der er blevet testet gennem personlig erfaring. Men det betyder ikke, at du skal bruge det samme. Redskaberne i sig selv er ikke vigtige, de fremstår og bliver forældede. Vores ingeniøropgave er at forstå de grundlæggende principper: hvorfor vi har brug for denne gruppe værktøjer, og hvilke arbejdsproblemer vi kan løse med deres hjælp. Derfor efterlader jeg i slutningen af hvert afsnit links til lignende værktøjer, som kan bruges i din organisation.
Hvad er der ikke i denne artikel
Jeg gentager endnu en gang, at artiklen ikke handler om specifikke værktøjer, så der vil ikke være indsættelser af kode fra dokumentationen og beskrivelser af specifikke kommandoer. Men i slutningen af hvert afsnit efterlader jeg links til detaljeret undersøgelse.
Dette gøres fordi:
- dette materiale er meget let at finde i forskellige kilder (dokumentation, bøger, videokurser);
- hvis vi begynder at gå dybere, bliver vi nødt til at skrive 10, 20, 30 dele af denne artikel (mens planerne er 2-3);
- Jeg vil bare ikke spilde din tid, da du måske vil bruge andre værktøjer til at nå de samme mål.
Praksis
Jeg ville virkelig gerne have, at dette materiale var nyttigt for enhver læser, og ikke bare læst og glemt. I enhver undersøgelse er praksis en meget vigtig komponent. Hertil har jeg forberedt mig. Der venter også lektier på dig for at sikre dig, at du ikke tankeløst kopierer linjerne i de kommandoer, du udfører.
plan
Trin
Teknologier
Værktøjer
1
Lokal kørsel (forbered web-/android-demo-tests og kør det lokalt)
Node.js, Selen, Appium
2
Versionsstyringssystemer
Git
3
Containerisering
Docker, Selen grid, Selenoid (Web, Android)
4
CI/CD
Gitlab CI
5
Cloud platforme
Google Cloud Platform
6
Orchestration
Kubernetes
7
Infrastruktur som en kode (IaC)
Terraform, Ansible
Hver sektions opbygning
For at holde fortællingen klar er hvert afsnit beskrevet i henhold til følgende oversigt:
- kort beskrivelse af teknologien,
- værdi for automatiseringsinfrastruktur,
- illustration af den nuværende tilstand af infrastrukturen,
- links til studier,
- lignende værktøjer.
1. Kør test lokalt
Kort beskrivelse af teknologien
Dette er blot et forberedende trin til at køre demotestene lokalt og bekræfte, at de består. I den praktiske del bruges Node.js, men programmeringssproget og platformen er heller ikke vigtige og du kan bruge dem, der bruges i din virksomhed.
Som automatiseringsværktøjer anbefaler jeg dog at bruge henholdsvis Selenium WebDriver til webplatforme og Appium til Android-platformen, da vi i de næste trin vil bruge Docker-billeder, der er skræddersyet til at arbejde specifikt med disse værktøjer. Desuden, med henvisning til jobkravene, er disse værktøjer de mest efterspurgte på markedet.
Som du måske har bemærket, overvejer vi kun web- og Android-tests. Desværre er iOS en helt anden historie (tak Apple). Jeg planlægger at fremvise IOS-relaterede løsninger og praksis i kommende dele.
Værdi for automatiseringsinfrastruktur
Fra et infrastrukturperspektiv giver det ikke nogen værdi at køre lokalt. Du kontrollerer kun, at testene kører på den lokale maskine i lokale browsere og simulatorer. Men det er under alle omstændigheder et nødvendigt udgangspunkt.
Illustration af infrastrukturens nuværende tilstand
Links til at udforske
Lignende værktøjer
- ethvert programmeringssprog, du kan lide, i forbindelse med Selenium/Appium-tests;
- eventuelle tests;
- enhver testløber.
2. Versionskontrolsystemer (Git)
Kort beskrivelse af teknologien
Det vil ikke være en stor åbenbaring for nogen, hvis jeg siger, at versionskontrol er en ekstremt vigtig del af udviklingen, både i et team og individuelt. Baseret på forskellige kilder er det sikkert at sige, at Git er den mest populære repræsentant. Et versionskontrolsystem giver mange fordele, såsom kodedeling, lagring af versioner, gendannelse til tidligere filialer, overvågning af projekthistorik og sikkerhedskopier. Vi vil ikke diskutere hvert punkt i detaljer, da jeg er sikker på, at du er meget fortrolig med det og bruger det i dit daglige arbejde. Men hvis det pludselig ikke er tilfældet, så anbefaler jeg at holde pause i at læse denne artikel og udfylde dette hul så hurtigt som muligt.
Værdi for automatiseringsinfrastruktur
Og her kan du stille et rimeligt spørgsmål: ”Hvorfor fortæller han os om Git? Alle ved dette og bruger det både til udviklingskode og til autotestkode.” Du vil have helt ret, men i denne artikel taler vi om infrastruktur, og denne sektion fungerer som et eksempel på afsnit 7: "Infrastruktur som kode (IaC)". For os betyder det, at hele infrastrukturen, inklusive test, er beskrevet i form af kode, så vi også kan anvende versionssystemer på den og få lignende fordele som for udvikling og automatiseringskode.
Vi vil se mere detaljeret på IaC i trin 7, men allerede nu kan du begynde at bruge Git lokalt ved at oprette et lokalt lager. Det store billede vil blive udvidet, når vi tilføjer et fjernlager til infrastrukturen.
Illustration af infrastrukturens nuværende tilstand
Links til at udforske
Lignende værktøjer
3. Containerisering (Docker)
Kort beskrivelse af teknologien
For at demonstrere, hvordan containerisering har ændret spillereglerne, lad os gå et par årtier tilbage i tiden. Dengang købte og brugte folk servermaskiner til at køre applikationer. Men i de fleste tilfælde var de nødvendige startressourcer ikke kendt på forhånd. Som følge heraf brugte virksomheder penge på indkøb af dyre, kraftfulde servere, men noget af denne kapacitet blev ikke udnyttet fuldstændigt.
Næste trin i udviklingen var virtuelle maskiner (VM'er), som løste problemet med at spilde penge på ubrugte ressourcer. Denne teknologi gjorde det muligt at køre applikationer uafhængigt af hinanden inden for den samme server, og allokerede fuldstændigt isoleret plads. Men desværre har enhver teknologi sine ulemper. Kørsel af en VM kræver et fuldt operativsystem, som forbruger CPU, RAM, lager og, afhængigt af operativsystemet, skal licensomkostninger tages i betragtning. Disse faktorer påvirker indlæsningshastigheden og gør portabiliteten vanskelig.
Og nu kommer vi til containerisering. Endnu en gang løser denne teknologi det tidligere problem, da containere ikke bruger et fuldt OS, hvilket frigør en stor mængde ressourcer og giver en hurtig og fleksibel løsning til portabilitet.
Selvfølgelig er containeriseringsteknologi ikke noget nyt og blev først introduceret i slutningen af 70'erne. I de dage blev der udført en masse forskning, udvikling og forsøg. Men det var Docker, der tilpassede denne teknologi og gjorde den let tilgængelig for masserne. I dag, når vi taler om containere, mener vi i de fleste tilfælde Docker. Når vi taler om Docker-containere, mener vi Linux-containere. Vi kan bruge Windows- og macOS-systemer til at køre containere, men det er vigtigt at forstå, at der i dette tilfælde vises et ekstra lag. For eksempel kører Docker på Mac lydløst containere inde i en letvægts Linux VM. Vi vender tilbage til dette emne, når vi diskuterer at køre Android-emulatorer inde i containere, så her er der en meget vigtig nuance, som skal diskuteres mere detaljeret.
Værdi for automatiseringsinfrastruktur
Vi fandt ud af, at containerisering og Docker er seje. Lad os se på dette i sammenhæng med automatisering, fordi ethvert værktøj eller teknologi skal løse et problem. Lad os skitsere de åbenlyse problemer med testautomatisering i forbindelse med UI-tests:
- et stort antal afhængigheder ved installation af Selenium og især Appium;
- kompatibilitetsproblemer mellem versioner af browsere, simulatorer og drivere;
- mangel på isoleret plads til browsere/simulatorer, hvilket er særligt vigtigt for parallel kørsel;
- svært at administrere og vedligeholde, hvis du skal køre 10, 50, 100 eller endda 1000 browsere på samme tid.
Men da Selenium er det mest populære automatiseringsværktøj, og Docker er det mest populære containeriseringsværktøj, burde det ikke komme som nogen overraskelse, at nogen har forsøgt at kombinere dem for at skabe et kraftfuldt værktøj til at løse de ovennævnte problemer. Lad os overveje sådanne løsninger mere detaljeret.
Selengitter i docker
Dette værktøj er det mest populære i Selenium-verdenen til at køre flere browsere på flere maskiner og administrere dem fra en central hub. For at starte skal du registrere mindst 2 dele: Hub og Node(r). Hub er en central node, der modtager alle anmodninger fra test og distribuerer dem til de relevante noder. For hver Node kan vi konfigurere en specifik konfiguration, for eksempel ved at angive den ønskede browser og dens version. Vi skal dog stadig selv tage os af kompatible browserdrivere og installere dem på de ønskede noder. Af denne grund bruges Selenium grid ikke i sin rene form, undtagen når vi skal arbejde med browsere, der ikke kan installeres på Linux OS. I alle andre tilfælde ville en væsentlig fleksibel og korrekt løsning være at bruge Docker-billeder til at køre Selenium grid Hub og Nodes. Denne tilgang forenkler i høj grad nodestyring, da vi kan vælge det billede, vi har brug for, med kompatible versioner af browsere og drivere, der allerede er installeret.
På trods af negative anmeldelser om stabilitet, især når man kører et stort antal noder parallelt, er Selenium Grid stadig det mest populære værktøj til at køre Selenium test parallelt. Det er vigtigt at bemærke, at forskellige forbedringer og ændringer af dette værktøj konstant vises i open source, som bekæmper forskellige flaskehalse.
Selenoid til web
Dette værktøj er et gennembrud i Selen-verdenen, da det fungerer lige ud af boksen og har gjort livet for mange automationsingeniører meget lettere. Først og fremmest er dette ikke endnu en ændring af selennettet. I stedet skabte udviklerne en helt ny version af Selenium Hub i Golang, som kombineret med lette Docker-billeder til forskellige browsere satte skub i udviklingen af testautomatisering. Desuden skal vi i tilfælde af Selenium Grid bestemme alle de nødvendige browsere og deres versioner på forhånd, hvilket ikke er et problem, når du kun arbejder med én browser. Men når det kommer til flere understøttede browsere, er Selenoid den bedste løsning takket være dens 'browser on demand'-funktion. Alt, der kræves af os, er at downloade de nødvendige billeder med browsere på forhånd og opdatere konfigurationsfilen, som Selenoid interagerer med. Efter at Selenoid har modtaget en anmodning fra testene, vil den automatisk starte den ønskede beholder med den ønskede browser. Når testen er fuldført, vil Selenoid trække beholderen tilbage og derved frigøre ressourcer til fremtidige anmodninger. Denne tilgang eliminerer fuldstændigt det velkendte problem med 'knudeforringelse', som vi ofte støder på i selennettet.
Men desværre er Selenoid stadig ikke en sølvkugle. Vi har fået funktionen 'browser on demand', men funktionen 'ressourcer on demand' er stadig ikke tilgængelig. For at bruge Selenoid skal vi implementere det på fysisk hardware eller på en VM, hvilket betyder, at vi på forhånd skal vide, hvor mange ressourcer der skal allokeres. Jeg gætter på, at dette ikke er et problem for små projekter, der kører 10, 20 eller endda 30 browsere parallelt. Men hvad hvis vi har brug for 100, 500, 1000 eller mere? Det giver ingen mening at vedligeholde og betale for så mange ressourcer hele tiden. I afsnit 5 og 6 i denne artikel vil vi diskutere løsninger, der giver dig mulighed for at skalere og derved reducere virksomhedens omkostninger betydeligt.
Selenoid til Android
Efter succesen med Selenoid som et webautomatiseringsværktøj, ønskede folk noget lignende til Android. Og det skete - Selenoid blev udgivet med Android-understøttelse. Fra et brugersynspunkt på højt niveau ligner operationsprincippet webautomatisering. Den eneste forskel er, at Selenoid i stedet for browsercontainere kører Android-emulatorcontainere. Efter min mening er dette i øjeblikket det mest kraftfulde gratis værktøj til at køre Android-tests parallelt.
Jeg vil virkelig ikke tale om de negative aspekter af dette værktøj, da jeg virkelig kan lide det. Men alligevel er der de samme ulemper, som gør sig gældende for webautomatisering og er forbundet med skalering. Ud over dette skal vi tale om endnu en begrænsning, der kan komme som en overraskelse, hvis vi opsætter værktøjet for første gang. For at køre Android-billeder har vi brug for en fysisk maskine eller VM med indlejret virtualiseringsunderstøttelse. I vejledningen viser jeg, hvordan du aktiverer dette på en Linux VM. Men hvis du er macOS-bruger og ønsker at implementere Selenoid lokalt, så vil dette ikke være muligt at køre Android-tests. Men du kan altid køre en Linux VM lokalt med 'indlejret virtualisering' konfigureret og implementere Selenoid indeni.
Illustration af infrastrukturens nuværende tilstand
I forbindelse med denne artikel vil vi tilføje 2 værktøjer til at illustrere infrastrukturen. Disse er Selenium-gitter til webtests og Selenoid til Android-tests. I GitHub-tutorialen vil jeg også vise dig, hvordan du bruger Selenoid til at køre webtests.
Links til at udforske
Lignende værktøjer
- Der er andre containeriseringsværktøjer, men Docker er det mest populære. Hvis du vil prøve noget andet, skal du huske på, at de værktøjer, vi har dækket til at køre Selenium-tests parallelt, ikke fungerer ud af boksen.
- Som allerede nævnt er der mange modifikationer af selennettet, f.eks..
4.CI/CD
Kort beskrivelse af teknologien
Praksisen med kontinuerlig integration er ret populær i udviklingen og er på niveau med versionskontrolsystemer. På trods af dette føler jeg, at der er forvirring i terminologien. I dette afsnit vil jeg gerne beskrive 3 modifikationer af denne teknologi fra mit synspunkt. På internettet finder du mange artikler med forskellige fortolkninger, og det er helt normalt, hvis din mening er forskellig. Det vigtigste er, at du er på samme side med dine kollegaer.
Så der er 3 udtryk: CI - Kontinuerlig Integration, CD - Kontinuerlig levering og igen CD - Kontinuerlig Deployment. (Nedenfor vil jeg bruge disse udtryk på engelsk). Hver modifikation tilføjer flere yderligere trin til din udviklingspipeline. Men ordet kontinuerlig (kontinuerlig) er det vigtigste. I denne sammenhæng mener vi noget, der sker fra start til slut, uden afbrydelse eller manuel indgriben. Lad os se på CI & CD og CD i denne sammenhæng.
- Kontinuerlig integration dette er det første trin i udviklingen. Efter at have indsendt ny kode til serveren, forventer vi at modtage hurtig tilbagemelding om, at vores ændringer er ok. Typisk inkluderer CI at køre statiske kodeanalyseværktøjer og enheds/interne API-tests. Dette giver os mulighed for at få information om vores kode inden for få sekunder/minutter.
- Kontinuerlig tilførsel er et mere avanceret trin, hvor vi kører integration/UI-tests. Men på dette stadium får vi ikke resultater så hurtigt som med CI. For det første tager disse typer test længere tid at gennemføre. For det andet, før lancering, skal vi implementere vores ændringer til test-/iscenesættelsesmiljøet. Desuden, hvis vi taler om mobiludvikling, så ser der et ekstra trin ud til at skabe en build af vores applikation.
- Kontinuerlig implementering forudsætter, at vi automatisk frigiver vores ændringer til produktionen, hvis alle accepttests er bestået i de foregående trin. Ud over dette kan du efter udgivelsesfasen konfigurere forskellige stadier, såsom at køre røgtest på produktion og indsamle metrics af interesse. Kontinuerlig implementering er kun mulig med god dækning af automatiserede tests. Hvis der er behov for manuelle indgreb, inklusive test, er dette ikke længere Kontinuerlig (sammenhængende). Så kan vi sige, at vores pipeline kun overholder praksis med Kontinuerlig Levering.
Værdi for automatiseringsinfrastruktur
I dette afsnit skal jeg præcisere, at når vi taler om end-to-end UI-tests, betyder det, at vi bør implementere vores ændringer og tilknyttede tjenester til at teste miljøer. Kontinuerlig integration - processen er ikke anvendelig til denne opgave, og vi skal sørge for at implementere i det mindste Continuous Deliver-praksis. Continuous Deployment giver også mening i forbindelse med UI-tests, hvis vi skal køre dem i produktion.
Og før vi ser på illustrationen af arkitekturændringen, vil jeg sige et par ord om GitLab CI. I modsætning til andre CI/CD-værktøjer giver GitLab et fjernlager og mange andre ekstra funktioner. Således er GitLab mere end CI. Det inkluderer kildekodestyring, agil styring, CI/CD-pipelines, logføringsværktøjer og metrikindsamling ud af boksen. GitLab-arkitekturen består af Gitlab CI/CD og GitLab Runner. Her er en kort beskrivelse fra den officielle hjemmeside:
Gitlab CI/CD er en webapplikation med en API, der gemmer sin tilstand i en database, administrerer projekter/bygninger og giver en brugergrænseflade. GitLab Runner er en applikation, der behandler builds. Det kan implementeres separat og fungerer med GitLab CI/CD gennem en API. For at køre test skal du bruge både Gitlab-instans og Runner.
Illustration af infrastrukturens nuværende tilstand
Links til at udforske
Lignende værktøjer
- Og mange andre
5. Cloud platforme
Kort beskrivelse af teknologien
I dette afsnit vil vi tale om en populær trend kaldet 'offentlige skyer'. På trods af de enorme fordele, som virtualiserings- og containeriseringsteknologierne beskrevet ovenfor giver, har vi stadig brug for computerressourcer. Virksomheder køber dyre servere eller lejer datacentre, men i dette tilfælde er det nødvendigt at lave beregninger (til tider urealistiske) af, hvor mange ressourcer vi får brug for, om vi vil bruge dem 24/7 og til hvilke formål. For eksempel kræver produktion en server, der kører XNUMX/XNUMX, men har vi brug for lignende ressourcer til test uden for arbejdstiden? Det afhænger også af den type test, der udføres. Et eksempel kunne være belastnings-/stresstest, som vi planlægger at køre uden for arbejdstiden for at få resultater næste dag. Men der kræves bestemt ikke servertilgængelighed XNUMX/XNUMX for end-to-end automatiserede tests og især ikke for manuelle testmiljøer. I sådanne situationer vil det være godt at skaffe så mange ressourcer som nødvendigt på efterspørgsel, bruge dem og stoppe med at betale, når de ikke længere er nødvendige. Desuden ville det være fantastisk at modtage dem med det samme ved at lave et par museklik eller køre et par scripts. Det er, hvad offentlige skyer bruges til. Lad os se på definitionen:
"Den offentlige sky er defineret som computertjenester, der tilbydes af tredjepartsudbydere over det offentlige internet, hvilket gør dem tilgængelige for alle, der ønsker at bruge eller købe dem. De kan være gratis eller sælges on-demand, hvilket giver kunderne mulighed for kun at betale pr. brug for de CPU-cyklusser, lagerplads eller båndbredde, de bruger."
Der er en opfattelse af, at offentlige skyer er dyre. Men deres centrale idé er at reducere virksomhedens omkostninger. Som nævnt tidligere giver offentlige skyer dig mulighed for at få ressourcer på efterspørgsel og kun betale for den tid, du bruger dem. Nogle gange glemmer vi også, at medarbejdere modtager løn, og specialister er også en dyr ressource. Det skal tages i betragtning, at offentlige skyer gør infrastrukturunderstøttelse meget lettere, hvilket giver ingeniører mulighed for at fokusere på vigtigere opgaver.
Værdi for automatiseringsinfrastruktur
Hvilke specifikke ressourcer har vi brug for til end-to-end UI-tests? Dybest set er disse virtuelle maskiner eller klynger (vi taler om Kubernetes i næste afsnit) til at køre browsere og emulatorer. Jo flere browsere og emulatorer vi ønsker at køre samtidigt, jo mere CPU og hukommelse kræves der, og jo flere penge skal vi betale for det. Således giver offentlige skyer i forbindelse med testautomatisering os mulighed for at køre et stort antal (100, 200, 1000...) browsere/emulatorer on demand, få testresultater så hurtigt som muligt og stoppe med at betale for så vanvittigt ressourcekrævende strøm.
De mest populære cloud-udbydere er Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Vejledningen giver eksempler på, hvordan du bruger GCP, men generelt er det lige meget, hvad du bruger til automatiseringsopgaver. De har alle omtrent samme funktionalitet. For at vælge en udbyder fokuserer ledelsen typisk på hele virksomhedens infrastruktur og forretningskrav, hvilket ligger uden for denne artikels rammer. For automationsingeniører vil det være mere interessant at sammenligne brugen af cloud-udbydere med brugen af cloud-platforme specifikt til testformål, såsom Sauce Labs, BrowserStack, BitBar og så videre. Så lad os også gøre det! Efter min mening er Sauce Labs den mest berømte cloud-testfarm, og derfor brugte jeg den til sammenligning.
GCP vs Sauce Labs til automatiseringsformål:
Lad os forestille os, at vi skal køre 8 webtests og 8 Android-tests samtidigt. Til dette vil vi bruge GCP og køre 2 virtuelle maskiner med Selenoid. På den første vil vi rejse 8 containere med browsere. På den anden er der 8 beholdere med emulatorer. Lad os tage et kig på priserne:
For at køre én container med Chrome har vi brug for n1-standard-1 bil. I tilfælde af Android vil det være det n1-standard-4 for én emulator. Faktisk er en mere fleksibel og billigere måde at indstille specifikke brugerværdier for CPU/hukommelse, men i øjeblikket er dette ikke vigtigt for sammenligning med Sauce Labs.
Og her er taksterne for brug af Sauce Labs:
Jeg tror, du allerede har bemærket forskellen, men jeg vil stadig give en tabel med beregninger til vores opgave:
Nødvendige ressourcer
Månedlig
Arbejdstimer(8 – 8)
Arbejdstimer+ Udtagelig
GCP til web
n1-standard-1 x 8 = n1-standard-8
$194.18
23 dage * 12 timer * 0.38 = 104.88 USD
23 dage * 12 timer * 0.08 = 22.08 USD
Sauce Labs til web
Virtual Cloud8 parallelle tests
$1.559
—
—
GCP til Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 dage * 12 timer * 1.52 = 419.52 USD
23 dage * 12 timer * 0.32 = 88.32 USD
Sauce Labs til Android
Real Device Cloud 8 parallelle tests
$1.999
—
—
Som du kan se, er forskellen i omkostningerne enorm, især hvis du kun kører test i en tolv timers arbejdsperiode. Men du kan skære yderligere ned på omkostningerne, hvis du bruger udskiftelige maskiner. Hvad er det?
En udtagelig VM er en instans, som du kan oprette og køre til en meget lavere pris end normale instanser. Compute Engine kan dog afslutte (foregribe) disse tilfælde, hvis det kræver adgang til disse ressourcer til andre opgaver. Udskiftelige forekomster er overskydende Compute Engine-kapacitet, så deres tilgængelighed varierer med brugen.
Hvis dine apps er fejltolerante og kan modstå mulige forekomstforekomster, kan udskiftelige forekomster reducere dine Compute Engine-omkostninger betydeligt. For eksempel kan batchbehandlingsjob køre på udskiftelige forekomster. Hvis nogle af disse tilfælde afsluttes under behandlingen, bliver jobbet langsommere, men stopper ikke helt. Udskiftelige forekomster fuldfører dine batchbehandlingsopgaver uden at lægge yderligere arbejdsbyrde på dine eksisterende forekomster og uden at kræve, at du betaler fuld pris for yderligere normale forekomster.
Og det er stadig ikke slut! I virkeligheden er jeg sikker på, at ingen kører test i 12 timer uden pause. Og hvis ja, så kan du automatisk starte og stoppe virtuelle maskiner, når de ikke er nødvendige. Den faktiske brugstid kan reduceres til 6 timer om dagen. Så vil betalingen i forbindelse med vores opgave falde til $11 pr. måned for 8 browsere. Er det ikke vidunderligt? Men med udskiftelige maskiner skal vi være forsigtige og forberedte på afbrydelser og ustabilitet, selvom disse situationer kan sørges for og håndteres i software. Det er det værd!
Men jeg siger på ingen måde 'brug aldrig cloud-testfarme'. De har en række fordele. Først og fremmest er dette ikke bare en virtuel maskine, men en fuldgyldig testautomatiseringsløsning med et sæt funktionalitet ud af boksen: fjernadgang, logfiler, skærmbilleder, videooptagelse, forskellige browsere og fysiske mobile enheder. I mange situationer kan dette være et essentielt smart alternativ. Testplatforme er især nyttige til IOS-automatisering, når offentlige skyer kun kan tilbyde Linux/Windows-systemer. Men vi vil tale om iOS i de følgende artikler. Jeg anbefaler altid at se på situationen og tage udgangspunkt i opgaverne: I nogle tilfælde er det billigere og mere effektivt at bruge offentlige skyer, og i andre er testplatformene bestemt pengene værd.
Illustration af infrastrukturens nuværende tilstand
Links til at udforske
Lignende værktøjer:
6. Orkestrering
Kort beskrivelse af teknologien
Jeg har gode nyheder – vi er næsten i slutningen af artiklen! I øjeblikket består vores automatiseringsinfrastruktur af web- og Android-tests, som vi kører gennem GitLab CI parallelt ved hjælp af Docker-aktiverede værktøjer: Selenium grid og Selenoid. Desuden bruger vi virtuelle maskiner oprettet via GCP til at hoste containere med browsere og emulatorer. For at reducere omkostningerne starter vi kun disse virtuelle maskiner efter behov og stopper dem, når der ikke udføres test. Er der andet, der kan forbedre vores infrastruktur? Svaret er ja! Mød Kubernetes (K8s)!
Lad os først se på, hvordan ordene orkestrering, klynge og Kubernetes er relateret til hinanden. På et højt niveau er orkestrering det system, der implementerer og administrerer applikationer. Til testautomatisering er sådanne containeriserede applikationer Selenium grid og Selenoid. Docker og K8s supplerer hinanden. Den første bruges til applikationsimplementering, den anden til orkestrering. Til gengæld er K8s en klynge. Klyngens opgave er at bruge VM'er som noder, hvilket giver dig mulighed for at installere forskellige funktionaliteter, programmer og tjenester inden for en server (cluster). Hvis nogen af noderne fejler, vil andre noder samle sig op, hvilket sikrer uafbrudt drift af vores applikation. Ud over dette har K8s vigtig funktionalitet relateret til skalering, takket være hvilken vi automatisk opnår den optimale mængde ressourcer baseret på belastningen og sætter grænser.
I virkeligheden er det slet ikke en triviel opgave at implementere Kubernetes manuelt fra bunden. Jeg efterlader et link til den berømte vejledning "Kubernetes The Hard Way", og hvis du er interesseret, kan du øve dig på det. Men heldigvis findes der alternative metoder og værktøjer. Den nemmeste måde er at bruge Google Kubernetes Engine (GKE) i GCP, som giver dig mulighed for at få en færdiglavet klynge med få klik. Jeg anbefaler at bruge denne tilgang til at begynde at lære, da den vil give dig mulighed for at fokusere på at lære at bruge K8'erne til dine opgaver i stedet for at lære, hvordan de interne komponenter skal integreres med hinanden.
Værdi for automatiseringsinfrastruktur
Lad os tage et kig på et par vigtige funktioner, som K8s giver:
- applikationsimplementering: brug af en multi-node klynge i stedet for VM'er;
- dynamisk skalering: reducerer omkostningerne ved ressourcer, der kun bruges efter behov;
- selvhelbredende: automatisk genopretning af bælg (som følge af hvilken beholdere også gendannes);
- udrulning af opdateringer og tilbagerulninger af ændringer uden nedetid: opdateringsværktøjer, browsere og emulatorer afbryder ikke nuværende brugeres arbejde
Men K8s er stadig ikke en sølvkugle. For at forstå alle fordele og begrænsninger i forbindelse med de værktøjer, vi overvejer (Selenium grid, Selenoid), vil vi kort diskutere strukturen af K8'er. Klynge indeholder to typer noder: Master Nodes og Workers Nodes. Master Nodes er ansvarlige for beslutninger om ledelse, implementering og planlægning. Workers noder er hvor applikationer lanceres. Noder indeholder også et container-runtime-miljø. I vores tilfælde er dette Docker, som er ansvarlig for container-relaterede operationer. Men der findes også alternative løsninger, f.eks. Det er vigtigt at forstå, at afskalning eller selvhelbredelse ikke gælder direkte for beholdere. Dette implementeres ved at tilføje/reducere antallet af pods, som igen indeholder containere (normalt én container pr. pod, men afhængigt af opgaven kan der være flere). Højniveauhierarkiet består af arbejderknudepunkter, inden i hvilke der er pods, indeni hvilke containere er hævet.
Skaleringsfunktionen er nøglen og kan anvendes på både noder i en klynge-nodepulje og pods i en node. Der er 2 typer skalering, der gælder for både noder og pods. Den første type er vandret - skalering sker ved at øge antallet af noder/pods. Denne type er mere at foretrække. Den anden type er derfor lodret. Skalering udføres ved at øge størrelsen af noder/pods, og ikke deres antal.
Lad os nu se på vores værktøjer i sammenhæng med ovenstående udtryk.
Selen gitter
Som tidligere nævnt er selenrist et meget populært værktøj, og det er ingen overraskelse, at det er blevet containeriseret. Derfor kommer det ikke som nogen overraskelse, at Selenium-gitteret kan implementeres i K8'er. Et eksempel på, hvordan man gør dette, kan findes i det officielle K8s-lager. Som sædvanlig vedhæfter jeg links i slutningen af afsnittet. Derudover viser vejledningen, hvordan du gør dette i Terraform. Der er også instruktioner om, hvordan man skalerer antallet af pods, der indeholder browsercontainere. Men den automatiske skaleringsfunktion i forbindelse med K8s er stadig ikke en helt oplagt opgave. Da jeg begyndte at studere, fandt jeg ingen praktisk vejledning eller anbefalinger. Efter adskillige undersøgelser og eksperimenter med støtte fra DevOps-teamet, valgte vi tilgangen med at rejse containere med de nødvendige browsere inde i én pod, som er placeret inde i én arbejderknude. Denne metode giver os mulighed for at anvende strategien med horisontal skalering af noder ved at øge deres antal. Jeg håber, at dette vil ændre sig i fremtiden, og vi vil se flere og flere beskrivelser af bedre tilgange og færdige løsninger, især efter udgivelsen af Selenium grid 4 med en ændret intern arkitektur.
Selenoid:
Selenoid-implementering i K8s er i øjeblikket den største skuffelse. De er ikke kompatible. I teorien kan vi rejse en Selenoid-beholder inde i en pod, men når Selenoid begynder at lancere containere med browsere, vil de stadig være inde i den samme pod. Dette gør skalering umulig, og som et resultat vil Selenoids arbejde inde i en klynge ikke adskille sig fra arbejde inde i en virtuel maskine. Sådan er det.
Moon:
Ved at kende denne flaskehals, når de arbejdede med Selenoid, udgav udviklerne et mere kraftfuldt værktøj kaldet Moon. Dette værktøj blev oprindeligt designet til at fungere med Kubernetes, og som følge heraf kan og bør autoskaleringsfunktionen bruges. Desuden vil jeg sige, at det er det i øjeblikket kun et værktøj i Selenium-verdenen, som har indbygget K8s-klyngeunderstøttelse ud af kassen (ikke længere tilgængelig, se næste værktøj ). Nøglefunktionerne ved Moon, der giver denne støtte, er:
Fuldstændig statsløs. Selenoid gemmer oplysninger i hukommelsen om aktuelt kørende browsersessioner. Hvis dens proces af en eller anden grund går ned - så går alle kørende sessioner tabt. Månen har derimod ingen intern tilstand og kan replikeres på tværs af datacentre. Browsersessioner forbliver i live, selvom en eller flere replikaer går ned.
Så Moon er en fantastisk løsning, men der er et problem: den er ikke gratis. Prisen afhænger af antallet af sessioner. Du kan kun køre 0-4 sessioner gratis, hvilket ikke er særlig nyttigt. Men fra den femte session skal du betale $5 for hver. Situationen kan variere fra virksomhed til virksomhed, men i vores tilfælde er det meningsløst at bruge Moon. Som jeg beskrev ovenfor, kan vi køre VM'er med Selenium Grid on demand eller øge antallet af noder i klyngen. For cirka én pipeline lancerer vi 500 browsere og stopper alle ressourcer, efter at testene er afsluttet. Hvis vi brugte Moon, skulle vi betale yderligere 500 x 5 = $2500 om måneden, uanset hvor ofte vi kører tests. Igen, jeg siger ikke, at du ikke skal bruge Moon. Til dine opgaver kan dette være en uundværlig løsning, hvis du fx har mange projekter/teams i din organisation, og du har brug for en kæmpe fælles klynge for alle. Som altid efterlader jeg et link til sidst og anbefaler at lave alle de nødvendige beregninger i forbindelse med din opgave.
Callisto(Opmærksomhed! Dette er ikke i den originale artikel og er kun indeholdt i den russiske oversættelse)
Selen er som sagt et meget populært værktøj, og IT-området udvikler sig meget hurtigt. Mens jeg arbejdede på oversættelsen, dukkede et nyt lovende værktøj kaldet Callisto op på nettet (hej Cypress og andre selenmordere). Det fungerer indbygget med K8s og giver dig mulighed for at køre Selenoid-beholdere i pods, fordelt på tværs af noder. Alt fungerer lige ud af kassen, inklusive autoskalering. Fantastisk, men skal testes. Jeg har allerede formået at implementere dette værktøj og køre flere eksperimenter. Men det er for tidligt at drage konklusioner, efter at have modtaget resultater over lang afstand, vil jeg måske lave en anmeldelse i fremtidige artikler. For nu efterlader jeg kun links til uafhængig forskning.
Illustration af infrastrukturens nuværende tilstand
Links til at udforske
Lignende værktøjer
7. Infrastruktur som kode (IaC)
Kort beskrivelse af teknologien
Og nu kommer vi til det sidste afsnit. Typisk er denne teknologi og relaterede opgaver ikke automationsingeniørers ansvar. Og det er der grunde til. For det første er infrastrukturproblemer i mange organisationer under DevOps-afdelingens kontrol, og udviklingsteamene er ikke ligeglade med, hvad der får pipelinen til at fungere, og hvordan alt, der er forbundet med det, skal understøttes. For det andet, lad os være ærlige, er praksis med Infrastructure as Code (IaC) stadig ikke vedtaget i mange virksomheder. Men det er bestemt blevet en populær trend, og det er vigtigt at forsøge at være med i de processer, tilgange og værktøjer, der er forbundet med det. Eller i det mindste holde dig opdateret.
Lad os starte med motivationen for at bruge denne tilgang. Vi har allerede diskuteret, at for at køre test i GitlabCI, skal vi som minimum have ressourcer til at køre Gitlab Runner. Og for at køre containere med browsere/emulatorer skal vi reservere en VM eller klynge. Ud over at teste ressourcer har vi brug for en betydelig mængde kapacitet til at understøtte udvikling, iscenesættelse, produktionsmiljøer, hvilket også omfatter databaser, automatiske tidsplaner, netværkskonfigurationer, belastningsbalancere, brugerrettigheder og så videre. Nøglespørgsmålet er den indsats, der kræves for at understøtte det hele. Der er flere måder, hvorpå vi kan foretage ændringer og udrulle opdateringer. For eksempel, i forbindelse med GCP, kan vi bruge UI-konsollen i browseren og udføre alle handlinger ved at klikke på knapper. Et alternativ ville være at bruge API-kald til at interagere med cloud-enheder eller bruge kommandolinjeværktøjet gcloud til at udføre de ønskede manipulationer. Men med et rigtig stort antal forskellige enheder og infrastrukturelementer bliver det svært eller endda umuligt at udføre alle operationer manuelt. Desuden er alle disse manuelle handlinger ukontrollerbare. Vi kan ikke indsende dem til gennemgang før udførelse, bruge et versionskontrolsystem og hurtigt tilbagerulle de ændringer, der førte til hændelsen. For at løse sådanne problemer har ingeniører skabt og skabt automatiske bash/shell-scripts, som ikke er meget bedre end tidligere metoder, da de ikke er så lette at hurtigt læse, forstå, vedligeholde og ændre i en proceduremæssig stil.
I denne artikel og vejledningen bruger jeg 2 værktøjer relateret til IaC-praksis. Disse er Terraform og Ansible. Nogle mennesker mener, at det ikke giver mening at bruge dem på samme tid, da deres funktionalitet er ens, og de er udskiftelige. Men faktum er, at de i første omgang får helt andre opgaver. Og det faktum, at disse værktøjer skulle supplere hinanden, blev bekræftet ved en fælles præsentation af udviklere, der repræsenterer HashiCorp og RedHat. Den konceptuelle forskel er, at Terraform er et klargøringsværktøj til at administrere selve serverne. Mens Ansible er et konfigurationsstyringsværktøj, hvis opgave er at installere, konfigurere og administrere software på disse servere.
Et andet vigtigt kendetegn ved disse værktøjer er kodningsstilen. I modsætning til bash og Ansible bruger Terraform en deklarativ stil baseret på en beskrivelse af den ønskede sluttilstand, der skal opnås som et resultat af udførelse. For eksempel, hvis vi skal oprette 10 VM'er og anvende ændringerne gennem Terraform, så får vi 10 VM'er. Hvis vi kører scriptet igen, vil der ikke ske noget, da vi allerede har 10 VM'er, og Terraform ved om dette, fordi det gemmer den aktuelle tilstand af infrastrukturen i en tilstandsfil. Men Ansible bruger en proceduremæssig tilgang, og hvis du beder den om at oprette 10 VM'er, vil vi ved den første lancering få 10 VM'er, der ligner Terraform. Men efter genstart har vi allerede 20 VM'er. Dette er den vigtige forskel. I proceduremæssig stil gemmer vi ikke den aktuelle tilstand og beskriver blot en række trin, der skal udføres. Selvfølgelig kan vi håndtere forskellige situationer, tilføje flere kontroller for eksistensen af ressourcer og den nuværende tilstand, men det nytter ikke at spilde vores tid og lægge kræfter i at kontrollere denne logik. Derudover øger dette risikoen for at begå fejl.
Sammenfattende alt ovenstående kan vi konkludere, at Terraform og deklarativ notation er et mere egnet værktøj til at klargøre servere. Men det er bedre at uddelegere arbejdet med konfigurationsstyring til Ansible. Med det af vejen, lad os se på use cases i sammenhæng med automatisering.
Værdi for automatiseringsinfrastruktur
Den eneste vigtige ting at forstå her er, at testautomatiseringsinfrastrukturen skal betragtes som en del af hele virksomhedens infrastruktur. Det betyder, at al IaC-praksis skal anvendes globalt på hele organisationens ressourcer. Hvem der er ansvarlig for dette afhænger af dine processer. DevOps-teamet er mere erfarne i disse problemer, de ser hele billedet af, hvad der sker. QA-ingeniører er dog mere involveret i processen med bygningsautomatisering og strukturen af pipelinen, hvilket giver dem mulighed for bedre at se alle de nødvendige ændringer og muligheder for forbedringer. Den bedste mulighed er at arbejde sammen, udveksle viden og ideer for at opnå det forventede resultat.
Her er et par eksempler på brug af Terraform og Ansible i forbindelse med testautomatisering og de værktøjer, vi diskuterede før:
1. Beskriv de nødvendige karakteristika og parametre for VM'er og klynger ved hjælp af Terraform.
2. Brug Ansible, installer de nødvendige værktøjer til test: docker, Selenoid, Selenium Grid og download de nødvendige versioner af browsere/emulatorer.
3. Brug Terraform til at beskrive egenskaberne for den VM, hvor GitLab Runner vil blive lanceret.
4. Installer GitLab Runner og de nødvendige medfølgende værktøjer ved hjælp af Ansible, indstil indstillinger og konfigurationer.
Illustration af infrastrukturens nuværende tilstand
Links til at udforske:
Lignende værktøjer
Lad os opsummere det!
Trin
Teknologier
Værktøjer
Værdi for automatiseringsinfrastruktur
1
Lokalt løb
Node.js, Selen, Appium
- De mest populære værktøjer til web og mobil
- Understøtter mange sprog og platforme (inklusive Node.js)
2
Versionsstyringssystemer
Git
- Lignende fordele med udviklingskode
3
Containerisering
Docker, Selen grid, Selenoid (Web, Android)
- Køre test parallelt
- Isolerede miljøer
- Simple, fleksible versionsopgraderinger
- Dynamisk standsning af ubrugte ressourcer
- Let at konfigurere
4
CI/CD
Gitlab CI
- Tester en del af pipelinen
- Hurtig feedback
- Synlighed for hele virksomheden/teamet
5
Cloud platforme
Google Cloud Platform
- Ressourcer efter behov (vi betaler kun, når det er nødvendigt)
- Nem at administrere og opdatere
- Synlighed og kontrol over alle ressourcer
6
Orchestration
Kubernetes
I forbindelse med containere med browsere/emulatorer inde i pods:
- Skalering/automatisk skalering
- Selvhelbredende
- Opdateringer og tilbagerulninger uden afbrydelser
7
Infrastruktur som en kode (IaC)
Terraform, Ansible
- Lignende fordele med udviklingsinfrastruktur
- Alle fordelene ved kodeversionering
- Nem at lave ændringer og vedligeholde
- Fuldt automatiseret
Mind map-diagrammer: udvikling af infrastruktur
trin 1: Lokal
trin 2: VCS
trin 3: Containerisering
trin 4: CI/CD
trin 5: Cloud-platforme
trin 6: Orkestrering
trin 7: IaC
Hvad er det næste?
Så dette er slutningen på artiklen. Men afslutningsvis vil jeg gerne indgå nogle aftaler med dig.
Fra din side
Som jeg sagde i begyndelsen, vil jeg gerne have, at artiklen er til praktisk brug og hjælper dig med at anvende den opnåede viden i virkeligt arbejde. tilføjer jeg igen.
Men selv efter det skal du ikke stoppe op, øve dig, studere relevante links og bøger, finde ud af, hvordan det fungerer i din virksomhed, finde steder, der kan forbedres, og tage del i det. Held og lykke!
Fra min side
Af titlen kan du se, at dette kun var den første del. På trods af at det viste sig at være ret stort, er vigtige emner stadig ikke dækket her. I den anden del planlægger jeg at se på automatiseringsinfrastruktur i sammenhæng med IOS. På grund af Apples begrænsninger for kun at køre iOS-simulatorer på macOS-systemer, er vores udvalg af løsninger indsnævret. For eksempel kan vi ikke bruge Docker til at køre simulatoren eller offentlige skyer til at køre virtuelle maskiner. Men det betyder ikke, at der ikke er andre alternativer. Jeg vil forsøge at holde dig opdateret med avancerede løsninger og moderne værktøjer!
Jeg har heller ikke nævnt ret store emner relateret til overvågning. I del 3 vil jeg se på de mest populære infrastrukturovervågningsværktøjer og hvilke data og målinger, der skal overvejes.
Og endelig. I fremtiden planlægger jeg at udgive et videokursus om opbygning af testinfrastruktur og populære værktøjer. I øjeblikket er der en del kurser og foredrag om DevOps på internettet, men alle materialer præsenteres i udviklingssammenhæng, ikke testautomatisering. I denne sag har jeg virkelig brug for feedback på, om et sådant kursus vil være interessant og værdifuldt for fællesskabet af testere og automationsingeniører. Tak på forhånd!
Kilde: www.habr.com