ProHoster > Blogg > Administration > DevOps-verktyg inte bara för DevOps. Processen att bygga infrastruktur för testautomatisering frÄn grunden

DevOps-verktyg inte bara för DevOps. Processen att bygga infrastruktur för testautomatisering frÄn grunden

Del 1: Web / Android

AnmÀrkning: denna artikel Àr en översÀttning till ryska av den ursprungliga artikeln «DevOps-verktyg Àr inte bara för DevOps. Att bygga testautomationsinfrastruktur frÄn grunden». Alla illustrationer, lÀnkar, citat och termer har dock behÄllits pÄ originalsprÄket för att undvika att betydelsen förvrÀngs vid översÀttningen till ryska. Jag önskar er en trevlig studie!

DevOps-verktyg inte bara för DevOps. Processen att bygga infrastruktur för testautomatisering frÄn grunden

För nĂ€rvarande Ă€r DevOps en av de mest efterfrĂ„gade yrkena inom IT-branschen. Om du öppnar populĂ€ra jobb-sökningssajter och stĂ€ller in din sökfilter för löner, sĂ„ ser du att DevOps-relaterade jobb ligger högst pĂ„ listan. Men det Ă€r viktigt att förstĂ„ att detta frĂ€mst gĂ€ller ‘Senior’-positioner, vilket innebĂ€r att kandidaten har en hög kompetensnivĂ„, kunskaper om teknologier och verktyg. Detta medför Ă€ven ett stort ansvar relaterat till att upprĂ€tthĂ„lla produktionens stabilitet. Men vi har börjat glömma vad DevOps egentligen Ă€r. Ursprungligen var det inte en specifik person eller avdelning. Om vi söker definitioner av detta begrepp, kommer vi att hitta mĂ„nga vackra och korrekta substantiv som metodik, praktiker, kulturell filosofi, en grupp koncept m.m.

Min specialisering Ă€r testeringsautomatiseringsingenjör (QA automation engineer), men jag anser att det inte bara bör handla om att skriva automatiserade tester eller utveckla arkitekturen för testframework. År 2020 Ă€r kunskap om automatiseringsinfrastruktur ocksĂ„ nödvĂ€ndigt. Det möjliggör att organisera automatiseringsprocessen pĂ„ egen hand, frĂ„n att köra tester till att tillhandahĂ„lla resultat till alla intresserade parter i linje med uppsatta mĂ„l. Som resultat Ă€r DevOps-fĂ€rdigheter en obligatorisk faktor för att utföra detta arbete. Och allt detta Ă€r bra, men tyvĂ€rr finns det ett problem (spoiler: denna artikel gör försök att förenkla detta problem). Den bestĂ„r i att DevOps Ă€r komplext. Och det Ă€r uppenbart, för företag kommer inte att betala mycket för nĂ„got som Ă€r lĂ€tt att göra... Inom DevOps finns det en mĂ€ngd verktyg, termer och praktiker som mĂ„ste behĂ€rskas. SĂ€rskilt Ă€r det svĂ„rt i början av karriĂ€ren och beror pĂ„ den mĂ€ngd teknisk erfarenhet som samlats.

DevOps-verktyg inte bara för DevOps. Processen att bygga infrastruktur för testautomatisering frÄn grunden
KĂ€lla: http://maximelanciauxbi.blogspot.com/2017/04/devops-tools.html

HÀr avslutar vi nog med introduktionen och fokuserar pÄ syftet med denna artikel. 

Vad handlar denna artikel om

I den hĂ€r artikeln kommer jag att dela med mig av min erfarenhet av att bygga infrastruktur för testautomatisering. Det finns mĂ„nga kĂ€llor pĂ„ internet om olika verktyg och hur man anvĂ€nder dem, men jag skulle vilja diskutera dem uteslutande i kontexten av automatisering. Jag tror att mĂ„nga automatiseringsingenjörer kĂ€nner igen situationen dĂ€r de utvecklade testerna, förutom av er sjĂ€lva, ingen kör eller tar hand om dem. Som ett resultat blir testerna förĂ„ldrade och man mĂ„ste lĂ€gga tid pĂ„ att uppdatera dem. Återigen kan detta vara en ganska komplex uppgift i början av karriĂ€ren: att smart besluta vilka verktyg som ska hjĂ€lpa till att lösa detta problem, hur man vĂ€ljer dem, konfigurerar och underhĂ„ller dem. Vissa testare söker hjĂ€lp frĂ„n DevOps (personer) och, Ă€rligt talat, sĂ„ fungerar den metoden. I mĂ„nga fall kan detta vara det enda alternativet, eftersom vi saknar insyn i alla beroenden. Men som vi vet, Ă€r DevOps mycket upptagna mĂ€nniskor, eftersom de mĂ„ste tĂ€nka pĂ„ infrastrukturen för hela företaget, deployment, övervakning, mikrotjĂ€nster och andra liknande uppgifter beroende pĂ„ organisationen/teamet. Som det ofta Ă€r, Ă€r automatisering inte en prioritet. I sĂ„dana fall mĂ„ste vi försöka göra allt vi kan frĂ„n början till slut. Detta minskar beroenden, pĂ„skyndar arbetsflödet, förbĂ€ttrar vĂ„ra fĂ€rdigheter och gör att vi kan se en större bild av vad som hĂ€nder.

Artikeln presenterar de mest efterfrÄgade och populÀra verktygen och visar hur man anvÀnder dem för en steg-för-steg-byggnad av automatiseringsinfrastruktur. Varje grupp presenteras med verktyg som har prövats i personlig erfarenhet. Men det betyder inte att du mÄste anvÀnda samma. SjÀlva verktygen Àr inte viktiga, de kommer och gÄr. VÄr ingenjörs uppgift Àr att förstÄ de grundlÀggande principerna: varför vi behöver denna grupp verktyg och vilka arbetsuppgifter vi kan lösa med hjÀlp av dem. DÀrför lÀmnar jag i slutet av varje avsnitt lÀnkar till liknande verktyg som möjligen anvÀnds i din organisation.

Vad som saknas i denna artikel

Jag upprepar Ànnu en gÄng att artikeln inte handlar om specifika verktyg, sÄ hÀr kommer det inte att finnas nÄgra kodexempel frÄn dokumentationen eller beskrivningar av specifika kommandon. Men i slutet av varje avsnitt lÀmnar jag lÀnkar för en mer detaljerad studie.

Detta har gjorts av följande skÀl: 

  • detta material Ă€r mycket lĂ€tt att hitta i olika kĂ€llor (dokumentation, böcker, videokurser);
  • om vi börjar fördjupa oss, kommer vi att behöva skriva 10, 20, 30 delar av denna artikel (nĂ€r vi planerar 2-3);
  • jag vill helt enkelt inte slösa din tid, eftersom du möjligen vill anvĂ€nda andra verktyg för att uppnĂ„ samma mĂ„l.

Praxis

Jag skulle verkligen vilja att detta material Àr anvÀndbart för varje lÀsare, och inte bara lÀses och glöms bort. I varje inlÀrning Àr praxis en mycket viktig komponent. För detta har jag förberett ett GitHub-repo med en steg-för-steg-guide om hur man gör allt frÄn grunden. Du fÄr ocksÄ en hemuppgift för att vara sÀker pÄ att du inte slentrianmÀssigt kopierar utförande kommandon.

Plan

Steg
Teknik
Verktyg

1
Lokal körning (förbereda webben / android demotester och köra det lokalt) 
Node.js, Selenium, Appium

2
Versionshanteringssystem 
Git

3
Containerisering
Docker, Selenium grid, Selenoid (Web, Android)

4
CI / CD
Gitlab CI

5
Molnplattformar
Google Cloud Platform

6
Orkestrering
Kubernetes

7
Infrastruktur som kod (IaC)
Terraform, Ansible

Strukturen för varje avsnitt

För att hÄlla berÀttelsen visuellt klar, beskrivs varje avsnitt enligt följande plan:

  • kort beskrivning av tekniken,
  • vĂ€rdet för automatiseringsinfrastruktur,
  • illustration av det aktuella tillstĂ„ndet för infrastrukturen,
  • lĂ€nkar för studier,
  • liknande verktyg.

1. Lokal körning av tester

Kort beskrivning av tekniken

Detta Àr bara ett förberedande steg för att köra demonstrativa tester lokalt och för att kontrollera att de lyckas. I den praktiska delen anvÀnds Node.js, men programmeringssprÄket och plattformen Àr inte sÄ viktiga och man kan anvÀnda de som anvÀnds i ditt företag. 

Men som automatiseringsverktyg rekommenderar jag att anvÀnda Selenium WebDriver för webplattformar och Appium för Android-plattformen, eftersom vi i nÀsta steg kommer att anvÀnda Docker-bilder som Àr anpassade för att arbeta specifikt med dessa verktyg. Dessutom, med hÀnvisning till kraven i jobbannonserna, Àr dessa verktyg de mest efterfrÄgade pÄ marknaden.

Som du kanske har mÀrkt, fokuserar vi endast pÄ web och Android-tester. TyvÀrr Àr IOS en helt annan historia (tack Apple). Jag planerar att demonstrera lösningar och metoder kopplade till IOS i kommande delar.

VÀrde för automatiseringsinfrastruktur

Sett ur infrastrukturens perspektiv ger lokal körning inget vÀrde. Du kontrollerar bara att tester fungerar pÄ en lokal maskin i lokala webblÀsare och simuleringar. Men oavsett Àr det en nödvÀndig utgÄngspunkt.

Illustration av det nuvarande tillstÄndet för infrastrukturen

DevOps-verktyg inte bara för DevOps. Processen att bygga infrastruktur för testautomatisering frÄn grunden

LÀnkar för studier

Liknande verktyg

  • valfri programmeringssprĂ„k du gillar, i kombination med Selenium/Appium-tester;
  • valfria tester;
  • valfri test-runner.

2. Versionshanteringssystem (Git)

Kort beskrivning av tekniken

Ingen kommer att bli förvÄnad om jag sÀger att versionshanteringssystem Àr en extremt viktig del av utveckling bÄde i team och individuellt. Med stöd av olika kÀllor kan man med sÀkerhet sÀga att Git Àr den mest populÀra representanterna. Versionshanteringssystemet erbjuder mÄnga fördelar, sÄsom koddelning, versionslagring, ÄterstÀllning till tidigare grenar, övervakning av projektets historia och backup. Vi kommer inte att diskutera varje punkt i detalj, eftersom jag Àr sÀker pÄ att ni Àr vÀl bekanta med detta och anvÀnder det i ert dagliga arbete. Men om ni mot förmodan inte Àr det, rekommenderar jag att ni pausar lÀsningen av denna artikel och snabbt ÄtgÀrdar denna brist.

VÀrde för automatiseringsinfrastruktur

HÀr kan ni stÀlla en rimlig frÄga: "Varför berÀttar han för oss om Git? Alla vet och anvÀnder detta för bÄde kodutveckling och autotestning." Ni har helt rÀtt, men i denna artikel pratar vi om infrastruktur och denna sektion fungerar som en förhandsvisning för sektion 7: "Infrastruktur som kod (IaC)". För oss innebÀr detta att hela infrastrukturen, inklusive testinfrastrukturen, beskrivs i form av kod, och vi kan alltsÄ ocksÄ tillÀmpa versionshanteringssystem och fÄ liknande fördelar som för kodutveckling och automatisering.

Vi kommer att titta nÀrmare pÄ IaC i steg 7, men Àven nu kan du börja anvÀnda Git lokalt genom att skapa ett lokalt förrÄd. Den övergripande bilden kommer att utvidgas nÀr vi lÀgger till ett fjÀrrförrÄd till infrastrukturen.

Illustration av det nuvarande tillstÄndet för infrastrukturen

DevOps-verktyg inte bara för DevOps. Processen att bygga infrastruktur för testautomatisering frÄn grunden

LÀnkar för studier

Liknande verktyg

3. Containerisering (Docker)

Kort beskrivning av tekniken

För att demonstrera hur containerisering har förÀndrat spelreglerna, lÄt oss resa flera decennier tillbaka i tiden. PÄ den tiden köpte och anvÀnde mÀnniskor servermaskiner för att köra applikationer. Men i de flesta fall var de nödvÀndiga resurserna för driften inte kÀnda i förvÀg. DÀrför spenderade företag pengar pÄ att köpa dyra kraftfulla servrar, men en del av denna kapacitet utnyttjades inte helt.

Den nÀsta fasen i evolutionen var virtuella maskiner (VM), som löste problemet med onödiga kostnader för outnyttjade resurser. Denna teknologi gjorde det möjligt att köra applikationer oberoende av varandra inom en och samma server, och att tilldela helt isolerat utrymme. Men tyvÀrr har varje teknologi sina nackdelar. Att köra VM krÀver ett fullt operativsystem, som förbrukar CPU, RAM, lagring, och beroende pÄ OS bör man Àven ta hÀnsyn till licenskostnader. Dessa faktorer pÄverkar laddningstiden och komplicerar portabiliteten.

Och hĂ€r har vi kommit till containerisering. Återigen har denna teknologi löst det tidigare problemet, eftersom containrar inte anvĂ€nder ett fullt operativsystem, vilket frigör mycket resurser och erbjuder en snabb och flexibel lösning för portabilitet.

SjÀlvklart Àr containerteknologi inget nytt och introducerades först i slutet av 70-talet. Under den tiden gjordes mÄnga studier, utvecklingar och försök. Men det var just Docker som anpassade denna teknologi och gjorde den lÀttillgÀnglig för massorna. I vÄr tid, nÀr vi talar om containrar, menar vi oftast Docker. NÀr vi pratar om Docker-containrar syftar vi pÄ Linux-containrar. Vi kan anvÀnda Windows och macOS-system för att köra containrar, men det Àr viktigt att förstÄ att det dÄ uppstÄr ett extra lager. Till exempel kör Docker pÄ Mac osynligt containrar inuti en lÀttvikts Linux VM. Vi kommer att Äterkomma till detta Àmne nÀr vi diskuterar körning av Android-emulatorer inuti containrar, eftersom det hÀr finns en mycket viktig detalj som vi behöver gÄ igenom mer ingÄende.

VÀrde för automatiseringsinfrastruktur

Vi har kommit fram till att containerisering och Docker Àr fantastiskt. LÄt oss se pÄ detta i kontexten av automatisering, eftersom varje verktyg eller teknologi mÄste lösa nÄgot problem. LÄt oss identifiera de uppenbara problemen med automatisering av tester i kontexten av UI-tester:

  • ett enormt antal beroenden vid installation av Selenium och sĂ€rskilt Appium;
  • kompatibilitetsproblem mellan webblĂ€sarversioner, simulatorer och drivrutiner;
  • brist pĂ„ isolerat utrymme för webblĂ€sare/simulatorer, vilket Ă€r sĂ€rskilt kritiskt för parallell körning;
  • svĂ„rt att hantera och underhĂ„lla om man behöver köra 10, 50, 100 eller till och med 1000 webblĂ€sare samtidigt.

Men eftersom Selenium Àr det mest populÀra verktyget för automatisering och Docker Àr det mest populÀra verktyget för containerisering, borde det inte förvÄna nÄgon att nÄgon har försökt att kombinera dem för att fÄ ett kraftfullt verktyg för att lösa de ovan nÀmnda problemen. LÄt oss titta pÄ sÄdana lösningar mer i detalj. 

Selenium grid in docker

Det hÀr verktyget Àr det mest populÀra i vÀrlden för att köra flera webblÀsare pÄ flera maskiner och hantera dem frÄn en central nod. För att köra det mÄste minst tvÄ delar registreras: Hub och Node(s). Hub Àr den centrala noden som tar emot alla förfrÄgningar frÄn tester och fördelar dem till de aktuella noderna. För varje nod kan vi konfigurera specifika instÀllningar, till exempel genom att ange vilken webblÀsare och vilken version som behövs. Men vi mÄste fortfarande se till att de kompatibla drivrutinerna för webblÀsarna finns och installeras pÄ de aktuella noderna. Av denna anledning anvÀnds Selenium grid sÀllan i sin rena form, utom nÀr vi behöver arbeta med webblÀsare som inte kan installeras pÄ Linux OS. För alla andra situationer Àr anvÀndningen av Docker-bilder för att köra Selenium grid Hub och Noder en mycket flexibel och korrekt lösning. Detta tillvÀgagÄngssÀtt förenklar hanteringen av noderna avsevÀrt, eftersom vi kan vÀlja den bild som passar oss med redan installerade kompatibla versioner av webblÀsare och drivrutiner.

Trots negativa omdömen om stabiliteten vid körning av ett stort antal noder parallellt, förblir Selenium grid fortfarande det mest populÀra verktyget för parallell körning av Selenium-tester. Det Àr viktigt att notera att det stÀndigt görs olika förbÀttringar och modifieringar av detta verktyg inom open-source som ÄtgÀrdar olika flaskhalsar.

Selenoid för Web

Det hÀr verktyget Àr ett genombrott inom Selenium, eftersom det fungerar direkt ur boxen och har gjort livet betydligt enklare för mÄnga automatiseringsingenjörer. Först och frÀmst Àr det inte en ny version av Selenium Grid. IstÀllet har utvecklarna skapat en helt ny version av Selenium Hub i Golang, vilket i kombination med lÀtta Docker-bilder för olika webblÀsare har gett ett viktigt lyft för testautomatisering. Dessutom, nÀr det gÀller Selenium Grid mÄste vi pÄ förhand definiera alla nödvÀndiga webblÀsare och deras versioner, vilket inte Àr ett problem nÀr vi endast arbetar med en viss webblÀsare. Men nÀr det handlar om flera stödjande webblÀsare Àr Selenoid den bÀsta lösningen, tack vare funktionen 'webblÀsare pÄ begÀran'. Allt vi behöver göra Àr att pÄ förhand ladda ner de nödvÀndiga bilderna med webblÀsare och uppdatera konfigurationsfilen som Selenoid interagerar med. NÀr Selenoid fÄr en begÀran frÄn testerna startar den automatiskt rÀtt container med rÀtt webblÀsare. NÀr testen Àr avslutade stÀnger Selenoid ner containern, vilket frigör resurser för nÀsta begÀran. Denna metod eliminerar helt den kÀnda problemet med 'noddegradering', som vi ofta stöter pÄ i Selenium Grid.

Men tyvÀrr Àr Selenoid fortfarande ingen lösning pÄ alla problem. Vi har fÄtt funktionen 'webblÀsare pÄ begÀran', men funktionen 'resurser pÄ begÀran' Àr fortfarande inte tillgÀnglig. För att anvÀnda Selenoid mÄste vi distribuera det pÄ fysisk hÄrdvara eller pÄ en virtuell maskin, vilket innebÀr att vi pÄ förhand mÄste veta hur mycket resurser vi behöver tilldela. Jag tror inte att detta Àr ett problem för smÄ projekt som kör 10, 20 eller till och med 30 webblÀsare parallellt. Men vad hÀnder om vi behöver 100, 500, 1000 och mer? Det Àr meningslöst att stÀndigt stötta och betala för ett sÄdant antal resurser. I avsnitt 5 och 6 av denna artikel kommer vi att diskutera lösningar som möjliggör skalning, vilket avsevÀrt minskar företagets kostnader.

Selenoid för Android

Efter framgĂ„ngen med Selenoid som verktyg för webbautomatisering ville folk ha nĂ„got liknande för Android. Och detta har nu blivit verklighet – Selenoid har slĂ€ppts med stöd för Android. Ur ett högre anvĂ€ndarperspektiv fungerar den pĂ„ samma sĂ€tt som webbautomatisering. Den enda skillnaden Ă€r att istĂ€llet för behĂ„llare med webblĂ€sare kör Selenoid behĂ„llare med Android-emulatorer. Enligt min mening Ă€r detta just nu det mest kraftfulla gratisverktyget för att köra Android-tester parallellt.

Jag skulle verkligen inte vilja talk om de negativa aspekterna av detta verktyg, eftersom jag faktiskt gillar det mycket. Men det finns ÀndÄ nÄgra nackdelar som ocksÄ gÀller webbautomatisering, relaterat till skalbarhet. Dessutom mÄste jag nÀmna en annan begrÀnsning som kan komma som en överraskning om vi konfigurerar verktyget för första gÄngen. För att köra Android-bilder behöver vi en fysisk maskin eller en VM med stöd för nested virtualisation. I den praktiska guiden visar jag hur man aktiverar detta pÄ Linux VM. Men om du Àr en macOS-anvÀndare och vill köra Selenoid lokalt, kommer det att vara omöjligt att köra Android-tester. Men du kan alltid köra en Linux VM lokalt med konfigurerad 'nested virtualisation' och köra Selenoid inuti.

Illustration av det nuvarande tillstÄndet för infrastrukturen

I denna artikel kommer vi att lÀgga till tvÄ verktyg för att illustrera infrastrukturen. Detta Àr Selenium grid för webbtester och Selenoid för Android-tester. I guiden pÄ GitHub visar jag ocksÄ hur man anvÀnder Selenoid för att köra webbtester. 

DevOps-verktyg inte bara för DevOps. Processen att bygga infrastruktur för testautomatisering frÄn grunden

LÀnkar för studier

Liknande verktyg

  • Det finns andra containeriseringsverktyg, men Docker Ă€r det mest populĂ€ra. Om du vill prova nĂ„got annat, kom ihĂ„g att de verktyg vi har granskat för parallell körning av Selenium-tester inte kommer att fungera direkt.  
  • Som redan nĂ€mnts finns det mĂ„nga modifikationer av Selenium grid, till exempel Zalenium.

4. CI / CD

Kort beskrivning av tekniken

Praktiken för kontinuerlig integration Àr ganska populÀra inom utveckling och stÄr pÄ samma nivÄ som versionshanteringssystem. Trots detta kÀnner jag att det finns förvirring kring terminologin. I detta stycke skulle jag vilja beskriva tre modifieringar av denna teknik utifrÄn mitt perspektiv. PÄ internet kan du hitta mÄnga artiklar med olika tolkningar, och det Àr helt okej om din Äsikt avviker. Det viktigaste Àr att ni Àr pÄ samma sida som era kollegor.

SĂ„ledes finns det tre termer: CI – Continuous Integration (kontinuerlig integration), CD – Continuous Delivery (kontinuerlig leverans) och Ă„terigen CD – Continuous Deployment (kontinuerlig driftsĂ€ttning). (Vidare kommer jag att anvĂ€nda dessa termer pĂ„ engelska). Varje modifiering lĂ€gger till nĂ„gra extra steg till din utvecklingspipeline. Men ordet continuous (kontinuerlig) Ă€r det mest centrala. I detta sammanhang avser vi nĂ„got som sker frĂ„n början till slut, utan avbrott eller manuell inblandning. LĂ„t oss titta pĂ„ CI & CD och CD i detta sammanhang.

  • Continuous Integration – Ă€r det inledande steget i evolutionen. Efter att ny kod har skickats till servern förvĂ€ntar vi oss att fĂ„ snabb feedback, att allt Ă€r okej med vĂ„ra Ă€ndringar. Vanligtvis inkluderar CI körning av verktyg för statisk kodanalys och modulĂ€ra/interna API-tester. Detta gör det möjligt att fĂ„ information om vĂ„r kod nĂ„gra sekunder/minuter senare.
  • Kontinuerlig leverans Ă€r ett mer avancerat steg, dĂ€r vi kör integrations/UI-tester. Men i detta skede fĂ„r vi inte resultat lika snabbt som i fallet med CI. För det första tar dessa typer av tester lĂ€ngre tid att genomföra. För det andra mĂ„ste vi före körningen distribuera vĂ„ra Ă€ndringar pĂ„ test/staging-miljö. Dessutom, om vi pratar om mobilutveckling, tillkommer ett extra steg för att skapa en byggnad av vĂ„r applikation.
  • Continuous Deployment innebĂ€r att vi automatiskt slĂ€pper (release) vĂ„ra Ă€ndringar till produktion om alla acceptanstester har passerats i de tidigare stegen. Dessutom kan olika steg, sĂ„som att köra smoke-tester pĂ„ produktionen och samla intressanta mĂ€tvĂ€rden, konfigureras efter release-steget. Continuous Deployment Ă€r möjligt endast med bra tĂ€ckning av automatiserade tester. Om nĂ„gra manuella ingrepp krĂ€vs, inklusive testning, sĂ„ Ă€r det inte lĂ€ngre Continuous (kontinuerlig). DĂ„ kan vi sĂ€ga att vĂ„r pipeline endast uppfyller praktiken för Continuous Delivery.

VÀrde för automatiseringsinfrastruktur

I detta avsnitt mÄste jag klargöra att nÀr vi pratar om end-to-end UI-tester, innebÀr det att vi mÄste distribuera vÄra Àndringar och relaterade tjÀnster till testmiljöer. Continuous Integration-processen Àr inte tillÀmplig pÄ denna uppgift och vi mÄste ta hand om att implementera minst Continuous Delivery-praktiker. Continuous Deployment har ocksÄ betydelse i samband med UI-tester om vi planerar att köra dem pÄ produktionen.

Och innan vi tittar pÄ illustrationen av förÀndringen i arkitekturen, vill jag sÀga nÄgra ord om GitLab CI. Till skillnad frÄn andra CI/CD-verktyg erbjuder GitLab ett fjÀrrarkiv och mÄnga andra ytterligare funktioner. SÄledes Àr GitLab mer Àn bara CI. Det inkluderar inbyggd kÀllkodshantering, Agile-hantering, CI/CD-pipelines, loggningsverktyg och insamling av mÀtvÀrden. Arkitekturen för GitLab bestÄr av GitLab CI/CD och GitLab Runner. HÀr Àr en kort beskrivning frÄn den officiella webbplatsen:

Gitlab CI/CD Àr en webbapplikation med ett API som lagrar sitt tillstÄnd i en databas, hanterar projekt/byggen och tillhandahÄller ett anvÀndargrÀnssnitt. GitLab Runner Àr en applikation som bearbetar byggen. Den kan distribueras separat och arbetar med GitLab CI/CD genom ett API. För att köra tester behöver du bÄde GitLab-instansen och Runnern.

Illustration av det nuvarande tillstÄndet för infrastrukturen

DevOps-verktyg inte bara för DevOps. Processen att bygga infrastruktur för testautomatisering frÄn grunden

LÀnkar för studier

Liknande verktyg

5. Molnplattformar

Kort beskrivning av tekniken

I det hÀr avsnittet kommer vi att diskutera en populÀr trend som kallas 'publika moln'. Trots den stora nytta som de ovan beskrivna teknologierna för virtualisering och containerisering ger, behöver vi fortfarande datorkapacitet. Företag köper dyra servrar eller hyr datacenter, men i sÄdana fall mÄste man göra berÀkningar (ibland orealistiska) om hur mycket resurser vi kommer att behöva, om vi kommer att anvÀnda dem 24/7 och för vilka ÀndamÄl. Till exempel, för produktion krÀvs det att servern Àr aktiv dygnet runt, men behöver vi liknande resurser för testning under outnyttjad tid? Detta beror ocksÄ pÄ typen av test som genomförs. Ett exempel kan vara belastnings-/stress-tester som vi planerar att köra under outnyttjad tid för att fÄ resultat nÀsta dag. Men, definitivt, dygnet runt tillgÄng pÄ servrar Àr inte nödvÀndig för end-to-end automatiserade tester och speciellt för miljöer för manuell testning. För sÄdana situationer skulle det vara bra att fÄ precis sÄ mycket resurser som behövs pÄ begÀran, anvÀnda dem och sluta betala nÀr de inte lÀngre behövs. Dessutom skulle det vara fantastiskt att fÄ dem omedelbart, efter att ha gjort nÄgra musklick eller kört ett par skript. Det Àr dÀrför publika moln anvÀnds. LÄt oss titta pÄ definitionen:

“Det publika molnet definieras som datortjĂ€nster som erbjuds av tredjepartsleverantörer över det offentliga internet, vilket gör dem tillgĂ€ngliga för alla som vill anvĂ€nda eller köpa dem. De kan vara gratis eller sĂ€ljas pĂ„ begĂ€ran, vilket gör att kunder endast betalar för den anvĂ€ndning av CPU-cykler, lagring eller bandbredd de konsumera.”

Det rÄder en uppfattning om att publika moln Àr dyra. Men deras centrala idé Àr att minska företagets kostnader. Som nÀmnts tidigare möjliggör publika moln att fÄ resurser pÄ begÀran och betala endast för den tid de anvÀnds. Dessutom glömmer vi ibland att anstÀllda fÄr lön och specialister Àr ocksÄ en dyr resurs. Det Àr viktigt att beakta att publika moln avsevÀrt förenklar supporten av infrastrukturen, vilket gör att ingenjörerna kan fokusera pÄ viktigare uppgifter. 

VÀrde för automatiseringsinfrastruktur

Vilka specifika resurser behöver vi för end-to-end UI-tester? I huvudsak handlar det om virtuella maskiner eller kluster (vi kommer att prata om Kubernetes i nĂ€sta avsnitt) för att köra webblĂ€sare och emulatorer. Ju fler webblĂ€sare och emulatorer vi vill köra samtidigt, desto mer CPU och minne behövs, och desto mer pengar mĂ„ste vi betala för detta. PĂ„ sĂ„ sĂ€tt möjliggör offentliga moln i samband med testautomatisering att vi kan köra ett stort antal (100, 200, 1000
) webblĂ€sare/emulatorer pĂ„ begĂ€ran, fĂ„ testresultat sĂ„ snabbt som möjligt och sluta betala för dessa galet resurskrĂ€vande resurser. 

De mest populÀra molnleverantörerna Àr Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). I den praktiska guiden presenteras exempel pÄ anvÀndning av GCP, men generellt spelar det ingen roll vad du faktiskt anvÀnder för automatiseringsuppgifter. De erbjuder alla ungefÀr samma funktionalitet. Vanligtvis fokuserar guiden pÄ hela företagets infrastruktur och affÀrskrav, vilket ligger utanför denna artikel. För automatiseringsingenjörer skulle det vara mer intressant att jÀmföra anvÀndningen av molnleverantörer med anvÀndning av molnplattformar specifikt för testningsÀndamÄl, som Sauce Labs, BrowserStack, BitBar och sÄ vidare. SÄ lÄt oss göra det! Enligt min Äsikt Àr Sauce Labs den mest kÀnda molntestningsplattformen, dÀrför valde jag den för jÀmförelse. 

GCP mot Sauce Labs för automatiseringsÀndamÄl:

LĂ„t oss anta att vi behöver köra 8 web-tester och 8 Android-tester samtidigt. För detta kommer vi att anvĂ€nda GCP och starta 2 virtuella maskiner med Selenoid. PĂ„ den första ska vi köra 8 containrar med webblĂ€sare. PĂ„ den andra – 8 containrar med emulatorer. LĂ„t oss titta pĂ„ priserna:  

DevOps-verktyg inte bara för DevOps. Processen att bygga infrastruktur för testautomatisering frÄn grunden
För att starta en container med Chrome behöver vi n1-standard-1 maskin. I fallet med Android blir det n1-standard-4 för en emulator. Egentligen Àr ett mer flexibelt och billigare sÀtt att ange specifika anvÀndarvÀrden för CPU/Minne, men för tillfÀllet Àr detta inte avgörande för jÀmförelsen med Sauce Labs.

HÀr Àr priserna för att anvÀnda Sauce Labs:

DevOps-verktyg inte bara för DevOps. Processen att bygga infrastruktur för testautomatisering frÄn grunden
Jag antar att du redan har mÀrkt skillnaden, men jag ger fortfarande en tabell med berÀkningar för vÄr uppgift:

NödvÀndiga resurser
MĂ„nadsvis
Arbetstimmar(8 a.m — 8 p.m)
Arbetstimmar+ Preemptible

GCP för Web
n1-standard-1 x 8 = n1-standard-8
$194.18
23 dagar * 12h * 0.38 = 104.88$ 
23 dagar * 12h * 0.08 = 22.08$

Sauce Labs för Web
Virtuell Cloud8 parallella tester
$1.559
—
—

GCP för Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 dagar * 12h * 1.52 = 419.52$ 
23 dagar * 12h * 0.32 = 88.32$

Sauce Labs för Android
Real Device Cloud 8 parallella tester
$1.999
—
—

Som du kan se, Àr kostnadsskillnaden enorm, sÀrskilt om testerna körs endast under den arbetsmÀssiga tolv timmars perioden. Men kostnaderna kan ytterligare minskas om preemptible maskiner anvÀnds. Vad innebÀr det?

En preemptible VM Àr en instans som du kan skapa och köra till ett mycket lÀgre pris Àn vanliga instanser. Men Compute Engine kan avbryta (preempt) dessa instanser om den behöver tillgÄng till dessa resurser för andra uppgifter. Preemptible instanser Àr överskottskapacitet frÄn Compute Engine, sÄ deras tillgÀnglighet varierar med anvÀndning.

Om dina appar Àr fel-tÄliga och kan stÄ emot möjliga instans-avbrott, kan preemptible instanser minska dina Compute Engine-kostnader avsevÀrt. Till exempel kan batchbearbetningsjobb köras pÄ preemptible instanser. Om nÄgra av dessa instanser avslutas under bearbetningen saktas jobbet ned men stoppas inte helt. Preemptible instanser slutför dina batchbearbetningsuppgifter utan att öka arbetsbelastningen pÄ dina befintliga instanser och utan att du behöver betala fullt pris för ytterligare normala instanser.

Och det Ă€r fortfarande inte slut! I verkligheten Ă€r jag sĂ€ker pĂ„ att ingen kör tester i 12 timmar utan avbrott. Och om sĂ„ Ă€r fallet, kan du automatiskt starta och stoppa virtuella maskiner nĂ€r de inte behövs. Den verkliga anvĂ€ndningen kan minskas till 6 timmar per dag. DĂ„ skulle kostnaden i vĂ„r situation sjunka till sĂ„ lĂ„gt som 11$ i mĂ„naden för 8 webblĂ€sare. Är inte det fantastiskt? Men med preemptible maskiner mĂ„ste vi vara försiktiga och förberedda pĂ„ avbrott och instabilitet, Ă€ven om dessa situationer kan förutses och hanteras programmĂ€ssigt. Det Ă€r vĂ€rt det!

Men jag sÀger absolut inte 'anvÀnd aldrig molntestfarmar'. De har flera fördelar. För det första Àr det inte bara en virtuell maskin, utan en fullstÀndig lösning för automatisering av tester med ett paket funktioner direkt ur lÄdan: fjÀrrÄtkomst, loggar, skÀrmdumpar, videoinspelningar, olika webblÀsare och fysiska mobila enheter. I mÄnga situationer kan detta vara en ovÀrderlig och lyxig alternativ. SÀrskilt testplattformar Àr anvÀndbara för IOS-automatisering, dÀr offentliga moln endast kan erbjuda Linux-/Windows-system. Men samtalet om IOS kommer att vara i kommande artiklar. Jag rekommenderar alltid att man bedömer situationen och utgÄr frÄn uppgifterna: i vissa fall Àr det billigare och mer effektivt att anvÀnda offentliga moln, medan det i andra fall Àr testplattformar som definitivt Àr vÀrda pengarna.

Illustration av det nuvarande tillstÄndet för infrastrukturen

DevOps-verktyg inte bara för DevOps. Processen att bygga infrastruktur för testautomatisering frÄn grunden

LÀnkar för studier

Liknande verktyg:

6. Orkestrering

Kort beskrivning av tekniken

Jag har goda nyheter – vi har nĂ€stan nĂ„tt slutet av artikeln! För nĂ€rvarande bestĂ„r vĂ„r automatiseringsinfrastruktur av web och Android-tester som vi kör parallellt via GitLab CI, med hjĂ€lp av verktyg som stöder Docker: Selenium grid och Selenoid. Dessutom anvĂ€nder vi virtuella maskiner skapade via GCP för att köra containrar med webblĂ€sare och emulatorer. För att minska kostnaderna kör vi dessa virtuella maskiner endast pĂ„ begĂ€ran och stĂ€nger av dem nĂ€r testerna inte utförs. Finns det nĂ„got mer som kan förbĂ€ttra vĂ„r infrastruktur? Svaret Ă€r ja! HĂ€r Ă€r Kubernetes (K8s)!

För att börja, lĂ„t oss se hur orden orkestrering, kluster och Kubernetes Ă€r relaterade. PĂ„ en hög nivĂ„ Ă€r orkestrering ett system som distribuerar och hanterar applikationer. För automatisering av tester Ă€r sĂ„dana containeriserade applikationer Selenium grid och Selenoid. Docker och K8s kompletterar varandra. Den första anvĂ€nds för att distribuera applikationer, den andra för orkestrering. Å sin sida Ă€r K8s ett kluster. Klusterets uppgift Ă€r att anvĂ€nda VMs som noder, vilket gör att olika funktionaliteter, program och tjĂ€nster kan installeras inom en server (kluster). Om nĂ„gon av noderna faller, sĂ„ tar andra noder över, vilket sĂ€kerstĂ€ller att vĂ„r applikation fungerar oavbrutet. Utöver detta har K8s viktig funktionalitet relaterad till skalning, vilket gör att vi automatiskt fĂ„r optimalt antal resurser baserat pĂ„ belastning och angivna begrĂ€nsningar.

Ärligt talat Ă€r manuell driftsĂ€ttning av Kubernetes frĂ„n grunden en ganska komplicerad uppgift. Jag kommer att lĂ€mna en lĂ€nk till den kĂ€nda praktiska guiden "Kubernetes The Hard Way", och om du Ă€r intresserad kan du öva pĂ„ det. Men lyckligtvis finns det alternativ och verktyg. Det enklaste av dem Ă€r att anvĂ€nda Google Kubernetes Engine (GKE) i GCP, vilket ger en fĂ€rdig kluster efter nĂ„gra klick. För att börja rekommenderar jag verkligen att anvĂ€nda denna metod, eftersom den lĂ„ter dig fokusera pĂ„ hur du kan anvĂ€nda K8s för dina uppgifter istĂ€llet för att undersöka hur de interna komponenterna bör integreras med varandra. 

VÀrde för automatiseringsinfrastruktur

LÄt oss titta pÄ nÄgra viktiga funktioner som K8s erbjuder:

  • applikationsdistribuering: anvĂ€ndning av multi-nodes kluster istĂ€llet för VMs;
  • dynamisk skalning: minskar kostnader för resurser som anvĂ€nds endast vid behov;
  • sjĂ€lvĂ„terstĂ€llning (Self-healing): automatisk Ă„terstĂ€llning av pods (vilket i sin tur Ă„terstĂ€ller containrar);
  • utrullning av uppdateringar och Ă„tergĂ„r till Ă€ndringar utan driftstopp: uppdatering av verktyg, webblĂ€sare och emulatorer avbryter inte nuvarande anvĂ€ndare

Men K8s Àr fortfarande inte en silverkula. För att förstÄ alla fördelar och begrÀnsningar i sammanhanget av de verktyg vi diskuterar (Selenium grid, Selenoid) ska vi kort diskutera strukturen av K8s. Kluster innehÄller tvÄ typer av noder: Master Nodes och Worker Nodes. Master Nodes ansvarar för hantering, distribuerande och schemalÀggningsbeslut. Worker nodes Àr dÀr applikationerna körs. Noder innehÄller ocksÄ en körmiljö för containrar. I vÄrt fall Àr det Docker, som ansvarar för operationer relaterade till containrar. Men det finns ocksÄ alternativa lösningar, till exempel containerd. Det Àr viktigt att förstÄ att skalning eller sjÀlvÄterstÀllning inte hÀnför sig direkt till containrar. Detta realiseras genom att lÀgga till/minska antalet pods, som i sin tur innehÄller containrar (vanligtvis en container per pod, men beroende pÄ uppgiften kan det vara fler). Den högre hierarkin representerar worker nodes, inom vilka pods finns, inuti vilka containrar körs.

Skalningsfunktionen Àr avgörande och kan tillÀmpas bÄde pÄ noder inom klustrets nodpool och pÄ pods inom noden. Det finns tvÄ typer av skalning som gÀller bÄde noder och pods. Den första typen - horisontell - innebÀr att antalet noder/pods ökas. Denna typ Àr mer föredragen. Den andra typen, motsvarande, Àr vertikal. Skalningen genomförs genom att öka storleken pÄ noder/pods snarare Àn deras antal.

Nu ska vi titta pÄ vÄra verktyg i samband med de ovan nÀmnda termerna.

Selenium grid

Som nÀmnts tidigare Àr Selenium grid ett mycket populÀrt verktyg, och det Àr ingen överraskning att det har containeriserats. DÀrför Àr det inte förvÄnande att Selenium grid kan distribueras i K8s. Ett exempel pÄ hur detta görs kan hittas i det officiella K8s-repositoriet. Som vanligt bifogar jag lÀnkar i slutet av avsnittet. Utöver detta visar en praktisk guide hur man gör det med Terraform. Det finns ocksÄ en instruktion för hur man skalar antalet pods som innehÄller containrar med webblÀsare. Men automatisk skalning i kontexten av K8s Àr fortfarande en uppgift som inte Àr helt uppenbar. NÀr jag började studera hittade jag ingen praktisk guide eller rekommendationer. Efter flera undersökningar och experiment med stöd frÄn vÄrt DevOps-team valde vi metoden att lyfta containrar med de önskade webblÀsarna inom en pod som ligger inom en arbetsnod. Denna metod gör det möjligt för oss att tillÀmpa en strategi för horisontell skalning av noder genom att öka deras antal. Jag hoppas att situationen förÀndras i framtiden, och att vi ser fler och fler beskrivningar av de bÀsta metoderna och fÀrdiga lösningarna, sÀrskilt efter lanseringen av Selenium grid 4 med en Àndrad intern arkitektur.

Selenoid:

För nÀrvarande Àr distribuerar Selenoid i K8s den största besvikelsen. De Àr inte kompatibla. Teoretiskt kan vi lyfta Selenoid-containern inom en pod, men nÀr Selenoid börjar köra containrar med webblÀsare kommer de fortfarande att vara inom samma pod. Detta gör skalning omöjlig och som ett resultat kommer driften av Selenoid inom klustret inte att skilja sig frÄn driften inom en virtuell maskin. Slutet pÄ historien.

Moon:

Med vetskap om denna flaskhals nÀr man arbetar med Selenoid har utvecklarna slÀppt ett kraftfullare verktyg som de kallat Moon. Detta verktyg var ursprungligen avsett för anvÀndning med Kubernetes och som ett resultat kan och bör man anvÀnda automatiseringsfunktionen. Dessutom skulle jag sÀga att just nu Àr detta den enda verktyget i vÀrlden av Selenium som har native K8s-klusterstöd direkt ur lÄdan (inte lÀngre, se nÀsta verktyg ). En nyckelfunktion hos Moon som möjliggör detta stöd Àr: 

Helt stateless. Selenoid lagrar i minnet information om för nÀrvarande aktiva webblÀsarsessioner. Om dess process av nÄgon anledning kraschar förloras alla aktiva sessioner. Moon dÀremot har inget internt tillstÄnd och kan replikeras över datacentren. WebblÀsarsessioner förblir aktiva Àven om en eller flera repliker gÄr ner.

SÄ, Moon Àr en fantastisk lösning, men med ett problem, det Àr inte gratis. Priset beror pÄ antalet sessioner. Gratis kan man endast köra 0-4 sessioner, vilket inte Àr sÀrskilt anvÀndbart. Men frÄn och med den femte sessionen mÄste man betala 5 $ för varje. Situationen kan variera mellan företag, men i vÄrt fall Àr anvÀndningen av Moon meningslös. Som jag beskrev ovan kan vi starta VMs med Selenium Grid pÄ begÀran eller öka antalet noder i klustret. För varje pipeline kör vi cirka 500 webblÀsare och stoppar alla resurser efter att testerna Àr utförda. Om vi skulle anvÀnda Moon skulle vi behöva betala ytterligare 500 x 5 = 2500 $ i mÄnaden, oavsett hur ofta vi kör tester. Och Äterigen, jag sÀger inte "anvÀnd inte Moon". För dina behov kan det vara en ovÀrderlig lösning, sÀrskilt om du har mÄnga projekt/team inom organisationen och behöver ett stort gemensamt kluster för alla. Som alltid lÀmnar jag en lÀnk i slutet och rekommenderar att göra alla nödvÀndiga berÀkningar i förhÄllande till din uppgift.

Callisto: (Observera! Detta finns inte i den ursprungliga artikeln och finns endast i den ryska översÀttningen.)

Som jag sa tidigare Àr Selenium ett mycket populÀrt verktyg och IT-omrÄdet utvecklas snabbt. Medan jag arbetade med översÀttningen dök ett nytt lovande verktyg upp, Callisto (hej Cypress och andra Selenium-konkurrenter). Det fungerar nativt med K8s och gör det möjligt att köra Selenoid-containrar i pods, fördelat pÄ Nodes. Allt fungerar direkt ur lÄdan, inklusive automatisk skalning. Fantastiskt, men det mÄste testas. Jag har redan lyckats implementera detta verktyg och köra nÄgra experiment. Men det Àr för tidigt att dra slutsatser, efter att jag fÄtt resultaten pÄ lÄng sikt kanske jag gör en översikt i kommande artiklar. Tills vidare lÀmnar jag bara lÀnkar för sjÀlvstÀndiga studier.  

Illustration av det nuvarande tillstÄndet för infrastrukturen

DevOps-verktyg inte bara för DevOps. Processen att bygga infrastruktur för testautomatisering frÄn grunden

LÀnkar för studier

Liknande verktyg

7. Infrastruktur som kod (IaC)

Kort beskrivning av tekniken

Och hÀr har vi kommit till den sista delen. Vanligtvis faller denna teknik och relaterade uppgifter utanför ansvarsomrÄdet för automatiseringsingenjörer. Och det finns anledning till det. För det första ligger infrastrukturella frÄgor under DevOps-avdelningens kontroll i mÄnga organisationer, och utvecklingsteamet bryr sig inte sÄ mycket om vad som driver pipeline eller hur man ska underhÄlla allt som hör till den. För det andra, lÄt oss vara Àrliga, praktiken "Infrastruktur som kod (IaC)" tillÀmpas fortfarande inte i mÄnga företag. Men det har definitivt blivit en populÀr trend och det Àr viktigt att försöka vara involverad i de relaterade processerna, metoderna och verktygen. Eller Ätminstone hÄlla sig informerad om vad som hÀnder.

LÄt oss börja med motivationen för att anvÀnda detta tillvÀgagÄngssÀtt. Vi har redan diskuterat att för att köra tester i GitlabCI behöver vi minst resurser för att köra Gitlab Runner. Och för att starta containrar med webblÀsare/emulatorer mÄste vi reservera en VM eller en kluster. Förutom resurserna för testning behöver vi Àven betydande kapacitet för att upprÀtthÄlla utvecklings-, staging- och produktionsmiljöer, vilket Àven inkluderar databaser, automatiska scheman, nÀtverkskonfigurationer, lastbalanserare, anvÀndarrÀttigheter och sÄ vidare. Det centrala problemet Àr de nödvÀndiga insatserna för att stödja allt detta. Det finns flera sÀtt att göra Àndringar och implementera uppdateringar. Till exempel, i kontexten av GCP kan vi anvÀnda UI-konsolen i webblÀsaren och utföra alla ÄtgÀrder genom att klicka pÄ knappar. Ett alternativ kan vara att anvÀnda API-anrop för att interagera med molnentiteter eller att anvÀnda kommandoradsverktyget gcloud för att utföra nödvÀndiga manipulationer. Men med en verkligt stor mÀngd olika entiteter och infrastrukturkomponenter blir det svÄrt eller till och med omöjligt att utföra alla operationer manuellt. Dessutom Àr alla dessa manuella ÄtgÀrder okontrollerade. Vi kan inte skicka dem pÄ granskning innan de genomförs, anvÀnda versionskontrollsystem och snabbt ÄterstÀlla Àndringar som ledde till en incident. För att lösa sÄdana problem har ingenjörer skapat och fortsÀtter att skapa automatiska bash/shell-skript, vilket inte Àr mycket bÀttre Àn de tidigare metoderna, eftersom de inte Àr lÀtta att snabbt lÀsa, förstÄ, underhÄlla och modifiera i procedurstil.

I den hÀr artikeln och den praktiska guiden anvÀnder jag 2 verktyg som relaterar till praktiken IaC. Dessa Àr Terraform och Ansible. Vissa anser att det inte Àr meningsfullt att anvÀnda dem samtidigt, eftersom deras funktionalitet Àr liknande och de Àr utbytbara. Men saken Àr den att de ursprungligen stÀlls inför helt olika uppgifter. Faktumet att dessa verktyg ska komplettera varandra har bekrÀftats vid en gemensam presentation av utvecklare frÄn företagen HashiCorp och RedHat. Den konceptuella skillnaden Àr att Terraform Àr ett provisioning-verktyg för att hantera sjÀlva servrarna. Medan Ansible Àr ett verktyg för hantering av konfigurationer, vars uppgift Àr att installera, konfigurera och hantera mjukvara pÄ dessa servrar.

En annan nyckelskillnad mellan dessa verktyg Àr kodskrivningsstilen. Till skillnad frÄn bash och Ansible, anvÀnder Terraform en deklarativ stil, baserad pÄ beskrivningen av det önskade slutgiltiga tillstÄndet som mÄste uppnÄs som resultat av utförandet. Till exempel, om vi kÀnner för att skapa 10 VMs och tillÀmpa förÀndringar genom Terraform, sÄ fÄr vi 10 VMs. Om vi kör skriptet igen, hÀnder ingenting, eftersom vi redan har 10 VMs, och Terraform vet detta, eftersom det lagrar det aktuella tillstÄndet av infrastrukturen i en state-fil. Men Ansible anvÀnder ett proceduralt tillvÀgagÄngssÀtt och, om vi ber det att skapa 10 VMs, sÄ fÄr vi 10 VMs vid första körningen, pÄ samma sÀtt som med Terraform. Men efter att ha kört det igen, kommer vi att ha 20 VMs. Detta utgör den viktiga skillnaden. I den procedurala stilen lagrar vi inte det aktuella tillstÄndet utan beskriver helt enkelt sekvensen av steg som mÄste utföras. Naturligtvis kan vi hantera olika situationer, lÀgga till nÄgra kontroller för att kontrollera resurser och aktuellt tillstÄnd, men det Àr meningslöst att slösa vÄr tid och energi pÄ att kontrollera denna logik. Dessutom ökar det risken för att göra misstag. 

Sammanfattningsvis kan vi dra slutsatsen att det mer lĂ€mpliga verktyget för provisioning av servrar Ă€r Terraform och deklarativ notation. Å andra sidan Ă€r det bĂ€ttre att delegera konfigureringens hantering till Ansible. NĂ€r vi har förstĂ„tt detta, lĂ„t oss ta en titt pĂ„ exempel pĂ„ anvĂ€ndning i kontexten av automatisering.

VÀrde för automatiseringsinfrastruktur

HÀr Àr det viktigt att förstÄ att testautomatiseringsinfrastrukturen bör ses som en del av hela företagets infrastruktur. Det betyder att alla IaC-praktiker bör tillÀmpas globalt pÄ resurserna i hela organisationen. Vem som Àr ansvarig för detta beror pÄ era processer. DevOps-teamet har mer erfarenhet inom dessa frÄgor, de ser hela bilden av vad som pÄgÄr. Men QA-ingenjörer Àr starkare involverade i processen för att bygga automatisering och strukturen för pipeline, vilket gör att de bÀttre kan se alla nödvÀndiga förÀndringar och möjligheter till förbÀttring. Den bÀsta lösningen Àr att arbeta tillsammans, dela kunskap och idéer för att nÄ det förvÀntade resultatet. 

Jag ger nÄgra exempel pÄ anvÀndning av Terraform och Ansible i sammanhanget av testautomatisering och verktyg som vi diskuterat tidigare:

1. Beskriv de nödvÀndiga egenskaperna och parametrarna för VMs och kluster via Terraform.

2. Installera nödvÀndiga testverktyg med hjÀlp av Ansible: docker, Selenoid, Selenium Grid och ladda ner de nödvÀndiga versionerna av webblÀsare/emulatorer.

3. Beskriv via Terraform egenskaperna hos VM:n dÀr GitLab Runner kommer att köras.

4. Installera GitLab Runner och nödvÀndiga tillhörande verktyg med hjÀlp av Ansible, ange instÀllningar och konfigurationer.

Illustration av det nuvarande tillstÄndet för infrastrukturen

DevOps-verktyg inte bara för DevOps. Processen att bygga infrastruktur för testautomatisering frÄn grunden

Resurser för studier:

Liknande verktyg

LĂ„t oss sammanfatta!

Steg
Teknik
Verktyg
VÀrde för automatiseringsinfrastruktur

1
Lokal körning
Node.js, Selenium, Appium

  • De mest populĂ€ra verktygen för web och mobil
  • Stöd för mĂ„nga sprĂ„k och plattformar (inklusive Node.js)

2
Versionshanteringssystem 
Git

  • Liknande fördelar med utvecklingskoden

3
Containerisering
Docker, Selenium grid, Selenoid (Web, Android)

  • Parallell körning av tester
  • Isolerade miljöer
  • Enkel, flexibel uppdatering av versioner
  • Dynamisk stopp av oanvĂ€nda resurser
  • LĂ€tt att konfigurera

4
CI / CD
Gitlab CI

  • Tester Ă€r en del av pipeline
  • Snabb feedback
  • Synlighet för hela företaget/teamet

5
Molnplattformar
Google Cloud Platform

  • Resurser pĂ„ begĂ€ran (betala bara nĂ€r de behövs)
  • LĂ€tt att hantera och uppdatera
  • Synlighet och kontroll över alla resurser

6
Orkestrering
Kubernetes
I kontexten av containrar med webblÀsare/emulatorer inuti pods:

  • Skalning / automatisk skalning
  • SjĂ€lvĂ„terstĂ€llning
  • Uppdateringar och Ă„terstĂ€llningar utan avbrott

7
Infrastruktur som kod (IaC)
Terraform, Ansible

  • Liknande fördelar med utvecklingsinfrastrukturen
  • Alla fördelar med versionshantering av koden
  • LĂ€tt att göra förĂ€ndringar och underhĂ„lla
  • Helt automatiserat

Mind map-diagrammer: evolutionen av infrastrukturen

steg1: Lokal
DevOps-verktyg inte bara för DevOps. Processen att bygga infrastruktur för testautomatisering frÄn grunden

steg2: VCS
DevOps-verktyg inte bara för DevOps. Processen att bygga infrastruktur för testautomatisering frÄn grunden

steg3: Containerisering 
DevOps-verktyg inte bara för DevOps. Processen att bygga infrastruktur för testautomatisering frÄn grunden

steg4: CI/CD 
DevOps-verktyg inte bara för DevOps. Processen att bygga infrastruktur för testautomatisering frÄn grunden

steg5: Molnplattformar
DevOps-verktyg inte bara för DevOps. Processen att bygga infrastruktur för testautomatisering frÄn grunden

steg6: Orkestrering
DevOps-verktyg inte bara för DevOps. Processen att bygga infrastruktur för testautomatisering frÄn grunden

steg7: IaC
DevOps-verktyg inte bara för DevOps. Processen att bygga infrastruktur för testautomatisering frÄn grunden

Vad hÀnder hÀrnÀst?

SÄ, det hÀr Àr slutet pÄ artikeln. Men som avslutning skulle jag vilja faststÀlla nÄgra överenskommelser med er.

FrÄn er sida
Som jag nÀmnde tidigare, skulle jag vilja att artikeln bÀr praktiskt vÀrde och hjÀlper er att applicera de kunskaper ni fÄtt i verkligt arbete. Jag lÀgger till lÀnken till den praktiska guiden Ànnu en gÄng till den praktiska guiden.

Men Àven efter detta, tveka inte att öva, studera relevanta lÀnkar och böcker, ta reda pÄ hur det fungerar i ert företag, identifiera omrÄden som kan förbÀttras och delta i detta. Lycka till!

FrÄn min sida

Av rubriken framgÄr det att detta bara var den första delen. Trots att den blev ganska lÄng, kvarstÄr fortfarande viktiga Àmnen. I den andra delen planerar jag att diskutera automatiseringsinfrastruktur i sammanhanget av iOS. PÄ grund av Apples begrÀnsningar kring körning av iOS-simulatorer endast pÄ macOS-system, Àr vÄrt urval av lösningar begrÀnsat. Till exempel, vi har inte möjlighet att anvÀnda Docker för att köra simulatorn eller offentliga moln för att köra virtuella maskiner. Men det betyder inte att det inte finns andra alternativ. Jag kommer att försöka hÄlla er uppdaterade om de senaste lösningarna och moderna verktygen!

Jag nÀmnde ocksÄ inte de ganska stora Àmnena relaterade till övervakning. I del 3 avser jag att diskutera de mest populÀra verktygen för övervakning av infrastruktur, samt vilka data och metrik man bör ta hÀnsyn till.

Och till sist. I framtiden planerar jag att slÀppa en videokurs om att bygga testinfrastruktur och populÀra verktyg. För nÀrvarande finns det ganska mÄnga kurser och förelÀsningar om DevOps pÄ internet, men allt material presenteras i samband med utveckling, men inte automatisering av tester. I den hÀr frÄgan behöver jag verkligen feedback, om en sÄdan kurs skulle vara intressant och vÀrdefull för testare och automatiserare. Tack pÄ förhand!

KĂ€lla: habr.com

Köp pĂ„litlig webbhotell med DDoS-skydd, VPS VDS-servrar đŸ”„ Köp pĂ„litlig webbhotell med DDoS-skydd, VPS VDS-servrar | ProHoster