Del 1: Web/Android
Note: denne artikkelen er en oversettelse til russisk av den originale artikkelen Imidlertid er alle illustrasjoner, lenker, sitater og termer bevart på originalspråket for å unngå forvrengning av betydningen når de oversettes til russisk. Jeg ønsker deg lykke til med å studere!
For tiden er DevOps-spesialiteten en av de mest etterspurte i IT-bransjen. Hvis du åpner populære jobbsøkesider og filtrerer etter lønn, vil du se at DevOps-relaterte jobber er øverst på listen. Det er imidlertid viktig å forstå at dette i hovedsak refererer til en 'senior' stilling, noe som innebærer at kandidaten har et høyt nivå av ferdigheter, kunnskap om teknologi og verktøy. Dette kommer også med en høy grad av ansvar knyttet til uavbrutt drift av produksjonen. Imidlertid begynte vi å glemme hva DevOps er. I utgangspunktet var det ikke noen spesifikk person eller avdeling. Hvis vi ser etter definisjoner av dette begrepet, vil vi finne mange vakre og korrekte substantiv, som metodikk, praksis, kulturfilosofi, begrepsgruppe og så videre.
Min spesialisering er en testautomatiseringsingeniør (QA-automatiseringsingeniør), men jeg mener at det ikke bare bør assosieres med å skrive autotester eller utvikle testrammearkitektur. I 2020 er kunnskap om automasjonsinfrastruktur også viktig. Dette lar deg organisere automatiseringsprosessen selv, fra å kjøre tester til å gi resultater til alle interessenter i samsvar med dine mål. Som et resultat er DevOps-ferdigheter et must for å få jobben gjort. Og alt dette er bra, men dessverre er det et problem (spoiler: denne artikkelen prøver å forenkle dette problemet). Poenget er at DevOps er vanskelig. Og dette er åpenbart, fordi selskaper ikke vil betale mye for noe som er enkelt å gjøre... I DevOps-verdenen er det et stort antall verktøy, termer og praksiser som må mestres. Dette er spesielt vanskelig i begynnelsen av en karriere og avhenger av den akkumulerte tekniske erfaringen.
Kilde:
Her vil vi trolig avslutte med den innledende delen og fokusere på hensikten med denne artikkelen.
Hva handler denne artikkelen om?
I denne artikkelen skal jeg dele min erfaring med å bygge en testautomatiseringsinfrastruktur. Det finnes mange informasjonskilder på Internett om ulike verktøy og hvordan man bruker dem, men jeg vil gjerne se på dem rent i sammenheng med automatisering. Jeg tror at mange automasjonsingeniører er kjent med situasjonen når ingen bortsett fra deg kjører de utviklede testene eller bryr seg om å vedlikeholde dem. Som et resultat blir tester utdaterte og du må bruke tid på å oppdatere dem. Igjen, i begynnelsen av en karriere kan dette være en ganske vanskelig oppgave: klokt å bestemme hvilke verktøy som skal bidra til å eliminere et gitt problem, hvordan velge, konfigurere og vedlikeholde dem. Noen testere henvender seg til DevOps (mennesker) for å få hjelp, og la oss være ærlige, denne tilnærmingen fungerer. I mange tilfeller kan dette være det eneste alternativet siden vi ikke har innsyn i alle avhengigheter. Men som vi vet er DevOps veldig travle karer, fordi de må tenke på hele selskapets infrastruktur, utrulling, overvåking, mikrotjenester og andre lignende oppgaver avhengig av organisasjonen/teamet. Som vanlig er ikke automatisering en prioritet. I et slikt tilfelle må vi prøve å gjøre alt mulig fra vår side fra begynnelse til slutt. Dette vil redusere avhengigheter, øke hastigheten på arbeidsflyten, forbedre ferdighetene våre og tillate oss å se det større bildet av hva som skjer.
Artikkelen presenterer de mest populære og populære verktøyene og viser hvordan du bruker dem til å bygge en automatiseringsinfrastruktur trinn for trinn. Hver gruppe er representert med verktøy som er testet gjennom personlig erfaring. Men det betyr ikke at du må bruke det samme. Verktøyene i seg selv er ikke viktige, de fremstår og blir utdaterte. Vår ingeniøroppgave er å forstå de grunnleggende prinsippene: hvorfor vi trenger denne gruppen av verktøy og hvilke arbeidsproblemer vi kan løse med deres hjelp. Derfor legger jeg igjen lenker til lignende verktøy på slutten av hver seksjon som kan brukes i din organisasjon.
Hva står ikke i denne artikkelen
Jeg gjentar nok en gang at artikkelen ikke handler om spesifikke verktøy, så det vil ikke være noen innsettinger av kode fra dokumentasjonen og beskrivelser av spesifikke kommandoer. Men på slutten av hver del legger jeg igjen lenker for detaljert studie.
Dette gjøres fordi:
- dette materialet er veldig enkelt å finne i ulike kilder (dokumentasjon, bøker, videokurs);
- hvis vi begynner å gå dypere, må vi skrive 10, 20, 30 deler av denne artikkelen (mens planene er 2-3);
- Jeg vil bare ikke kaste bort tiden din siden du kanskje vil bruke andre verktøy for å oppnå de samme målene.
Praksis
Jeg vil virkelig at dette materialet skal være nyttig for enhver leser, og ikke bare lese og glemt. I enhver studie er praksis en svært viktig komponent. For dette har jeg forberedt. Det er også lekser som venter på deg for å sørge for at du ikke tankeløst kopierer linjene til kommandoene du utfører.
plan
Trinn
Teknologi
verktøy
1
Lokal kjøring (forbered web / android demo-tester og kjør den lokalt)
Node.js, Selen, Appium
2
Versjonskontrollsystemer
gå
3
Containerisering
Docker, Selenium grid, Selenoid (Web, Android)
4
CI/CD
Gitlab CI
5
Cloud plattformer
Google Cloud Platform
6
orkestre
Kubernetes
7
Infrastruktur som en kode (IaC)
Terraform, Ansible
Struktur for hver seksjon
For å holde fortellingen klar, er hver del beskrevet i henhold til følgende disposisjon:
- kort beskrivelse av teknologien,
- verdi for automatiseringsinfrastruktur,
- illustrasjon av den nåværende tilstanden til infrastrukturen,
- lenker til studier,
- lignende verktøy.
1. Kjør tester lokalt
Kort beskrivelse av teknologien
Dette er bare et forberedende trinn for å kjøre demotestene lokalt og bekrefte at de består. I den praktiske delen brukes Node.js, men programmeringsspråket og plattformen er heller ikke viktig og du kan bruke de som brukes i din bedrift.
Som automatiseringsverktøy anbefaler jeg imidlertid å bruke henholdsvis Selenium WebDriver for nettplattformer og Appium for Android-plattformen, siden vi i de neste trinnene vil bruke Docker-bilder som er skreddersydd for å fungere spesifikt med disse verktøyene. Dessuten, med henvisning til jobbkravene, er disse verktøyene de mest etterspurte i markedet.
Som du kanskje har lagt merke til, vurderer vi kun nett- og Android-tester. Dessverre er iOS en helt annen historie (takk Apple). Jeg planlegger å vise frem IOS-relaterte løsninger og praksis i kommende deler.
Verdi for automatiseringsinfrastruktur
Fra et infrastrukturperspektiv gir det ingen verdi å kjøre lokalt. Du sjekker kun at testene kjører på den lokale maskinen i lokale nettlesere og simulatorer. Men uansett er dette et nødvendig utgangspunkt.
Illustrasjon av infrastrukturens nåværende tilstand
Lenker å utforske
Lignende verktøy
- et hvilket som helst programmeringsspråk du liker i forbindelse med Selenium/Appium-tester;
- eventuelle tester;
- enhver testløper.
2. Versjonskontrollsystemer (Git)
Kort beskrivelse av teknologien
Det vil ikke være en stor åpenbaring for noen hvis jeg sier at versjonskontroll er en ekstremt viktig del av utviklingen, både i team og individuelt. Basert på ulike kilder er det trygt å si at Git er den mest populære representanten. Et versjonskontrollsystem gir mange fordeler, som kodedeling, lagring av versjoner, gjenoppretting til tidligere grener, overvåking av prosjekthistorikk og sikkerhetskopier. Vi vil ikke diskutere hvert punkt i detalj, da jeg er sikker på at du er veldig kjent med det og bruker det i ditt daglige arbeid. Men hvis plutselig ikke, så anbefaler jeg å stoppe å lese denne artikkelen og fylle dette gapet så snart som mulig.
Verdi for automatiseringsinfrastruktur
Og her kan du stille et rimelig spørsmål: «Hvorfor forteller han oss om Git? Alle vet dette og bruker det både til utviklingskode og til autotestkode.» Du vil ha helt rett, men i denne artikkelen snakker vi om infrastruktur og denne delen fungerer som en forhåndsvisning for avsnitt 7: "Infrastructure as Code (IaC)". For oss betyr dette at hele infrastrukturen, inkludert testing, er beskrevet i form av kode, slik at vi også kan bruke versjonssystemer på den og få tilsvarende fordeler som for utviklings- og automatiseringskode.
Vi skal se på IaC mer detaljert i trinn 7, men selv nå kan du begynne å bruke Git lokalt ved å opprette et lokalt depot. Det store bildet vil bli utvidet når vi legger til et eksternt depot til infrastrukturen.
Illustrasjon av infrastrukturens nåværende tilstand
Lenker å utforske
Lignende verktøy
3. Containerisering (Docker)
Kort beskrivelse av teknologien
For å demonstrere hvordan containerisering har endret spillereglene, la oss gå noen tiår tilbake i tid. Den gang kjøpte og brukte folk servermaskiner for å kjøre applikasjoner. Men i de fleste tilfeller var de nødvendige oppstartsressursene ikke kjent på forhånd. Som et resultat brukte selskaper penger på kjøp av dyre, kraftige servere, men noe av denne kapasiteten ble ikke utnyttet fullt ut.
Neste trinn i utviklingen var virtuelle maskiner (VM), som løste problemet med å kaste bort penger på ubrukte ressurser. Denne teknologien gjorde det mulig å kjøre applikasjoner uavhengig av hverandre innenfor samme server, og allokerte fullstendig isolert plass. Men dessverre har enhver teknologi sine ulemper. Å kjøre en VM krever et fullstendig operativsystem, som bruker CPU, RAM, lagring og, avhengig av operativsystemet, må lisenskostnader tas i betraktning. Disse faktorene påvirker lastehastigheten og gjør portabiliteten vanskelig.
Og nå kommer vi til containerisering. Nok en gang løser denne teknologien det forrige problemet, da containere ikke bruker et fullstendig OS, noe som frigjør store mengder ressurser og gir en rask og fleksibel løsning for portabilitet.
Selvfølgelig er containeriseringsteknologi ikke noe nytt og ble først introdusert på slutten av 70-tallet. På den tiden ble det utført mye forskning, utvikling og forsøk. Men det var Docker som tilpasset denne teknologien og gjorde den lett tilgjengelig for massene. I dag, når vi snakker om containere, mener vi i de fleste tilfeller Docker. Når vi snakker om Docker-containere, mener vi Linux-containere. Vi kan bruke Windows- og macOS-systemer til å kjøre containere, men det er viktig å forstå at i dette tilfellet vises et ekstra lag. For eksempel kjører Docker på Mac containere inne i en lettvekts Linux VM. Vi kommer tilbake til dette emnet når vi diskuterer å kjøre Android-emulatorer inne i beholdere, så her er det en veldig viktig nyanse som må diskuteres mer detaljert.
Verdi for automatiseringsinfrastruktur
Vi fant ut at containerisering og Docker er kult. La oss se på dette i sammenheng med automatisering, fordi hvert verktøy eller teknologi må løse et problem. La oss skissere de åpenbare problemene med testautomatisering i sammenheng med UI-tester:
- et stort antall avhengigheter når du installerer Selenium og spesielt Appium;
- kompatibilitetsproblemer mellom versjoner av nettlesere, simulatorer og drivere;
- mangel på isolert plass for nettlesere/simulatorer, noe som er spesielt kritisk for parallellkjøring;
- vanskelig å administrere og vedlikeholde hvis du trenger å kjøre 10, 50, 100 eller til og med 1000 nettlesere samtidig.
Men siden Selenium er det mest populære automatiseringsverktøyet og Docker er det mest populære containeriseringsverktøyet, bør det ikke komme som noen overraskelse at noen har prøvd å kombinere dem for å lage et kraftig verktøy for å løse de ovennevnte problemene. La oss vurdere slike løsninger mer detaljert.
Selennett i docker
Dette verktøyet er det mest populære i Selenium-verdenen for å kjøre flere nettlesere på flere maskiner og administrere dem fra en sentral hub. For å starte må du registrere minst 2 deler: Hub og Node(r). Hub er en sentral node som mottar alle forespørsler fra tester og distribuerer dem til de aktuelle nodene. For hver node kan vi konfigurere en spesifikk konfigurasjon, for eksempel ved å spesifisere ønsket nettleser og dens versjon. Imidlertid må vi fortsatt ta vare på kompatible nettleserdrivere selv og installere dem på de ønskede nodene. Av denne grunn brukes ikke Selenium grid i sin rene form, bortsett fra når vi trenger å jobbe med nettlesere som ikke kan installeres på Linux OS. For alle andre tilfeller vil en betydelig fleksibel og korrekt løsning være å bruke Docker-bilder til å kjøre Selenium grid Hub og Nodes. Denne tilnærmingen forenkler nodeadministrasjonen betydelig, siden vi kan velge bildet vi trenger med kompatible versjoner av nettlesere og drivere som allerede er installert.
Til tross for negative anmeldelser om stabilitet, spesielt når du kjører et stort antall noder parallelt, er Selenium grid fortsatt det mest populære verktøyet for å kjøre Selenium-tester parallelt. Det er viktig å merke seg at ulike forbedringer og modifikasjoner av dette verktøyet stadig vises i åpen kildekode, som bekjemper ulike flaskehalser.
Selenoid for web
Dette verktøyet er et gjennombrudd i selen-verdenen ettersom det fungerer rett ut av esken og har gjort livet til mange automasjonsingeniører mye enklere. Først av alt, dette er ikke en annen modifikasjon av selennettet. I stedet laget utviklerne en helt ny versjon av Selenium Hub i Golang, som, kombinert med lette Docker-bilder for ulike nettlesere, satte fart på utviklingen av testautomatisering. Dessuten, når det gjelder Selenium Grid, må vi bestemme alle nødvendige nettlesere og deres versjoner på forhånd, noe som ikke er et problem når du arbeider med bare én nettleser. Men når det kommer til flere støttede nettlesere, er Selenoid nummer én løsning takket være funksjonen "nettleser på forespørsel". Alt som kreves av oss er å laste ned de nødvendige bildene med nettlesere på forhånd og oppdatere konfigurasjonsfilen som Selenoid samhandler med. Etter at Selenoid mottar en forespørsel fra testene, vil den automatisk starte ønsket beholder med ønsket nettleser. Når testen er fullført, vil Selenoid trekke beholderen tilbake, og dermed frigjøre ressurser for fremtidige forespørsler. Denne tilnærmingen eliminerer fullstendig det velkjente problemet med 'node-degradering' som vi ofte møter i selennett.
Men dessverre er Selenoid fortsatt ikke en sølvkule. Vi har funksjonen "nettleser på forespørsel", men funksjonen "ressurser på forespørsel" er fortsatt ikke tilgjengelig. For å bruke Selenoid må vi distribuere den på fysisk maskinvare eller på en VM, noe som betyr at vi må vite på forhånd hvor mange ressurser som må tildeles. Jeg antar at dette ikke er et problem for små prosjekter som kjører 10, 20 eller til og med 30 nettlesere parallelt. Men hva om vi trenger 100, 500, 1000 eller mer? Det gir ingen mening å vedlikeholde og betale for så mange ressurser hele tiden. I avsnitt 5 og 6 i denne artikkelen vil vi diskutere løsninger som lar deg skalere, og dermed redusere selskapets kostnader betydelig.
Selenoid for Android
Etter suksessen med Selenoid som et webautomatiseringsverktøy, ønsket folk noe lignende for Android. Og det skjedde - Selenoid ble utgitt med Android-støtte. Fra et brukersynspunkt på høyt nivå ligner operasjonsprinsippet webautomatisering. Den eneste forskjellen er at i stedet for nettleserbeholdere, kjører Selenoid Android-emulatorbeholdere. Etter min mening er dette for øyeblikket det kraftigste gratisverktøyet for å kjøre Android-tester parallelt.
Jeg vil virkelig ikke snakke om de negative sidene ved dette verktøyet, siden jeg virkelig liker det. Men likevel er det de samme ulempene som gjelder webautomatisering og er forbundet med skalering. I tillegg til dette må vi snakke om en begrensning til som kan komme som en overraskelse hvis vi setter opp verktøyet for første gang. For å kjøre Android-bilder trenger vi en fysisk maskin eller VM med nestet virtualiseringsstøtte. I veiledningen viser jeg hvordan du aktiverer dette på en Linux VM. Men hvis du er en macOS-bruker og ønsker å distribuere Selenoid lokalt, vil dette ikke være mulig å kjøre Android-tester. Men du kan alltid kjøre en Linux VM lokalt med "nested virtualisering" konfigurert og distribuere Selenoid inne.
Illustrasjon av infrastrukturens nåværende tilstand
I sammenheng med denne artikkelen vil vi legge til 2 verktøy for å illustrere infrastrukturen. Dette er Selenium grid for nettester og Selenoid for Android-tester. I GitHub-opplæringen vil jeg også vise deg hvordan du bruker Selenoid til å kjøre webtester.
Lenker å utforske
Lignende verktøy
- Det finnes andre containeriseringsverktøy, men Docker er det mest populære. Hvis du vil prøve noe annet, husk at verktøyene vi har dekket for å kjøre Selenium-tester parallelt, ikke vil fungere ut av esken.
- Som allerede sagt, er det mange modifikasjoner av selennettet, for eksempel,.
4.CI/CD
Kort beskrivelse av teknologien
Praksisen med kontinuerlig integrasjon er ganske populær i utviklingen og er på nivå med versjonskontrollsystemer. Til tross for dette føler jeg at det er forvirring i terminologien. I dette avsnittet vil jeg beskrive 3 modifikasjoner av denne teknologien fra mitt synspunkt. På internett finner du mange artikler med ulike tolkninger, og det er helt normalt hvis din mening er ulik. Det viktigste er at du er på samme side med kollegene dine.
Så det er 3 begreper: CI - Kontinuerlig integrasjon, CD - Kontinuerlig levering og igjen CD - Kontinuerlig distribusjon. (Nedenfor vil jeg bruke disse begrepene på engelsk). Hver endring legger til flere ekstra trinn til utviklingspipeline. Men ordet kontinuerlig (kontinuerlig) er det viktigste. I denne sammenheng mener vi noe som skjer fra start til slutt, uten avbrudd eller manuelle inngrep. La oss se på CI & CD og CD i denne sammenhengen.
- Kontinuerlig integrering dette er det første trinnet i evolusjonen. Etter å ha sendt inn ny kode til serveren forventer vi å få rask tilbakemelding om at endringene våre er ok. Vanligvis inkluderer CI kjøring av statiske kodeanalyseverktøy og enhets-/interne API-tester. Dette lar oss få informasjon om koden vår i løpet av få sekunder/minutter.
- Kontinuerlig Levering er et mer avansert trinn hvor vi kjører integrasjon/UI-tester. På dette stadiet får vi imidlertid ikke resultater like raskt som med CI. For det første tar disse typene tester lengre tid å fullføre. For det andre, før lansering, må vi implementere endringene våre i test-/staging-miljøet. Dessuten, hvis vi snakker om mobilutvikling, vises det et ekstra trinn for å lage en build av applikasjonen vår.
- Kontinuerlig distribusjon forutsetter at vi automatisk slipper våre endringer til produksjon dersom alle akseptprøver er bestått i de tidligere stadiene. I tillegg til dette, etter utgivelsesstadiet, kan du konfigurere ulike stadier, for eksempel å kjøre røyktester på produksjon og samle inn beregninger av interesse. Kontinuerlig distribusjon er bare mulig med god dekning av automatiserte tester. Hvis det er nødvendig med manuelle inngrep, inkludert testing, er dette ikke lenger Kontinuerlig (kontinuerlige). Da kan vi si at rørledningen vår kun er i samsvar med praksisen med kontinuerlig levering.
Verdi for automatiseringsinfrastruktur
I denne delen bør jeg presisere at når vi snakker om ende-til-ende UI-tester, betyr det at vi bør distribuere våre endringer og tilhørende tjenester til testmiljøer. Kontinuerlig integrasjon - prosessen er ikke aktuelt for denne oppgaven, og vi må sørge for å implementere minst Continuous Deliver-praksis. Continuous Deployment gir også mening i sammenheng med UI-tester hvis vi skal kjøre dem i produksjon.
Og før vi ser på illustrasjonen av arkitekturendringen, vil jeg si noen ord om GitLab CI. I motsetning til andre CI/CD-verktøy, gir GitLab et eksternt depot og mange andre tilleggsfunksjoner. Dermed er GitLab mer enn CI. Det inkluderer kildekodeadministrasjon, smidig administrasjon, CI/CD-pipelines, loggingsverktøy og metrikkinnsamling rett ut av boksen. GitLab-arkitekturen består av Gitlab CI/CD og GitLab Runner. Her er en kort beskrivelse fra den offisielle nettsiden:
Gitlab CI/CD er en webapplikasjon med en API som lagrer tilstanden i en database, administrerer prosjekter/bygg og gir et brukergrensesnitt. GitLab Runner er en applikasjon som behandler bygg. Den kan distribueres separat og fungerer med GitLab CI/CD gjennom en API. For å kjøre tester trenger du både Gitlab-forekomst og Runner.
Illustrasjon av infrastrukturens nåværende tilstand
Lenker å utforske
Lignende verktøy
- Og mange andre
5. Skyplattformer
Kort beskrivelse av teknologien
I denne delen vil vi snakke om en populær trend kalt 'offentlige skyer'. Til tross for de enorme fordelene som virtualiserings- og containeriseringsteknologiene beskrevet ovenfor gir, trenger vi fortsatt dataressurser. Bedrifter kjøper dyre servere eller leier datasentre, men i dette tilfellet er det nødvendig å gjøre beregninger (noen ganger urealistiske) av hvor mange ressurser vi trenger, om vi skal bruke dem 24/7 og til hvilke formål. For eksempel krever produksjon en server som kjører XNUMX/XNUMX, men trenger vi tilsvarende ressurser for testing utenom arbeidstid? Det avhenger også av typen testing som utføres. Et eksempel kan være belastnings-/stresstester som vi planlegger å kjøre utenom arbeidstid for å få resultater neste dag. Men definitivt XNUMX/XNUMX servertilgjengelighet er ikke nødvendig for ende-til-ende automatiserte tester og spesielt ikke for manuelle testmiljøer. For slike situasjoner vil det være greit å skaffe så mange ressurser som trengs på forespørsel, bruke dem og slutte å betale når de ikke lenger er nødvendige. Dessuten ville det være flott å motta dem umiddelbart ved å gjøre noen få museklikk eller kjøre et par skript. Det er dette offentlige skyer brukes til. La oss se på definisjonen:
"Den offentlige skyen er definert som datatjenester som tilbys av tredjepartsleverandører over det offentlige Internett, og gjør dem tilgjengelige for alle som ønsker å bruke eller kjøpe dem. De kan være gratis eller selges på forespørsel, slik at kundene kun kan betale per bruk for CPU-syklusene, lagringen eller båndbredden de bruker."
Det er en oppfatning at offentlige skyer er dyre. Men hovedideen deres er å redusere selskapets kostnader. Som nevnt tidligere lar offentlige skyer deg få ressurser på forespørsel og betale kun for tiden du bruker dem. Noen ganger glemmer vi også at ansatte mottar lønn, og spesialister er også en kostbar ressurs. Det må tas i betraktning at offentlige skyer gjør infrastrukturstøtte mye enklere, noe som gjør at ingeniører kan fokusere på viktigere oppgaver.
Verdi for automatiseringsinfrastruktur
Hvilke spesifikke ressurser trenger vi for ende-til-ende UI-tester? I utgangspunktet er dette virtuelle maskiner eller klynger (vi snakker om Kubernetes i neste avsnitt) for å kjøre nettlesere og emulatorer. Jo flere nettlesere og emulatorer vi ønsker å kjøre samtidig, jo mer CPU og minne kreves og jo mer penger må vi betale for det. Dermed lar offentlige skyer i sammenheng med testautomatisering oss kjøre et stort antall (100, 200, 1000...) nettlesere/emulatorer på forespørsel, få testresultater så raskt som mulig og slutte å betale for så sinnsykt ressurskrevende makt.
De mest populære skyleverandørene er Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Veiledningen gir eksempler på hvordan du bruker GCP, men generelt sett spiller det ingen rolle hva du bruker til automatiseringsoppgaver. De har alle omtrent samme funksjonalitet. Vanligvis, for å velge en leverandør, fokuserer ledelsen på hele selskapets infrastruktur og forretningskrav, noe som ligger utenfor rammen av denne artikkelen. For automatiseringsingeniører vil det være mer interessant å sammenligne bruken av skyleverandører med bruken av skyplattformer spesifikt til testformål, som Sauce Labs, BrowserStack, BitBar, og så videre. Så la oss gjøre det også! Etter min mening er Sauce Labs den mest kjente skytestinggården, og det er derfor jeg brukte den til sammenligning.
GCP vs Sauce Labs for automatiseringsformål:
La oss forestille oss at vi må kjøre 8 webtester og 8 Android-tester samtidig. Til dette vil vi bruke GCP og kjøre 2 virtuelle maskiner med Selenoid. På den første vil vi heve 8 containere med nettlesere. På den andre er det 8 beholdere med emulatorer. La oss ta en titt på prisene:
For å kjøre én beholder med Chrome, trenger vi n1-standard-1 bil. I tilfelle av Android vil det være det n1-standard-4 for én emulator. Faktisk er en mer fleksibel og billigere måte å sette spesifikke brukerverdier for CPU/minne, men for øyeblikket er ikke dette viktig for sammenligning med Sauce Labs.
Og her er tariffene for bruk av Sauce Labs:
Jeg tror du allerede har lagt merke til forskjellen, men jeg vil fortsatt gi en tabell med beregninger for oppgaven vår:
Nødvendige ressurser
Månedlig
Arbeidstid(8–8)
Arbeidstid+ Uttakbar
GCP for web
n1-standard-1 x 8 = n1-standard-8
$194.18
23 dager * 12 t * 0.38 = $ 104.88
23 dager * 12 t * 0.08 = $ 22.08
Saus Labs for web
Virtual Cloud8 parallelle tester
$1.559
-
-
GCP for Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 dager * 12 t * 1.52 = $ 419.52
23 dager * 12 t * 0.32 = $ 88.32
Sauce Labs for Android
Real Device Cloud 8 parallelle tester
$1.999
-
-
Som du kan se, er forskjellen i kostnad enorm, spesielt hvis du kjører tester bare i løpet av en tolv timers arbeidsperiode. Men du kan kutte kostnadene ytterligere hvis du bruker uttrekkbare maskiner. Hva er det?
En uttakbar VM er en forekomst som du kan opprette og kjøre til en mye lavere pris enn vanlige forekomster. Compute Engine kan imidlertid avslutte (foregripe) disse forekomstene hvis den krever tilgang til disse ressursene for andre oppgaver. Forekomster som kan fjernes er overflødig Compute Engine-kapasitet, så tilgjengeligheten deres varierer med bruken.
Hvis appene dine er feiltolerante og tåler mulige forekomster, kan uttakbare forekomster redusere Compute Engine-kostnadene betraktelig. For eksempel kan batchbehandlingsjobber kjøres på uttakbare forekomster. Hvis noen av disse forekomstene avsluttes under behandlingen, bremses jobben, men stopper ikke helt. Uttakbare forekomster fullfører batchbehandlingsoppgavene dine uten å legge ekstra arbeidsbelastning på eksisterende forekomster og uten at du må betale full pris for ekstra normale forekomster.
Og det er fortsatt ikke over! I virkeligheten er jeg sikker på at ingen kjører tester i 12 timer uten pause. Og i så fall kan du automatisk starte og stoppe virtuelle maskiner når de ikke er nødvendige. Faktisk brukstid kan reduseres til 6 timer per dag. Da vil betalingen i forbindelse med oppgaven vår reduseres til $11 per måned for 8 nettlesere. Er ikke dette fantastisk? Men med uttakbare maskiner må vi være forsiktige og forberedt på avbrudd og ustabilitet, selv om disse situasjonene kan sørges for og håndteres i programvare. Det er verdt det!
Men jeg sier på ingen måte "bruk aldri skytestfarmer". De har en rekke fordeler. For det første er dette ikke bare en virtuell maskin, men en fullverdig testautomatiseringsløsning med et sett med funksjonalitet ut av esken: fjerntilgang, logger, skjermbilder, videoopptak, ulike nettlesere og fysiske mobile enheter. I mange situasjoner kan dette være et essensielt elegant alternativ. Testplattformer er spesielt nyttige for IOS-automatisering, når offentlige skyer bare kan tilby Linux/Windows-systemer. Men vi vil snakke om iOS i de følgende artiklene. Jeg anbefaler å alltid se på situasjonen og ta utgangspunkt i oppgavene: i noen tilfeller er det billigere og mer effektivt å bruke offentlige skyer, og i andre er testplattformene definitivt verdt pengene brukt.
Illustrasjon av infrastrukturens nåværende tilstand
Lenker å utforske
Lignende verktøy:
6. Orkestrering
Kort beskrivelse av teknologien
Jeg har gode nyheter – vi er nesten på slutten av artikkelen! For øyeblikket består automatiseringsinfrastrukturen vår av nett- og Android-tester, som vi kjører gjennom GitLab CI parallelt, ved hjelp av Docker-aktiverte verktøy: Selenium grid og Selenoid. Dessuten bruker vi virtuelle maskiner opprettet via GCP for å være vert for containere med nettlesere og emulatorer. For å redusere kostnadene starter vi disse virtuelle maskinene kun på forespørsel og stopper dem når testing ikke utføres. Er det noe annet som kan forbedre infrastrukturen vår? Svaret er ja! Møt Kubernetes (K8s)!
La oss først se på hvordan ordene orkestrering, klynge og Kubernetes er relatert til hverandre. På et høyt nivå er orkestrering systemet som distribuerer og administrerer applikasjoner. For testautomatisering er slike containeriserte applikasjoner Selenium grid og Selenoid. Docker og K8s utfyller hverandre. Den første brukes til applikasjonsdistribusjon, den andre til orkestrering. I sin tur er K8s en klynge. Klyngens oppgave er å bruke VM-er som noder, som lar deg installere ulike funksjoner, programmer og tjenester innenfor en server (cluster). Hvis noen av nodene mislykkes, vil andre noder ta seg opp, noe som sikrer uavbrutt drift av applikasjonen vår. I tillegg til dette har K8s viktig funksjonalitet knyttet til skalering, takket være at vi automatisk oppnår den optimale mengden ressurser basert på belastningen og setter grenser.
I sannhet er det ikke en triviell oppgave å manuelt distribuere Kubernetes fra bunnen av. Jeg legger igjen en lenke til den berømte veiledningen "Kubernetes The Hard Way", og hvis du er interessert, kan du øve på den. Men heldigvis finnes det alternative metoder og verktøy. Den enkleste måten er å bruke Google Kubernetes Engine (GKE) i GCP, som lar deg få en ferdig klynge med noen få klikk. Jeg anbefaler å bruke denne tilnærmingen for å begynne å lære, da den vil tillate deg å fokusere på å lære hvordan du bruker K8-ene til oppgavene dine i stedet for å lære hvordan de interne komponentene skal integreres med hverandre.
Verdi for automatiseringsinfrastruktur
La oss ta en titt på noen viktige funksjoner som K8s gir:
- applikasjonsdistribusjon: bruk av en klynge med flere noder i stedet for virtuelle datamaskiner;
- dynamisk skalering: reduserer kostnadene for ressurser som bare brukes på forespørsel;
- selvhelbredende: automatisk gjenoppretting av pods (som et resultat av at beholdere også gjenopprettes);
- utrulling av oppdateringer og tilbakeføringer av endringer uten nedetid: oppdateringsverktøy, nettlesere og emulatorer avbryter ikke arbeidet til nåværende brukere
Men K8s er fortsatt ikke en sølvkule. For å forstå alle fordelene og begrensningene i sammenheng med verktøyene vi vurderer (Selenium grid, Selenoid), vil vi kort diskutere strukturen til K8s. Klyngen inneholder to typer noder: Hovednoder og Arbeidsnoder. Master Noder er ansvarlige for administrasjon, distribusjon og planleggingsbeslutninger. Arbeidernoder er der applikasjoner lanseres. Noder inneholder også et container-runtime-miljø. I vårt tilfelle er dette Docker, som er ansvarlig for containerrelaterte operasjoner. Men det finnes også alternative løsninger, for eksempel. Det er viktig å forstå at skalering eller selvhelbredelse ikke gjelder direkte for beholdere. Dette implementeres ved å legge til/redusere antall pods, som igjen inneholder containere (vanligvis én container per pod, men avhengig av oppgaven kan det være flere). Høynivåhierarkiet består av arbeidernoder, inne i hvilke det er pods, inne i hvilke containere er hevet.
Skaleringsfunksjonen er nøkkelen og kan brukes på både noder i en klynge-node-pool og pods i en node. Det er 2 typer skalering som gjelder både noder og poder. Den første typen er horisontal - skalering skjer ved å øke antall noder/pods. Denne typen er mer å foretrekke. Den andre typen er følgelig vertikal. Skalering utføres ved å øke størrelsen på noder/poder, og ikke antallet.
La oss nå se på verktøyene våre i sammenheng med vilkårene ovenfor.
Selennett
Som nevnt tidligere er selennett et veldig populært verktøy, og det er ingen overraskelse at det har blitt containerisert. Derfor kommer det ikke som noen overraskelse at Selenium grid kan distribueres i K8s. Et eksempel på hvordan du gjør dette finner du i det offisielle K8s-depotet. Som vanlig legger jeg ved lenker på slutten av avsnittet. I tillegg viser fremgangsmåten hvordan du gjør dette i Terraform. Det er også instruksjoner om hvordan du skalerer antall pods som inneholder nettleserbeholdere. Men den automatiske skaleringsfunksjonen i sammenheng med K8s er likevel ikke en helt åpenbar oppgave. Da jeg begynte å studere fant jeg ingen praktisk veiledning eller anbefalinger. Etter flere studier og eksperimenter med støtte fra DevOps-teamet, valgte vi tilnærmingen med å heve containere med de nødvendige nettleserne inne i én pod, som er plassert inne i én arbeidernode. Denne metoden lar oss bruke strategien for horisontal skalering av noder ved å øke antallet. Jeg håper at dette vil endre seg i fremtiden og vi vil se flere og flere beskrivelser av bedre tilnærminger og ferdige løsninger, spesielt etter utgivelsen av Selenium grid 4 med endret intern arkitektur.
Selenoid:
Selenoid-distribusjon i K8s er for øyeblikket den største skuffelsen. De er ikke kompatible. I teorien kan vi heve en Selenoid-beholder inne i en pod, men når Selenoid begynner å lansere containere med nettlesere, vil de fortsatt være inne i den samme poden. Dette gjør skalering umulig, og som et resultat vil ikke arbeidet til Selenoid inne i en klynge skille seg fra arbeid inne i en virtuell maskin. Slutt på historien.
Moon:
Utviklerne kjente til denne flaskehalsen når de jobbet med Selenoid, og ga ut et kraftigere verktøy kalt Moon. Dette verktøyet ble opprinnelig designet for å fungere med Kubernetes, og som et resultat kan og bør autoskaleringsfunksjonen brukes. Dessuten vil jeg si at det er det for øyeblikket den eneste et verktøy i Selenium-verdenen, som har innfødt K8s-klyngestøtte rett ut av esken (ikke lenger tilgjengelig, se neste verktøy ). Nøkkelfunksjonene til Moon som gir denne støtten er:
Helt statsløs. Selenoid lagrer informasjon om nettleserøkter som kjører i minnet. Hvis prosessen krasjer av en eller annen grunn - så går alle løpende økter tapt. Moon har derimot ingen intern tilstand og kan replikeres på tvers av datasentre. Nettleserøkter forblir i live selv om en eller flere replikaer går ned.
Så, Moon er en flott løsning, men det er ett problem: det er ikke gratis. Prisen avhenger av antall økter. Du kan kun kjøre 0-4 økter gratis, noe som ikke er spesielt nyttig. Men fra og med den femte økten må du betale $5 for hver. Situasjonen kan variere fra selskap til selskap, men i vårt tilfelle er det meningsløst å bruke Moon. Som jeg beskrev ovenfor, kan vi kjøre VM-er med Selenium Grid på forespørsel eller øke antall noder i klyngen. For omtrent én pipeline lanserer vi 500 nettlesere og stopper alle ressurser etter at testene er fullført. Hvis vi brukte Moon, måtte vi betale ytterligere 500 x 5 = $2500 per måned, uansett hvor ofte vi kjører tester. Igjen, jeg sier ikke at du ikke bruker Moon. For dine oppgaver kan dette være en uunnværlig løsning, for eksempel hvis du har mange prosjekter/team i din organisasjon og du trenger en enorm felles klynge for alle. Som alltid legger jeg igjen en lenke på slutten og anbefaler å gjøre alle nødvendige beregninger i forbindelse med oppgaven din.
Callisto: (Merk følgende! Dette er ikke i den originale artikkelen og finnes kun i den russiske oversettelsen)
Selen er som sagt et veldig populært verktøy, og IT-feltet utvikler seg veldig raskt. Mens jeg jobbet med oversettelsen, dukket et nytt lovende verktøy kalt Callisto opp på nettet (hei Cypress og andre selenmordere). Det fungerer naturlig med K8s og lar deg kjøre Selenoid-beholdere i pods, fordelt på noder. Alt fungerer rett ut av esken, inkludert autoskalering. Fantastisk, men må testes. Jeg har allerede klart å distribuere dette verktøyet og kjøre flere eksperimenter. Men det er for tidlig å trekke konklusjoner, etter å ha mottatt resultater over lang avstand, kanskje jeg vil gjøre en gjennomgang i fremtidige artikler. Foreløpig legger jeg kun igjen lenker for uavhengig forskning.
Illustrasjon av infrastrukturens nåværende tilstand
Lenker å utforske
Lignende verktøy
7. Infrastruktur som kode (IaC)
Kort beskrivelse av teknologien
Og nå kommer vi til den siste delen. Vanligvis er denne teknologien og relaterte oppgaver ikke automasjonsingeniørers ansvar. Og det er grunner til dette. For det første, i mange organisasjoner er infrastrukturspørsmål under kontroll av DevOps-avdelingen, og utviklingsteamene bryr seg egentlig ikke om hva som får rørledningen til å fungere og hvordan alt som er knyttet til den, må støttes. For det andre, la oss være ærlige, er praksisen med Infrastructure as Code (IaC) fortsatt ikke tatt i bruk i mange selskaper. Men det har definitivt blitt en populær trend og det er viktig å prøve å være involvert i prosessene, tilnærmingene og verktøyene knyttet til det. Eller i det minste holde deg oppdatert.
La oss starte med motivasjonen for å bruke denne tilnærmingen. Vi har allerede diskutert at for å kjøre tester i GitlabCI, trenger vi som et minimum ressursene for å kjøre Gitlab Runner. Og for å kjøre containere med nettlesere/emulatorer, må vi reservere en VM eller klynge. I tillegg til å teste ressurser trenger vi en betydelig mengde kapasitet for å støtte utvikling, iscenesettelse, produksjonsmiljøer, som også inkluderer databaser, automatiske tidsplaner, nettverkskonfigurasjoner, lastbalansere, brukerrettigheter og så videre. Nøkkelspørsmålet er innsatsen som kreves for å støtte det hele. Det er flere måter vi kan gjøre endringer og rulle ut oppdateringer. For eksempel, i sammenheng med GCP, kan vi bruke UI-konsollen i nettleseren og utføre alle handlinger ved å klikke på knappene. Et alternativ ville være å bruke API-kall for å samhandle med skyenheter, eller bruke kommandolinjeverktøyet gcloud for å utføre de ønskede manipulasjonene. Men med et virkelig stort antall forskjellige enheter og infrastrukturelementer, blir det vanskelig eller til og med umulig å utføre alle operasjoner manuelt. Dessuten er alle disse manuelle handlingene ukontrollerbare. Vi kan ikke sende dem til gjennomgang før utførelse, bruke et versjonskontrollsystem og raskt rulle tilbake endringene som førte til hendelsen. For å løse slike problemer har ingeniører laget og laget automatiske bash/shell-skript, som ikke er mye bedre enn tidligere metoder, siden de ikke er så enkle å raskt lese, forstå, vedlikeholde og modifisere i en prosedyrestil.
I denne artikkelen og veiledningen bruker jeg 2 verktøy relatert til IaC-praksis. Disse er Terraform og Ansible. Noen mennesker mener at det ikke gir mening å bruke dem samtidig, siden funksjonaliteten deres er lik og de er utskiftbare. Men faktum er at de i utgangspunktet får helt andre oppgaver. Og det faktum at disse verktøyene skulle utfylle hverandre ble bekreftet på en felles presentasjon av utviklere som representerer HashiCorp og RedHat. Den konseptuelle forskjellen er at Terraform er et klargjøringsverktøy for å administrere selve serverne. Mens Ansible er et konfigurasjonsadministrasjonsverktøy som har som oppgave å installere, konfigurere og administrere programvare på disse serverne.
Et annet viktig kjennetegn ved disse verktøyene er kodingsstilen. I motsetning til bash og Ansible, bruker Terraform en deklarativ stil basert på en beskrivelse av ønsket slutttilstand som skal oppnås som et resultat av utførelse. For eksempel, hvis vi skal lage 10 VM-er og bruke endringene gjennom Terraform, får vi 10 VM-er. Hvis vi kjører skriptet igjen, vil ingenting skje siden vi allerede har 10 VM-er, og Terraform vet om dette fordi den lagrer den nåværende tilstanden til infrastrukturen i en tilstandsfil. Men Ansible bruker en prosedyremessig tilnærming, og hvis du ber den om å lage 10 VM-er, vil vi ved første lansering få 10 VM-er, lik Terraform. Men etter omstart vil vi allerede ha 20 VM-er. Dette er den viktige forskjellen. I prosedyremessig stil lagrer vi ikke gjeldende tilstand og beskriver ganske enkelt en sekvens av trinn som må utføres. Selvfølgelig kan vi håndtere ulike situasjoner, legge til flere kontroller for eksistensen av ressurser og den nåværende tilstanden, men det er ingen vits i å kaste bort tiden vår og bruke krefter på å kontrollere denne logikken. I tillegg øker dette risikoen for å gjøre feil.
Ved å oppsummere alt det ovennevnte kan vi konkludere med at Terraform og deklarativ notasjon er et mer passende verktøy for klargjøring av servere. Men det er bedre å delegere arbeidet med konfigurasjonsadministrasjon til Ansible. Med det ute av veien, la oss se på brukstilfeller i sammenheng med automatisering.
Verdi for automatiseringsinfrastruktur
Det eneste viktige å forstå her er at testautomatiseringsinfrastrukturen bør betraktes som en del av hele selskapets infrastruktur. Dette betyr at all IaC-praksis må brukes globalt på ressursene til hele organisasjonen. Hvem som er ansvarlig for dette avhenger av dine prosesser. DevOps-teamet er mer erfarne i disse problemene, de ser hele bildet av hva som skjer. QA-ingeniører er imidlertid mer involvert i prosessen med bygningsautomatisering og strukturen til rørledningen, noe som gjør at de bedre kan se alle nødvendige endringer og forbedringsmuligheter. Det beste alternativet er å jobbe sammen, utveksle kunnskap og ideer for å oppnå det forventede resultatet.
Her er noen eksempler på bruk av Terraform og Ansible i sammenheng med testautomatisering og verktøyene vi diskuterte før:
1. Beskriv de nødvendige egenskapene og parameterne til virtuelle datamaskiner og klynger ved hjelp av Terraform.
2. Bruk Ansible, installer verktøyene som er nødvendige for testing: docker, Selenoid, Selenium Grid og last ned de nødvendige versjonene av nettlesere/emulatorer.
3. Bruk Terraform, beskriv egenskapene til VM-en der GitLab Runner vil bli lansert.
4. Installer GitLab Runner og de nødvendige medfølgende verktøyene ved å bruke Ansible, angi innstillinger og konfigurasjoner.
Illustrasjon av infrastrukturens nåværende tilstand
Linker å utforske:
Lignende verktøy
La oss oppsummere det!
Trinn
Teknologi
verktøy
Verdi for automatiseringsinfrastruktur
1
Lokal løping
Node.js, Selen, Appium
- De mest populære verktøyene for nett og mobil
- Støtter mange språk og plattformer (inkludert Node.js)
2
Versjonskontrollsystemer
gå
- Lignende fordeler med utviklingskode
3
Containerisering
Docker, Selenium grid, Selenoid (Web, Android)
- Kjøre tester parallelt
- Isolerte miljøer
- Enkle, fleksible versjonsoppgraderinger
- Dynamisk stoppe ubrukte ressurser
- Lett å sette opp
4
CI/CD
Gitlab CI
- Tester en del av rørledningen
- Rask tilbakemelding
- Synlighet for hele bedriften/teamet
5
Cloud plattformer
Google Cloud Platform
- Ressurser på forespørsel (vi betaler kun ved behov)
- Enkel å administrere og oppdatere
- Synlighet og kontroll over alle ressurser
6
orkestre
Kubernetes
I sammenheng med beholdere med nettlesere/emulatorer inne i pods:
- Skalering/automatisk skalering
- Selv helbreding
- Oppdateringer og tilbakeføringer uten avbrudd
7
Infrastruktur som en kode (IaC)
Terraform, Ansible
- Lignende fordeler med utviklingsinfrastruktur
- Alle fordelene med kodeversjon
- Enkel å gjøre endringer og vedlikeholde
- Helt automatisert
Tankekartdiagrammer: utvikling av infrastruktur
trinn 1: Lokal
trinn 2: VCS
trinn 3: Containerisering
trinn 4: CI/CD
trinn 5: Skyplattformer
trinn 6: Orkestrering
trinn 7: IaC
Hva blir det neste?
Så dette er slutten på artikkelen. Men avslutningsvis vil jeg gjerne etablere noen avtaler med deg.
Fra din side
Som sagt innledningsvis, vil jeg gjerne at artikkelen skal være til praktisk nytte og hjelpe deg å bruke kunnskapen du har fått i virkelig arbeid. Jeg legger til igjen.
Men selv etter det, ikke stopp, øv, studer relevante lenker og bøker, finn ut hvordan det fungerer i din bedrift, finn steder som kan forbedres og ta del i det. Lykke til!
Fra min side
Av tittelen kan du se at dette kun var den første delen. Til tross for at det viste seg å være ganske stort, er viktige temaer fortsatt ikke dekket her. I den andre delen planlegger jeg å se på automatiseringsinfrastruktur i sammenheng med IOS. På grunn av Apples restriksjoner på å kjøre iOS-simulatorer kun på macOS-systemer, er vårt utvalg av løsninger begrenset. For eksempel kan vi ikke bruke Docker til å kjøre simulatoren eller offentlige skyer for å kjøre virtuelle maskiner. Men dette betyr ikke at det ikke finnes andre alternativer. Jeg skal prøve å holde deg oppdatert med avanserte løsninger og moderne verktøy!
Jeg har heller ikke nevnt ganske store emner knyttet til overvåking. I del 3 skal jeg se på de mest populære verktøyene for infrastrukturovervåking og hvilke data og beregninger du bør vurdere.
Og endelig. I fremtiden planlegger jeg å gi ut et videokurs om å bygge testinfrastruktur og populære verktøy. For tiden er det ganske mange kurs og forelesninger om DevOps på Internett, men alt materiell presenteres i utviklingssammenheng, ikke testautomatisering. I denne saken trenger jeg virkelig tilbakemelding på om et slikt kurs vil være interessant og verdifullt for fellesskapet av testere og automasjonsingeniører. Takk på forhånd!
Kilde: www.habr.com