Deel 1: Web/Android
Noot: dit artikel is een vertaling in het Russisch van het originele artikel Alle illustraties, links, citaten en termen worden echter in de oorspronkelijke taal bewaard om vervorming van de betekenis bij vertaling in het Russisch te voorkomen. Ik wens je veel studieplezier!
Momenteel is de DevOps-specialiteit een van de meest gevraagde in de IT-industrie. Als u populaire zoeksites voor vacatures opent en op salaris filtert, ziet u dat DevOps-gerelateerde vacatures bovenaan de lijst staan. Het is echter belangrijk om te begrijpen dat dit vooral betrekking heeft op een 'Senior'-positie, wat impliceert dat de kandidaat over een hoog niveau van vaardigheden, kennis van technologie en hulpmiddelen beschikt. Dit gaat ook gepaard met een hoge mate van verantwoordelijkheid die gepaard gaat met de ononderbroken werking van de productie. We begonnen echter te vergeten wat DevOps is. Aanvankelijk was het geen specifieke persoon of afdeling. Als we zoeken naar definities van deze term, zullen we veel mooie en correcte zelfstandige naamwoorden vinden, zoals methodologie, praktijken, culturele filosofie, een groep concepten, enzovoort.
Mijn specialisatie is testautomatiseringsingenieur (QA automatiseringsingenieur), maar ik ben van mening dat dit niet alleen geassocieerd moet worden met het schrijven van autotests of het ontwikkelen van testframework-architectuur. Anno 2020 is kennis van de automatiseringsinfrastructuur ook essentieel. Hierdoor kunt u zelf het automatiseringsproces inrichten, van het uitvoeren van tests tot het aanleveren van resultaten aan alle belanghebbenden conform uw doelstellingen. Als gevolg hiervan zijn DevOps-vaardigheden een must om de klus te klaren. En dit is allemaal goed, maar helaas is er een probleem (spoiler: dit artikel probeert dit probleem te vereenvoudigen). Het punt is dat DevOps moeilijk is. En dit is duidelijk, omdat bedrijven niet veel zullen betalen voor iets dat gemakkelijk te doen is... In de DevOps-wereld zijn er een groot aantal tools, termen en praktijken die onder de knie moeten worden. Dit is vooral moeilijk aan het begin van een carrière en hangt af van de opgebouwde technische ervaring.
Bron:
Hier zullen we waarschijnlijk eindigen met het inleidende gedeelte en ons concentreren op het doel van dit artikel.
Waar gaat dit artikel over?
In dit artikel ga ik mijn ervaring delen met het bouwen van een testautomatiseringsinfrastructuur. Er zijn veel informatiebronnen op internet over verschillende tools en hoe je deze kunt gebruiken, maar ik zou ze graag puur in de context van automatisering willen bekijken. Ik geloof dat veel automatiseringsingenieurs bekend zijn met de situatie waarin niemand behalve jij de ontwikkelde tests uitvoert of zich zorgen maakt over het onderhoud ervan. Als gevolg hiervan raken tests verouderd en moet u tijd besteden aan het updaten ervan. Nogmaals, aan het begin van een carrière kan dit een behoorlijk moeilijke taak zijn: verstandig beslissen welke tools een bepaald probleem moeten helpen elimineren, hoe je ze moet selecteren, configureren en onderhouden. Sommige testers wenden zich tot DevOps (mensen) voor hulp en laten we eerlijk zijn: deze aanpak werkt. In veel gevallen kan dit de enige optie zijn, omdat we niet alle afhankelijkheden inzichtelijk hebben. Maar zoals we weten, hebben DevOps het erg druk, omdat ze moeten nadenken over de infrastructuur, implementatie, monitoring, microservices en andere soortgelijke taken van het hele bedrijf, afhankelijk van de organisatie/het team. Zoals meestal het geval is, heeft automatisering geen prioriteit. In zo'n geval moeten we van begin tot eind proberen al het mogelijke van onze kant te doen. Dit zal de afhankelijkheden verminderen, de workflow versnellen, onze vaardigheden verbeteren en ons in staat stellen het grotere plaatje te zien van wat er gebeurt.
Het artikel presenteert de meest populaire en populaire tools en laat zien hoe u deze kunt gebruiken om stap voor stap een automatiseringsinfrastructuur op te bouwen. Elke groep wordt vertegenwoordigd door instrumenten die door persoonlijke ervaring zijn getest. Maar dat betekent niet dat je hetzelfde moet gebruiken. De tools zelf zijn niet belangrijk, ze verschijnen en raken verouderd. Onze technische taak is om de basisprincipes te begrijpen: waarom we deze groep gereedschappen nodig hebben en welke werkproblemen we met hun hulp kunnen oplossen. Daarom laat ik aan het einde van elke sectie links achter naar soortgelijke tools die mogelijk in uw organisatie worden gebruikt.
Wat staat er niet in dit artikel
Ik herhaal nogmaals dat het artikel niet over specifieke tools gaat, dus er zullen geen code-invoegingen zijn uit de documentatie en beschrijvingen van specifieke commando's. Maar aan het einde van elke sectie laat ik links achter voor gedetailleerde studie.
Dit wordt gedaan omdat:
- dit materiaal is zeer gemakkelijk te vinden in verschillende bronnen (documentatie, boeken, videocursussen);
- als we dieper gaan, zullen we 10, 20, 30 delen van dit artikel moeten schrijven (terwijl de plannen 2-3 zijn);
- Ik wil je tijd niet verspillen, omdat je misschien andere tools wilt gebruiken om dezelfde doelen te bereiken.
Praktijk
Ik zou heel graag willen dat dit materiaal nuttig is voor elke lezer, en niet alleen maar wordt gelezen en vergeten. Bij elke studie is oefenen een zeer belangrijk onderdeel. Hiervoor heb ik voorbereidingen getroffen. Er ligt ook huiswerk voor u klaar om ervoor te zorgen dat u niet gedachteloos de regels kopieert van de opdrachten die u uitvoert.
plan
Stap voor
Technologie
Tools
1
Lokaal draaien (web-/Android-demotests voorbereiden en lokaal uitvoeren)
Node.js, Selenium, Appium
2
Versiebeheersystemen
Git
3
Containerisatie
Docker, Selenium-raster, Selenoid (web, Android)
4
CI/CD
Gitlab-CI
5
Cloud platforms
Google Cloud Platform
6
orkestratie
Kubernetes
7
Infrastructuur als code (IaC)
Terraform, Ansible
Structuur van elke sectie
Om het verhaal duidelijk te houden, wordt elke sectie beschreven volgens het volgende overzicht:
- korte beschrijving van de technologie,
- waarde voor de automatiseringsinfrastructuur,
- illustratie van de huidige staat van de infrastructuur,
- links naar studie,
- soortgelijke hulpmiddelen.
1. Voer lokaal tests uit
Korte beschrijving van de technologie
Dit is slechts een voorbereidende stap om de demotests lokaal uit te voeren en te verifiëren of ze slagen. In het praktijkgedeelte wordt gebruik gemaakt van Node.js, maar ook de programmeertaal en het platform zijn niet van belang en je kunt gebruik maken van degene die in jouw bedrijf gebruikt worden.
Als automatiseringstools raad ik echter aan om respectievelijk Selenium WebDriver voor webplatforms en Appium voor het Android-platform te gebruiken, omdat we in de volgende stappen Docker-afbeeldingen zullen gebruiken die zijn afgestemd om specifiek met deze tools te werken. Bovendien zijn deze tools, gezien de functie-eisen, het meest gevraagd op de markt.
Zoals je misschien hebt gemerkt, houden we alleen rekening met web- en Android-tests. Helaas is iOS een heel ander verhaal (bedankt Apple). Ik ben van plan om IOS-gerelateerde oplossingen en praktijken in de komende delen te presenteren.
Waarde voor automatiseringsinfrastructuur
Vanuit een infrastructuurperspectief levert lokaal draaien geen enkele waarde op. Je controleert alleen of de tests op de lokale machine draaien in lokale browsers en simulatoren. Maar in ieder geval is dit een noodzakelijk uitgangspunt.
Illustratie van de huidige staat van de infrastructuur
Links om te verkennen
Soortgelijke hulpmiddelen
- elke gewenste programmeertaal in combinatie met Selenium/Appium-tests;
- eventuele tests;
- elke testloper.
2. Versiebeheersystemen (Git)
Korte beschrijving van de technologie
Het zal voor niemand een grote openbaring zijn als ik zeg dat versiebeheer een uiterst belangrijk onderdeel is van de ontwikkeling, zowel in teamverband als individueel. Op basis van verschillende bronnen is het veilig om te zeggen dat Git de meest populaire vertegenwoordiger is. Een versiebeheersysteem biedt veel voordelen, zoals het delen van code, het opslaan van versies, het herstellen naar eerdere vestigingen, het bewaken van de projectgeschiedenis en back-ups. We zullen niet elk punt in detail bespreken, omdat ik er zeker van ben dat u er zeer bekend mee bent en het in uw dagelijkse werk gebruikt. Maar als dat plotseling niet het geval is, raad ik aan dit artikel even te lezen en deze leemte zo snel mogelijk op te vullen.
Waarde voor automatiseringsinfrastructuur
En hier kun je een redelijke vraag stellen: “Waarom vertelt hij ons over Git? Iedereen weet dit en gebruikt het zowel voor ontwikkelcode als voor autotestcode.” Je hebt volkomen gelijk, maar in dit artikel hebben we het over infrastructuur en deze paragraaf fungeert als voorproefje voor paragraaf 7: “Infrastructuur als Code (IaC)”. Voor ons betekent dit dat de gehele infrastructuur, inclusief het testen, wordt beschreven in de vorm van code, zodat we er ook versiesystemen op kunnen toepassen en vergelijkbare voordelen kunnen behalen als bij ontwikkel- en automatiseringscode.
We zullen IaC in meer detail bekijken in stap 7, maar zelfs nu kun je Git lokaal gaan gebruiken door een lokale repository te maken. Het grote geheel zal worden uitgebreid als we een externe repository aan de infrastructuur toevoegen.
Illustratie van de huidige staat van de infrastructuur
Links om te verkennen
Soortgelijke hulpmiddelen
3. Containerisatie (Docker)
Korte beschrijving van de technologie
Om aan te tonen hoe containerisatie de spelregels heeft veranderd, gaan we een paar decennia terug in de tijd. Destijds kochten en gebruikten mensen servermachines om applicaties uit te voeren. Maar in de meeste gevallen waren de benodigde opstartmiddelen vooraf niet bekend. Als gevolg hiervan gaven bedrijven geld uit aan de aanschaf van dure, krachtige servers, maar een deel van deze capaciteit werd niet volledig benut.
De volgende fase van de evolutie waren virtuele machines (VM's), die het probleem van het verspillen van geld aan ongebruikte bronnen oplosten. Deze technologie maakte het mogelijk om applicaties onafhankelijk van elkaar op dezelfde server te laten draaien, waardoor volledig geïsoleerde ruimte werd toegewezen. Maar helaas heeft elke technologie zijn nadelen. Voor het runnen van een VM is een volledig besturingssysteem vereist, dat CPU, RAM, opslag verbruikt en, afhankelijk van het besturingssysteem, moet rekening worden gehouden met licentiekosten. Deze factoren beïnvloeden de laadsnelheid en maken draagbaarheid moeilijk.
En nu komen we bij containerisatie. Opnieuw lost deze technologie het voorgaande probleem op, omdat containers geen volledig besturingssysteem gebruiken, waardoor een grote hoeveelheid bronnen vrijkomt en een snelle en flexibele oplossing voor portabiliteit wordt geboden.
Containerisatietechnologie is uiteraard niets nieuws en werd eind jaren zeventig voor het eerst geïntroduceerd. Er werd in die tijd veel onderzoek, ontwikkelingen en pogingen ondernomen. Maar het was Docker die deze technologie aanpaste en gemakkelijk toegankelijk maakte voor de massa. Als we het tegenwoordig over containers hebben, bedoelen we in de meeste gevallen Docker. Als we het over Docker-containers hebben, bedoelen we Linux-containers. We kunnen Windows- en macOS-systemen gebruiken om containers uit te voeren, maar het is belangrijk om te begrijpen dat er in dit geval een extra laag verschijnt. Docker op Mac voert bijvoorbeeld geruisloos containers uit in een lichtgewicht Linux-VM. We komen op dit onderwerp terug als we het hebben over het draaien van Android-emulators in containers, dus hier is er een zeer belangrijke nuance die in meer detail moet worden besproken.
Waarde voor automatiseringsinfrastructuur
We kwamen erachter dat containerisatie en Docker cool zijn. Laten we dit eens bekijken in de context van automatisering, omdat elk hulpmiddel of elke technologie een probleem moet oplossen. Laten we de voor de hand liggende problemen van testautomatisering in de context van UI-tests schetsen:
- een groot aantal afhankelijkheden bij het installeren van Selenium en vooral Appium;
- compatibiliteitsproblemen tussen versies van browsers, simulators en stuurprogramma's;
- gebrek aan geïsoleerde ruimte voor browsers/simulators, wat vooral van cruciaal belang is voor parallelle werking;
- moeilijk te beheren en te onderhouden als je 10, 50, 100 of zelfs 1000 browsers tegelijkertijd moet gebruiken.
Maar aangezien Selenium de populairste automatiseringstool is en Docker de populairste containerisatietool, mag het geen verrassing zijn dat iemand heeft geprobeerd ze te combineren om een krachtig hulpmiddel te creëren om de bovengenoemde problemen op te lossen. Laten we dergelijke oplossingen in meer detail bekijken.
Seleniumraster in docker
Deze tool is de meest populaire in de Selenium-wereld voor het uitvoeren van meerdere browsers op meerdere machines en het beheren ervan vanuit een centrale hub. Om te beginnen moet je minimaal 2 onderdelen registreren: Hub en Node(s). Hub is een centraal knooppunt dat alle aanvragen van tests ontvangt en deze distribueert naar de juiste knooppunten. Voor elke Node kunnen we een specifieke configuratie configureren, bijvoorbeeld door de gewenste browser en de versie ervan op te geven. We moeten echter nog steeds zelf voor compatibele browserstuurprogramma's zorgen en deze op de gewenste knooppunten installeren. Om deze reden wordt Selenium grid niet in zijn pure vorm gebruikt, behalve wanneer we moeten werken met browsers die niet op Linux OS kunnen worden geïnstalleerd. Voor alle andere gevallen zou een aanzienlijk flexibele en correcte oplossing zijn om Docker-images te gebruiken om Selenium grid Hub en Nodes uit te voeren. Deze aanpak vereenvoudigt het knooppuntbeheer aanzienlijk, omdat we de afbeelding die we nodig hebben kunnen selecteren met compatibele versies van browsers en stuurprogramma's die al zijn geïnstalleerd.
Ondanks negatieve recensies over de stabiliteit, vooral bij het parallel uitvoeren van een groot aantal knooppunten, is het Selenium-raster nog steeds het meest populaire hulpmiddel voor het parallel uitvoeren van Selenium-tests. Het is belangrijk op te merken dat er in open-source voortdurend verschillende verbeteringen en aanpassingen aan deze tool verschijnen, die verschillende knelpunten bestrijden.
Selenoid voor web
Deze tool is een doorbraak in de wereld van Selenium omdat het direct uit de doos werkt en het leven van veel automatiseringsingenieurs veel gemakkelijker heeft gemaakt. Allereerst is dit niet weer een wijziging van het Selenium-raster. In plaats daarvan creëerden de ontwikkelaars een volledig nieuwe versie van Selenium Hub in Golang, die, gecombineerd met lichtgewicht Docker-images voor verschillende browsers, een impuls gaf aan de ontwikkeling van testautomatisering. Bovendien moeten we in het geval van Selenium Grid vooraf alle benodigde browsers en hun versies bepalen, wat geen probleem is als je met slechts één browser werkt. Maar als het gaat om meerdere ondersteunde browsers, is Selenoid de nummer één oplossing dankzij de 'browser on demand'-functie. Het enige dat van ons wordt verlangd, is om vooraf de benodigde afbeeldingen met browsers te downloaden en het configuratiebestand bij te werken waarmee Selenoid communiceert. Nadat Selenoid een verzoek van de tests ontvangt, start het automatisch de gewenste container met de gewenste browser. Wanneer de test is voltooid, zal Selenoid de container buiten gebruik stellen, waardoor er middelen vrijkomen voor toekomstige verzoeken. Deze aanpak elimineert volledig het bekende probleem van 'knoopdegradatie' dat we vaak tegenkomen in het Selenium-raster.
Maar helaas is Selenoid nog steeds geen wondermiddel. We hebben de functie 'browser on demand', maar de functie 'resources on demand' is nog steeds niet beschikbaar. Om Selenoid te gebruiken, moeten we het op fysieke hardware of op een VM implementeren, wat betekent dat we van tevoren moeten weten hoeveel bronnen er moeten worden toegewezen. Ik denk dat dit geen probleem is voor kleine projecten die 10, 20 of zelfs 30 browsers parallel draaien. Maar wat als we er 100, 500, 1000 en meer nodig hebben? Het heeft geen zin om voortdurend zoveel hulpbronnen te onderhouden en te betalen. In secties 5 en 6 van dit artikel bespreken we oplossingen waarmee u kunt opschalen, waardoor de bedrijfskosten aanzienlijk worden verlaagd.
Selenoid voor Android
Na het succes van Selenoid als webautomatiseringstool wilden mensen iets soortgelijks voor Android. En het gebeurde: Selenoid werd uitgebracht met Android-ondersteuning. Vanuit het oogpunt van de gebruiker op hoog niveau is het werkingsprincipe vergelijkbaar met webautomatisering. Het enige verschil is dat Selenoid in plaats van browsercontainers Android-emulatorcontainers uitvoert. Naar mijn mening is dit momenteel de krachtigste gratis tool om Android-tests parallel uit te voeren.
Ik zou echt niet willen praten over de negatieve aspecten van deze tool, omdat ik het echt heel leuk vind. Maar toch zijn er dezelfde nadelen die van toepassing zijn op webautomatisering en die verband houden met schaalvergroting. Daarnaast moeten we het hebben over nog een beperking die als een verrassing kan komen als we de tool voor de eerste keer opzetten. Om Android-images uit te voeren, hebben we een fysieke machine of VM nodig met geneste virtualisatie-ondersteuning. In de handleiding laat ik zien hoe je dit kunt inschakelen op een Linux VM. Bent u echter een macOS-gebruiker en wilt u Selenoid lokaal inzetten, dan is het niet mogelijk om Android-tests uit te voeren. Maar je kunt altijd een Linux VM lokaal draaien met 'geneste virtualisatie' geconfigureerd en Selenoid erin implementeren.
Illustratie van de huidige staat van de infrastructuur
In de context van dit artikel zullen we 2 tools toevoegen om de infrastructuur te illustreren. Dit zijn Selenium grid voor webtests en Selenoid voor Android-tests. In de GitHub-tutorial laat ik je ook zien hoe je Selenoid gebruikt om webtests uit te voeren.
Links om te verkennen
Soortgelijke hulpmiddelen
- Er zijn andere containerisatietools, maar Docker is het populairst. Als je iets anders wilt proberen, houd er dan rekening mee dat de tools die we hebben besproken voor het parallel uitvoeren van Selenium-tests niet standaard werken.
- Zoals al gezegd, zijn er veel aanpassingen aan het Selenium-raster, bijvoorbeeld.
4.CI/CD
Korte beschrijving van de technologie
De praktijk van continue integratie is behoorlijk populair in de ontwikkeling en staat op één lijn met versiebeheersystemen. Desondanks heb ik het gevoel dat er sprake is van verwarring in de terminologie. In deze paragraaf wil ik vanuit mijn standpunt drie wijzigingen van deze technologie beschrijven. Op internet vind je veel artikelen met verschillende interpretaties, en het is volkomen normaal als jouw mening verschilt. Het allerbelangrijkste is dat je met je collega’s op één lijn zit.
Er zijn dus 3 termen: CI - Continuous Integration, CD - Continuous Delivery en opnieuw CD - Continuous Deployment. (Hieronder zal ik deze termen in het Engels gebruiken). Elke wijziging voegt verschillende extra stappen toe aan uw ontwikkelingspijplijn. Maar het woord doorlopend (continu) is het belangrijkste. In deze context bedoelen we iets dat van begin tot eind gebeurt, zonder onderbreking of handmatige tussenkomst. Laten we in deze context eens naar CI & CD en CD kijken.
- Continue integratie dit is de eerste stap van de evolutie. Nadat we de nieuwe code op de server hebben ingediend, verwachten we snel feedback dat onze wijzigingen in orde zijn. Normaal gesproken omvat CI het uitvoeren van statische code-analysetools en unit-/interne API-tests. Hierdoor kunnen we binnen enkele seconden/minuten informatie over onze code verkrijgen.
- Continue levering is een meer geavanceerde stap waarbij we integratie-/UI-tests uitvoeren. In dit stadium boeken we echter niet zo snel resultaat als bij CI. Ten eerste duurt het langer om dit soort tests te voltooien. Ten tweede moeten we vóór de lancering onze wijzigingen in de test-/stagingomgeving implementeren. Bovendien, als we het hebben over mobiele ontwikkeling, lijkt een extra stap het creëren van een build van onze applicatie.
- Voortdurende inzet gaat ervan uit dat we onze wijzigingen automatisch vrijgeven in productie als alle acceptatietests in de voorgaande fasen zijn doorstaan. Daarnaast kunt u na de releasefase verschillende fasen configureren, zoals het uitvoeren van rooktests op de productie en het verzamelen van interessante statistieken. Continuous Deployment is alleen mogelijk met een goede dekking door geautomatiseerde tests. Als er handmatige interventies nodig zijn, inclusief testen, dan is dit niet langer het geval Doorlopend (continu). Dan kunnen we zeggen dat onze pijplijn alleen voldoet aan de praktijk van Continuous Delivery.
Waarde voor automatiseringsinfrastructuur
In dit gedeelte moet ik verduidelijken dat wanneer we het hebben over end-to-end UI-tests, dit betekent dat we onze wijzigingen en bijbehorende services moeten inzetten om omgevingen te testen. Continue integratie - het proces is niet van toepassing op deze taak en we moeten ervoor zorgen dat we ten minste Continuous Deliver-praktijken implementeren. Continuous Deployment is ook zinvol in de context van UI-tests als we deze in productie gaan uitvoeren.
En voordat we naar de illustratie van de architectuurverandering kijken, wil ik een paar woorden zeggen over GitLab CI. In tegenstelling tot andere CI/CD-tools biedt GitLab een externe repository en vele andere extra functies. GitLab is dus meer dan CI. Het omvat broncodebeheer, Agile-beheer, CI/CD-pijplijnen, logboektools en kant-en-klare verzameling van statistieken. De GitLab-architectuur bestaat uit Gitlab CI/CD en GitLab Runner. Hier is een korte beschrijving van de officiële website:
Gitlab CI/CD is een webapplicatie met een API die de status ervan opslaat in een database, projecten/builds beheert en een gebruikersinterface biedt. GitLab Runner is een applicatie die builds verwerkt. Het kan afzonderlijk worden ingezet en werkt met GitLab CI/CD via een API. Voor het uitvoeren van tests heb je zowel een Gitlab-instantie als Runner nodig.
Illustratie van de huidige staat van de infrastructuur
Links om te verkennen
Soortgelijke hulpmiddelen
- En vele anderen
5. Cloudplatforms
Korte beschrijving van de technologie
In deze sectie zullen we het hebben over een populaire trend genaamd 'public clouds'. Ondanks de enorme voordelen die de hierboven beschreven virtualisatie- en containerisatietechnologieën bieden, hebben we nog steeds computerbronnen nodig. Bedrijven kopen dure servers of huren datacenters, maar in dit geval is het noodzakelijk om berekeningen te maken (soms onrealistisch) van hoeveel middelen we nodig zullen hebben, of we ze 24/7 zullen gebruiken en voor welke doeleinden. Voor productie is bijvoorbeeld een server nodig die XNUMX/XNUMX draait, maar hebben we ook soortgelijke middelen nodig voor testen buiten werktijd? Het hangt ook af van het type test dat wordt uitgevoerd. Een voorbeeld hiervan zijn belasting-/stresstests die we buiten werktijd willen uitvoeren om de volgende dag resultaten te krijgen. Maar voor end-to-end geautomatiseerde tests is XNUMX/XNUMX serverbeschikbaarheid absoluut niet vereist, en al helemaal niet voor handmatige testomgevingen. Voor dergelijke situaties zou het goed zijn om op verzoek zoveel hulpbronnen te verkrijgen als nodig is, deze te gebruiken en te stoppen met betalen wanneer ze niet langer nodig zijn. Bovendien zou het geweldig zijn om ze direct te ontvangen door een paar muisklikken te maken of een paar scripts uit te voeren. Dit is waar publieke clouds voor worden gebruikt. Laten we eens kijken naar de definitie:
“De publieke cloud wordt gedefinieerd als computerdiensten die door externe providers via het openbare internet worden aangeboden en deze beschikbaar maken voor iedereen die deze wil gebruiken of kopen. Ze kunnen gratis zijn of op aanvraag worden verkocht, waardoor klanten alleen per gebruik hoeven te betalen voor de CPU-cycli, opslag of bandbreedte die ze verbruiken."
Er is een mening dat publieke clouds duur zijn. Maar hun belangrijkste idee is het verlagen van de bedrijfskosten. Zoals eerder vermeld, kunt u met publieke clouds op aanvraag bronnen verkrijgen en alleen betalen voor de tijd dat u ze gebruikt. Ook vergeten we soms dat werknemers salarissen ontvangen, en dat specialisten ook een dure hulpbron zijn. Er moet rekening mee worden gehouden dat publieke clouds de ondersteuning van de infrastructuur veel eenvoudiger maken, waardoor ingenieurs zich kunnen concentreren op belangrijkere taken.
Waarde voor automatiseringsinfrastructuur
Welke specifieke bronnen hebben we nodig voor end-to-end UI-tests? In feite zijn dit virtuele machines of clusters (we zullen het in de volgende sectie over Kubernetes hebben) voor het uitvoeren van browsers en emulators. Hoe meer browsers en emulators we tegelijkertijd willen gebruiken, hoe meer CPU en geheugen er nodig is en hoe meer geld we ervoor moeten betalen. Zo stellen publieke clouds in de context van testautomatisering ons in staat om een groot aantal (100, 200, 1000...) browsers/emulators op aanvraag uit te voeren, zo snel mogelijk testresultaten te verkrijgen en te stoppen met betalen voor zulke waanzinnig resource-intensieve stroom.
De meest populaire cloudproviders zijn Amazon Web Services (AWS), Microsoft Azure en Google Cloud Platform (GCP). De handleiding geeft voorbeelden van het gebruik van GCP, maar over het algemeen maakt het niet uit wat u gebruikt voor automatiseringstaken. Ze bieden allemaal ongeveer dezelfde functionaliteit. Bij het selecteren van een provider concentreert het management zich doorgaans op de gehele infrastructuur en zakelijke vereisten van het bedrijf, wat buiten het bestek van dit artikel valt. Voor automatiseringsingenieurs zal het interessanter zijn om het gebruik van cloudproviders te vergelijken met het gebruik van cloudplatforms specifiek voor testdoeleinden, zoals Sauce Labs, BrowserStack, BitBar, enzovoort. Dus laten we het ook doen! Naar mijn mening is Sauce Labs de bekendste cloudtestboerderij en daarom heb ik het ter vergelijking gebruikt.
GCP versus Sauce Labs voor automatiseringsdoeleinden:
Laten we ons voorstellen dat we tegelijkertijd 8 webtests en 8 Android-tests moeten uitvoeren. Hiervoor zullen we GCP gebruiken en 2 virtuele machines draaien met Selenoid. Bij de eerste zullen we 8 containers met browsers verhogen. Op de tweede staan 8 containers met emulators. Laten we eens kijken naar de prijzen:
Om één container met Chrome uit te voeren, hebben we nodig n1-standaard-1 auto. In het geval van Android zal dat wel het geval zijn n1-standaard-4 voor één emulator. Een flexibelere en goedkopere manier is in feite het instellen van specifieke gebruikerswaarden voor CPU/geheugen, maar op dit moment is dit niet belangrijk in vergelijking met Sauce Labs.
En hier zijn de tarieven voor het gebruik van Sauce Labs:
Ik geloof dat je het verschil al hebt opgemerkt, maar ik zal nog steeds een tabel met berekeningen voor onze taak geven:
Vereiste middelen
maandelijks
Werkuren(8 - 8 uur)
Werkuren+Verwijderbaar
GCP voor internet
n1-standaard-1 x 8 = n1-standaard-8
$194.18
23 dagen * 12 uur * 0.38 = $ 104.88
23 dagen * 12 uur * 0.08 = $ 22.08
Sauslabs voor internet
Virtuele Cloud8 parallelle tests
$1.559
-
-
GCP voor Android
n1-standaard-4 x 8: n1-standaard-16
$776.72
23 dagen * 12 uur * 1.52 = $ 419.52
23 dagen * 12 uur * 0.32 = $ 88.32
Sauslabs voor Android
Real Device Cloud 8 parallelle tests
$1.999
-
-
Zoals u kunt zien, is het verschil in kosten enorm, vooral als u alleen tests uitvoert tijdens een werkperiode van twaalf uur. Maar u kunt de kosten nog verder verlagen als u verwijderbare machines gebruikt. Wat is het?
Een verwijderbare VM is een instance die u tegen een veel lagere prijs kunt maken en uitvoeren dan normale instances. Compute Engine kan deze instanties echter beëindigen (voorrang nemen) als toegang tot deze bronnen nodig is voor andere taken. Verwijderbare instanties zijn overtollige Compute Engine-capaciteit, dus de beschikbaarheid ervan varieert afhankelijk van het gebruik.
Als uw apps fouttolerant zijn en mogelijke voorrang op instances kunnen weerstaan, kunnen verwijderbare instances uw Compute Engine-kosten aanzienlijk verlagen. Batchverwerkingstaken kunnen bijvoorbeeld worden uitgevoerd op verwijderbare exemplaren. Als sommige van deze exemplaren tijdens de verwerking worden beëindigd, wordt de taak langzamer, maar stopt deze niet volledig. Verwijderbare instances voltooien uw batchverwerkingstaken zonder extra werklast op uw bestaande instances te plaatsen en zonder dat u de volledige prijs hoeft te betalen voor extra normale instances.
En het is nog steeds niet voorbij! In werkelijkheid weet ik zeker dat niemand twaalf uur lang zonder pauze tests uitvoert. En als dat zo is, kunt u virtuele machines automatisch starten en stoppen wanneer ze niet nodig zijn. De werkelijke gebruikstijd kan worden teruggebracht tot 12 uur per dag. Dan daalt de betaling in het kader van onze opdracht naar $6 per maand voor 11 browsers. Is dit niet geweldig? Maar met vermijdbare machines moeten we voorzichtig zijn en voorbereid zijn op onderbrekingen en instabiliteit, ook al kunnen deze situaties softwarematig worden voorzien en afgehandeld. Het is het waard!
Maar ik zeg zeker niet 'gebruik nooit cloud-testfarms'. Ze hebben een aantal voordelen. Allereerst is dit niet zomaar een virtuele machine, maar een volwaardige testautomatiseringsoplossing met een set functionaliteit out-of-the-box: toegang op afstand, logs, screenshots, video-opname, verschillende browsers en fysieke mobiele apparaten. In veel situaties kan dit een essentieel chic alternatief zijn. Testplatforms zijn vooral handig voor IOS-automatisering, wanneer publieke clouds alleen Linux/Windows-systemen kunnen aanbieden. Maar we zullen het in de volgende artikelen over iOS hebben. Ik raad aan om altijd naar de situatie te kijken en te vertrekken vanuit de taken: in sommige gevallen is het goedkoper en efficiënter om publieke clouds te gebruiken, en in andere gevallen zijn de testplatforms het uitgegeven geld zeker waard.
Illustratie van de huidige staat van de infrastructuur
Links om te verkennen
Soortgelijke hulpmiddelen:
6. Orkestratie
Korte beschrijving van de technologie
Ik heb goed nieuws: we zijn bijna aan het einde van het artikel! Op dit moment bestaat onze automatiseringsinfrastructuur uit web- en Android-tests, die we parallel uitvoeren via GitLab CI, met behulp van Docker-compatibele tools: Selenium grid en Selenoid. Bovendien gebruiken we virtuele machines die via GCP zijn gemaakt om containers met browsers en emulators te hosten. Om de kosten te drukken starten we deze virtuele machines alleen op afroep en stoppen we ze als er niet getest wordt. Is er nog iets dat onze infrastructuur kan verbeteren? Het antwoord is ja! Maak kennis met Kubernetes (K8s)!
Laten we eerst eens kijken hoe de woorden orkestratie, cluster en Kubernetes aan elkaar gerelateerd zijn. Op een hoog niveau is orkestratie het systeem dat applicaties implementeert en beheert. Voor testautomatisering zijn dergelijke containertoepassingen Selenium grid en Selenoid. Docker en K8's vullen elkaar aan. De eerste wordt gebruikt voor de implementatie van applicaties, de tweede voor orkestratie. K8s is op zijn beurt een cluster. De taak van het cluster is om VM’s als Nodes in te zetten, waardoor je verschillende functionaliteiten, programma’s en diensten binnen één server (cluster) kunt installeren. Als een van de knooppunten uitvalt, zullen andere knooppunten het oppakken, wat een ononderbroken werking van onze applicatie garandeert. Daarnaast heeft K8s belangrijke functionaliteit met betrekking tot schaling, waardoor we automatisch de optimale hoeveelheid bronnen verkrijgen op basis van de belasting en ingestelde limieten.
In werkelijkheid is het handmatig implementeren van Kubernetes helemaal geen triviale taak. Ik laat een link achter naar de beroemde handleiding "Kubernetes The Hard Way" en als je geïnteresseerd bent, kun je deze oefenen. Maar gelukkig zijn er alternatieve methoden en hulpmiddelen. De eenvoudigste manier is om Google Kubernetes Engine (GKE) in GCP te gebruiken, waarmee u met een paar klikken een kant-en-klaar cluster kunt krijgen. Ik raad aan om deze aanpak te gebruiken om te beginnen met leren, omdat je je hierdoor kunt concentreren op het leren gebruiken van de K8's voor je taken in plaats van te leren hoe de interne componenten met elkaar moeten worden geïntegreerd.
Waarde voor automatiseringsinfrastructuur
Laten we eens kijken naar enkele belangrijke functies die de K8s biedt:
- applicatie-implementatie: gebruik van een cluster met meerdere knooppunten in plaats van VM's;
- dynamische schaalvergroting: verlaagt de kosten van hulpbronnen die alleen op afroep worden gebruikt;
- zelfgenezing: automatisch herstel van peulen (waardoor ook containers worden hersteld);
- uitrol van updates en terugdraaien van wijzigingen zonder downtime: het updaten van tools, browsers en emulators onderbreekt het werk van huidige gebruikers niet
Maar de K8s is nog steeds geen wondermiddel. Om alle voordelen en beperkingen te begrijpen in de context van de tools die we overwegen (Selenium-raster, Selenoid), zullen we kort de structuur van K8s bespreken. Cluster bevat twee soorten knooppunten: hoofdknooppunten en werkknooppunten. Master Nodes zijn verantwoordelijk voor beslissingen op het gebied van beheer, implementatie en planning. Werknemersknooppunten zijn waar applicaties worden gestart. Knooppunten bevatten ook een containerruntimeomgeving. In ons geval is dat Docker, verantwoordelijk voor de containergerelateerde operaties. Maar er zijn bijvoorbeeld ook alternatieve oplossingen. Het is belangrijk om te begrijpen dat schaalvergroting of zelfherstel niet rechtstreeks van toepassing is op containers. Dit wordt geïmplementeerd door het aantal pods toe te voegen/te verkleinen, die op hun beurt containers bevatten (meestal één container per pod, maar afhankelijk van de taak kunnen er meer zijn). De hiërarchie op hoog niveau bestaat uit werkknooppunten, waarbinnen zich pods bevinden, waarbinnen containers worden verhoogd.
De schaalfunctie is essentieel en kan worden toegepast op zowel knooppunten binnen een clusterknooppuntpool als op peulen binnen een knooppunt. Er zijn twee typen schaling die van toepassing zijn op zowel knooppunten als peulen. Het eerste type is horizontaal: schaling vindt plaats door het aantal knooppunten/pods te vergroten. Dit type heeft meer de voorkeur. Het tweede type is dienovereenkomstig verticaal. Schalen wordt uitgevoerd door de grootte van knooppunten/pods te vergroten, en niet door hun aantal.
Laten we nu eens kijken naar onze tools in de context van de bovenstaande termen.
Selenium rooster
Zoals eerder vermeld, is het Selenium-raster een zeer populair hulpmiddel, en het is geen verrassing dat het in containers is opgeslagen. Het is daarom geen verrassing dat het Selenium-raster kan worden ingezet in K8's. Een voorbeeld van hoe u dit kunt doen, kunt u vinden in de officiële K8s-repository. Zoals gewoonlijk voeg ik links toe aan het einde van de sectie. Bovendien laat de how-to-handleiding zien hoe u dit in Terraform kunt doen. Er zijn ook instructies voor het schalen van het aantal peulen dat browsercontainers bevat. Maar de automatische schaalfunctie in de context van K8s is nog steeds geen geheel voor de hand liggende taak. Toen ik begon met studeren, vond ik geen praktische begeleiding of aanbevelingen. Na verschillende onderzoeken en experimenten met de steun van het DevOps-team hebben we gekozen voor de aanpak om containers met de benodigde browsers in één pod te plaatsen, die zich in één werkknooppunt bevindt. Met deze methode kunnen we de strategie van horizontale schaalvergroting van knooppunten toepassen door hun aantal te vergroten. Ik hoop dat dit in de toekomst zal veranderen en dat we steeds meer beschrijvingen zullen zien van betere benaderingen en kant-en-klare oplossingen, vooral na de release van Selenium grid 4 met een gewijzigde interne architectuur.
Selenoïde:
Selenoid-implementatie in K8's is momenteel de grootste teleurstelling. Ze zijn niet compatibel. In theorie kunnen we een Selenoid-container in een pod plaatsen, maar wanneer Selenoid containers met browsers begint te lanceren, zullen ze zich nog steeds in dezelfde pod bevinden. Dit maakt schaalvergroting onmogelijk en als gevolg daarvan zal het werk van Selenoid binnen een cluster niet verschillen van het werk binnen een virtuele machine. Einde verhaal.
Moon:
Omdat ze dit knelpunt kenden bij het werken met Selenoid, brachten de ontwikkelaars een krachtigere tool uit genaamd Moon. Deze tool is oorspronkelijk ontworpen om met Kubernetes te werken en als gevolg daarvan kan en moet de functie voor automatisch schalen worden gebruikt. Bovendien zou ik zeggen dat het op dit moment zo is единственный een tool in de Selenium-wereld, die standaard native K8s-clusterondersteuning biedt (niet meer verkrijgbaar, zie volgende tool ). De belangrijkste kenmerken van Moon die deze ondersteuning bieden zijn:
Volledig staatloos. Selenoid slaat informatie op in het geheugen over momenteel lopende browsersessies. Als het proces om de een of andere reden crasht, gaan alle actieve sessies verloren. Moon heeft daarentegen geen interne status en kan worden gerepliceerd tussen datacenters. Browsersessies blijven actief, zelfs als een of meer replica's uitvallen.
Moon is dus een geweldige oplossing, maar er is één probleem: het is niet gratis. De prijs is afhankelijk van het aantal sessies. Je kunt slechts 0-4 sessies gratis uitvoeren, wat niet bijzonder nuttig is. Maar vanaf de vijfde sessie moet u voor elke sessie $ 5 betalen. De situatie kan van bedrijf tot bedrijf verschillen, maar in ons geval is het gebruik van Moon zinloos. Zoals ik hierboven heb beschreven, kunnen we op verzoek VM's met Selenium Grid uitvoeren of het aantal knooppunten in het cluster vergroten. Voor ongeveer één pijplijn lanceren we 500 browsers en stoppen we alle bronnen nadat de tests zijn voltooid. Als we Moon zouden gebruiken, zouden we 500 x 5 = $2500 per maand extra moeten betalen, ongeacht hoe vaak we tests uitvoeren. Nogmaals, ik zeg niet dat je Moon niet moet gebruiken. Voor uw taken kan dit een onmisbare oplossing zijn, bijvoorbeeld als u veel projecten/teams in uw organisatie heeft en u een groot gemeenschappelijk cluster voor iedereen nodig heeft. Zoals altijd laat ik aan het einde een link achter en raad ik aan om alle noodzakelijke berekeningen uit te voeren in de context van uw taak.
Callisto(Aandacht! Dit staat niet in het originele artikel en staat alleen in de Russische vertaling)
Zoals ik al zei, is Selenium een zeer populair hulpmiddel en ontwikkelt het IT-veld zich zeer snel. Terwijl ik aan de vertaling werkte, verscheen er een nieuwe veelbelovende tool genaamd Callisto op het internet (hallo Cypress en andere Selenium-moordenaars). Het werkt native met K8s en stelt u in staat Selenoid-containers in pods uit te voeren, verdeeld over knooppunten. Alles werkt direct uit de doos, inclusief automatisch schalen. Fantastisch, maar moet getest worden. Ik ben er al in geslaagd deze tool in te zetten en verschillende experimenten uit te voeren. Maar het is te vroeg om conclusies te trekken, nadat ik resultaten over een lange afstand heb ontvangen, zal ik misschien een recensie doen in toekomstige artikelen. Voorlopig laat ik alleen links achter voor onafhankelijk onderzoek.
Illustratie van de huidige staat van de infrastructuur
Links om te verkennen
Soortgelijke hulpmiddelen
7. Infrastructuur als code (IaC)
Korte beschrijving van de technologie
En nu komen we bij het laatste deel. Normaal gesproken vallen deze technologie en de daarmee samenhangende taken niet onder de verantwoordelijkheid van automatiseringsingenieurs. En daar zijn redenen voor. Ten eerste vallen infrastructuurproblemen in veel organisaties onder de controle van de DevOps-afdeling en maakt het de ontwikkelingsteams niet zoveel uit wat de pijplijn doet werken en hoe alles wat daarmee samenhangt moet worden ondersteund. Ten tweede, laten we eerlijk zijn: de praktijk van Infrastructure as Code (IaC) wordt in veel bedrijven nog steeds niet toegepast. Maar het is zeker een populaire trend geworden en het is belangrijk om betrokken te zijn bij de processen, benaderingen en hulpmiddelen die ermee gepaard gaan. Of blijf in ieder geval op de hoogte.
Laten we beginnen met de motivatie om deze aanpak te gebruiken. We hebben al besproken dat we, om tests in GitlabCI uit te voeren, op zijn minst de middelen nodig hebben om Gitlab Runner uit te voeren. En om containers met browsers/emulators uit te voeren, moeten we een VM of cluster reserveren. Naast het testen van middelen hebben we een aanzienlijke hoeveelheid capaciteit nodig ter ondersteuning van ontwikkeling, staging en productieomgevingen, waaronder ook databases, automatische schema's, netwerkconfiguraties, load balancers, gebruikersrechten, enzovoort. Het belangrijkste punt is de inspanning die nodig is om dit alles te ondersteunen. Er zijn verschillende manieren waarop we wijzigingen kunnen aanbrengen en updates kunnen uitrollen. In de context van GCP kunnen we bijvoorbeeld de UI-console in de browser gebruiken en alle acties uitvoeren door op knoppen te klikken. Een alternatief zou zijn om API-aanroepen te gebruiken om te communiceren met cloudentiteiten, of om het gcloud-opdrachtregelhulpprogramma te gebruiken om de gewenste manipulaties uit te voeren. Maar met een heel groot aantal verschillende entiteiten en infrastructuurelementen wordt het moeilijk of zelfs onmogelijk om alle handelingen handmatig uit te voeren. Bovendien zijn al deze handmatige handelingen oncontroleerbaar. We kunnen ze niet ter beoordeling indienen voordat ze worden uitgevoerd, geen versiebeheersysteem gebruiken en de wijzigingen die tot het incident hebben geleid, snel terugdraaien. Om dergelijke problemen op te lossen, hebben ingenieurs automatische bash/shell-scripts gemaakt en gemaakt, die niet veel beter zijn dan eerdere methoden, omdat ze niet zo gemakkelijk snel te lezen, te begrijpen, te onderhouden en aan te passen zijn in een procedurele stijl.
In dit artikel en de handleiding gebruik ik twee hulpmiddelen die verband houden met de IaC-praktijk. Dit zijn Terraform en Ansible. Sommige mensen zijn van mening dat het geen zin heeft om ze tegelijkertijd te gebruiken, omdat hun functionaliteit vergelijkbaar is en ze uitwisselbaar zijn. Maar feit is dat ze aanvankelijk totaal verschillende taken krijgen. En het feit dat deze tools elkaar zouden moeten aanvullen werd bevestigd tijdens een gezamenlijke presentatie door ontwikkelaars die HashiCorp en RedHat vertegenwoordigden. Het conceptuele verschil is dat Terraform een provisioningtool is voor het beheer van de servers zelf. Terwijl Ansible een configuratiebeheertool is die tot taak heeft software op deze servers te installeren, configureren en beheren.
Een ander belangrijk onderscheidend kenmerk van deze tools is de codeerstijl. In tegenstelling tot bash en Ansible gebruikt Terraform een declaratieve stijl gebaseerd op een beschrijving van de gewenste eindtoestand die als resultaat van de uitvoering moet worden bereikt. Als we bijvoorbeeld 10 VM's gaan maken en de wijzigingen via Terraform gaan toepassen, krijgen we 10 VM's. Als we het script opnieuw uitvoeren, gebeurt er niets omdat we al 10 VM's hebben, en Terraform weet hiervan omdat het de huidige status van de infrastructuur opslaat in een statusbestand. Maar Ansible gebruikt een procedurele aanpak en als je het vraagt om 10 VM's te maken, krijgen we bij de eerste lancering 10 VM's, vergelijkbaar met Terraform. Maar na het opnieuw opstarten hebben we al 20 VM's. Dit is het belangrijke verschil. In procedurele stijl slaan we niet de huidige status op, maar beschrijven we eenvoudigweg een reeks stappen die moeten worden uitgevoerd. Natuurlijk kunnen we verschillende situaties aan, en verschillende controles toevoegen voor het bestaan van hulpbronnen en de huidige staat, maar het heeft geen zin om onze tijd te verspillen en moeite te doen om deze logica onder controle te houden. Bovendien vergroot dit de kans op het maken van fouten.
Als we al het bovenstaande samenvatten, kunnen we concluderen dat Terraform en declaratieve notatie een geschikter hulpmiddel zijn voor het inrichten van servers. Maar het is beter om het werk van configuratiebeheer aan Ansible te delegeren. Laten we, nu dat uit de weg is, eens kijken naar gebruiksscenario's in de context van automatisering.
Waarde voor automatiseringsinfrastructuur
Het enige belangrijke dat u hier moet begrijpen, is dat de testautomatiseringsinfrastructuur moet worden beschouwd als onderdeel van de gehele bedrijfsinfrastructuur. Dit betekent dat alle IaC-praktijken wereldwijd moeten worden toegepast op de middelen van de hele organisatie. Wie hiervoor verantwoordelijk is, hangt af van uw processen. Het DevOps-team heeft meer ervaring met deze kwesties, zij zien het hele plaatje van wat er gebeurt. QA-ingenieurs zijn echter meer betrokken bij het proces van gebouwautomatisering en de structuur van de pijplijn, waardoor ze alle vereiste veranderingen en mogelijkheden voor verbetering beter kunnen zien. De beste optie is samenwerken, kennis en ideeën uitwisselen om het verwachte resultaat te bereiken.
Hier zijn een paar voorbeelden van het gebruik van Terraform en Ansible in de context van testautomatisering en de tools die we eerder hebben besproken:
1. Beschrijf de noodzakelijke kenmerken en parameters van VM's en clusters met behulp van Terraform.
2. Installeer met behulp van Ansible de tools die nodig zijn voor het testen: docker, Selenoid, Selenium Grid en download de vereiste versies van browsers/emulators.
3. Beschrijf met behulp van Terraform de kenmerken van de VM waarin GitLab Runner zal worden gelanceerd.
4. Installeer GitLab Runner en de benodigde bijbehorende tools met behulp van Ansible, stel instellingen en configuraties in.
Illustratie van de huidige staat van de infrastructuur
Links om te verkennen:
Soortgelijke hulpmiddelen
Laten we het samenvatten!
Stap voor
Technologie
Tools
Waarde voor automatiseringsinfrastructuur
1
Lokaal hardlopen
Node.js, Selenium, Appium
- De meest populaire tools voor web en mobiel
- Ondersteunt vele talen en platforms (waaronder Node.js)
2
Versiebeheersystemen
Git
- Soortgelijke voordelen met ontwikkelingscode
3
Containerisatie
Docker, Selenium-raster, Selenoid (web, Android)
- Parallelle tests uitvoeren
- Geïsoleerde omgevingen
- Eenvoudige, flexibele versie-upgrades
- Dynamisch stoppen van ongebruikte bronnen
- Makkelijk op te zetten
4
CI/CD
Gitlab-CI
- Test een deel van de pijplijn
- Snelle feedback
- Zichtbaarheid voor het hele bedrijf/team
5
Cloud platforms
Google Cloud Platform
- Middelen op aanvraag (we betalen alleen wanneer dat nodig is)
- Eenvoudig te beheren en te updaten
- Zichtbaarheid en controle over alle middelen
6
orkestratie
Kubernetes
In de context van containers met browsers/emulators in pods:
- Schalen/automatisch schalen
- Zelfgenezend
- Updates en rollbacks zonder onderbreking
7
Infrastructuur als code (IaC)
Terraform, Ansible
- Soortgelijke voordelen met ontwikkelingsinfrastructuur
- Alle voordelen van codeversiebeheer
- Gemakkelijk wijzigingen aan te brengen en te onderhouden
- Volledig geautomatiseerd
Mindmapdiagrammen: evolutie van infrastructuur
stap 1: Lokaal
stap 2: VCS
stap3: Containerisatie
stap 4: CI/CD
stap 5: Cloudplatforms
stap6:Orchestratie
stap 7: IaC
Wat is het volgende?
Dit is dus het einde van het artikel. Maar tot slot wil ik graag enkele afspraken met u maken.
Van jouw kant
Zoals in het begin gezegd, zou ik graag willen dat het artikel van praktisch nut is en u helpt de opgedane kennis in het echte werk toe te passen. Ik voeg opnieuw toe.
Maar ook daarna: stop niet, oefen, bestudeer relevante links en boeken, ontdek hoe het werkt in uw bedrijf, vind plekken die verbeterd kunnen worden en neem eraan deel. Succes!
Van mijn kant
Aan de titel kun je zien dat dit pas het eerste deel was. Ondanks dat het behoorlijk groot bleek te zijn, worden belangrijke onderwerpen hier nog steeds niet behandeld. In het tweede deel ben ik van plan om te kijken naar de automatiseringsinfrastructuur in de context van IOS. Vanwege de beperkingen van Apple op het uitvoeren van iOS-simulators alleen op macOS-systemen, is ons aanbod aan oplossingen beperkt. We kunnen Docker bijvoorbeeld niet gebruiken om de simulator uit te voeren, of openbare clouds om virtuele machines uit te voeren. Maar dit betekent niet dat er geen andere alternatieven zijn. Ik zal proberen je op de hoogte te houden van geavanceerde oplossingen en moderne tools!
Ook heb ik nog geen grote onderwerpen genoemd die verband houden met monitoring. In deel 3 ga ik kijken naar de populairste tools voor infrastructuurmonitoring en welke gegevens en statistieken ik moet overwegen.
En tenslotte. In de toekomst ben ik van plan een videocursus uit te brengen over het bouwen van testinfrastructuur en populaire tools. Momenteel zijn er nogal wat cursussen en lezingen over DevOps op internet, maar alle materialen worden gepresenteerd in de context van ontwikkeling, niet van testautomatisering. Op dit punt heb ik echt feedback nodig over de vraag of een dergelijke cursus interessant en waardevol zal zijn voor de gemeenschap van testers en automatiseringsingenieurs. Alvast bedankt!
Bron: www.habr.com