Deel 1: Web / Android
Opmerking: dit artikel is een vertaling in het Russisch van het originele artikel Echter, alle illustraties, links, citaten en termen blijven in de originele taal om vervorming van de betekenis bij de vertaling naar het Russisch te voorkomen. Ik wens je veel plezier met het leren!
Tegenwoordig is het beroep DevOps een van de meest gevraagde in de IT-industrie. Als je populaire vacaturesites opent en een filter voor salarissen instelt, zie je dat vacatures gerelateerd aan DevOps bovenaan de lijst staan. Het is echter belangrijk om te begrijpen dat dit voornamelijk betrekking heeft op de positie 'Senior', wat inhoudt dat de kandidaat een hoog niveau van vaardigheden, kennis van technologieën en tools heeft. Dit gaat ook gepaard met een hoge mate van verantwoordelijkheid voor een ononderbroken werking van de productie. We lijken echter te vergeten wat DevOps eigenlijk is. Oorspronkelijk was het niet een specifieke persoon of afdeling. Als we naar definities van deze term zoeken, zullen we veel mooie en correcte zelfstandige naamwoorden vinden, zoals methodologie, praktijken, culturele filosofie, een groep concepten, enzovoort.
Mijn specialisatie is QA automation engineer, maar ik beschouw het niet alleen als het schrijven van automatische tests of het ontwikkelen van een testframework-architectuur. In 2020 zijn kennis van automatiseringsinfrastructuur ook noodzakelijk. Dit stelt je in staat om het automatiseringsproces zelf te organiseren, van het starten van tests tot het presenteren van resultaten aan alle belanghebbenden in overeenstemming met de gestelde doelen. Hierdoor zijn DevOps-vaardigheden een cruciale factor voor het uitvoeren van deze taak. En dat is goed, maar helaas is er een probleem (spoiler: dit artikel probeert dit probleem te vereenvoudigen). Het probleem is dat DevOps moeilijk is. En dat is duidelijk, want bedrijven willen niet veel betalen voor iets wat gemakkelijk te doen is... In de wereld van DevOps zijn er veel tools, termen en praktijken die je moet beheersen. Vooral in het begin van je carrière is dit moeilijk en hangt het af van de opgedane technische ervaring.
Bron:
Laten we hier de inleiding afsluiten en ons richten op het doel van dit artikel.
Waar gaat dit artikel over
In dit artikel ga ik mijn ervaringen delen over het opzetten van een infrastructuur voor testautomatisering. Op het internet zijn veel bronnen te vinden over verschillende tools en hoe deze te gebruiken, maar ik wil ze uitsluitend in de context van automatisering bekijken. Ik denk dat veel testautomatiseringsingenieurs zich kunnen herkennen in de situatie waarin de ontwikkelde tests, behalve door uzelf, door niemand worden uitgevoerd en onderhouden. Dit leidt ertoe dat tests verouderen en er tijd besteed moet worden aan hun actualisatie. Vooral in het begin van een carrière kan dit een behoorlijke uitdaging zijn: de juiste beslissing nemen over welke tools moeten helpen bij het oplossen van dit probleem, hoe ze te kiezen, in te stellen en te onderhouden. Sommige testers vragen hulp aan DevOps (mensen) en laten we eerlijk zijn, deze aanpak werkt. In veel gevallen kan dit de enige optie zijn, omdat we geen zicht hebben op alle afhankelijkheden. Maar zoals we weten, zijn DevOps heel druk bezig, want ze moeten denken aan de infrastructuur van het hele bedrijf, deployment, monitoring, microservices en andere soortgelijke taken, afhankelijk van de organisatie/team. Zoals meestal het geval is, is automatisering geen prioriteit. In dat geval moeten we proberen alles te doen wat we kunnen van begin tot eind. Dit zal de afhankelijkheden verminderen, de workflow versnellen, onze vaardigheden verbeteren en ons in staat stellen een breder beeld van de situatie te zien.
In het artikel worden de meest gevraagde en populaire tools gepresenteerd en wordt getoond hoe deze stap voor stap te gebruiken zijn voor het opzetten van een infrastructuur voor automatisering. Elke groep wordt gepresenteerd met tools die op persoonlijke ervaring zijn getest. Maar dat betekent niet dat u hetzelfde moet gebruiken. De tools zelf zijn niet belangrijk, ze verschijnen en verouderen. Onze technische taak is het begrijpen van de basisprincipes: waarom hebben we deze groep tools nodig en welke werkgerelateerde taken kunnen we hiermee oplossen? Daarom laat ik aan het einde van elke sectie links achter naar soortgelijke tools die misschien in uw organisatie worden gebruikt.
Wat er in dit artikel niet aanwezig is
Ik herhaal nogmaals dat het artikel niet over specifieke tools gaat, daarom zal er geen code-invoegingen uit de documentatie of beschrijvingen van specifieke commando's zijn. Aan het einde van elke sectie laat ik echter links achter voor een gedetailleerde studie.
Dit is gedaan omdat:
- dit materiaal heel gemakkelijk te vinden is in verschillende bronnen (documentatie, boeken, videotrainingen);
- als we verder in detail gaan, zullen we 10, 20, 30 delen van dit artikel moeten schrijven (terwijl er nu 2-3 gepland zijn);
- ik wil gewoon uw tijd niet verspillen, want misschien wilt u andere tools gebruiken om dezelfde doelen te bereiken.
Praktijk
Ik hoop van harte dat dit materiaal nuttig is voor elke lezer en niet alleen maar gelezen en vergeten wordt. Bij elke studie is oefening een heel belangrijk onderdeel. Daarom heb ik voorbereid. U kunt ook rekenen op huiswerk, zodat u zeker weet dat u de uitvoeringscommando's niet blindelings hebt gekopieerd.
Plan
Stap
Technologie
Tools
1
Lokale uitvoering (voorbereiden van web/android demo tests en deze lokaal uitvoeren)
Node.js, Selenium, Appium
2
Versiebeheersystemen
Git
3
Containerisatie
Docker, Selenium-grid, Selenoid (Web, Android)
4
CI / CD
Gitlab CI
5
Cloudplatforms
Google Cloud Platform
6
Orkestratie
Kubernetes
7
Infrastructure as Code (IaC)
Terraform, Ansible
Structuur van elke sectie
Om het verhaal visueel te houden, is elke sectie volgens het volgende schema beschreven:
- korte beschrijving van de technologie,
- waarde voor de automatiseringsinfrastructuur,
- illustratie van de huidige staat van de infrastructuur,
- links voor studie,
- vergelijkbare tools.
1. Lokale uitvoering van tests
Korte beschrijving van de technologie
Dit is slechts een voorbereidende stap voor het lokaal uitvoeren van demonstratietests en voor het controleren of ze met succes worden uitgevoerd. In het praktische deel wordt Node.js gebruikt, maar de programmeertaal en het platform zijn ook niet belangrijk en men kan die gebruiken die in uw bedrijf worden gebruikt.
Echter, voor automatiseringstools raad ik aan om Selenium WebDriver voor webplatformen en Appium voor Android-platformen te gebruiken, omdat we in de volgende stappen Docker-images zullen gebruiken die specifiek zijn geconfigureerd voor deze tools. Bovendien, verwijzend naar de vereisten in vacatures, zijn deze tools het meest gewild op de markt.
Zoals je hebt kunnen opmerken, kijken we alleen naar web- en Android-tests. Helaas is IOS een compleet ander verhaal (dank je Apple). Ik ben van plan om oplossingen en praktijken met betrekking tot IOS in volgende delen te demonstreren.
Waarde voor automatiseringsinfrastructuur
Vanuit het perspectief van infrastructuur heeft lokaal draaien geen enkele waarde. Je controleert alleen of de tests werken op de lokale machine in lokale browsers en simulators. Maar hoe dan ook is dit een noodzakelijke startpunt.
Illustratie van de huidige status van de infrastructuur
Links om te verkennen
Vergelijkbare tools
- elke programmeertaal die je leuk vindt, in combinatie met Selenium/Appium - testen;
- elke tests;
- elke test-runner.
2. Versiebeheersystemen (Git)
Korte beschrijving van de technologie
Het zal niemand verrassen als ik zeg dat versiebeheer een uiterst belangrijk onderdeel van ontwikkeling is, zowel in teamverband als individueel. Op basis van verschillende bronnen kan met zekerheid worden gesteld dat Git de meest populaire vertegenwoordiger is. Een versiebeheersysteem biedt tal van voordelen, zoals code-uitwisseling, versieopslag, herstel naar eerdere takken, projectgeschiedenis volgen, back-ups. We zullen elk punt niet in detail bespreken, omdat ik ervan overtuigd ben dat je hiermee goed bekend bent en het in je dagelijkse werk gebruikt. Maar als je dat nog niet hebt gedaan, raad ik je aan om te stoppen met deze artikel te lezen en deze leemte zo snel mogelijk in te vullen.
Waarde voor automatiseringsinfrastructuur
En hier kun je een terechte vraag stellen: "Waarom vertelt hij ons over Git? Iedereen weet dit en gebruikt het zowel voor codeontwikkeling als voor autotests." Je zou helemaal gelijk hebben, maar in dit artikel praten we over infrastructuur en deze sectie fungeert als een preview voor sectie 7: "Infrastructuur als code (IaC)". Voor ons betekent dit dat de volledige infrastructuur, inclusief de test-infrastructuur, wordt beschreven in de vorm van code, en we kunnen versiebeheersystemen ook op deze toepassen en vergelijkbare voordelen behalen zoals voor codeontwikkeling en automatisering.
We zullen IaC in stap 7 nader bekijken, maar zelfs nu kun je al lokaal met Git aan de slag door een lokale repository te maken. Het bredere beeld zal zich ontvouwen wanneer we een externe repository aan de infrastructuur toevoegen.
Illustratie van de huidige status van de infrastructuur
Links om te verkennen
Vergelijkbare tools
3. Containerization (Docker)
Korte beschrijving van de technologie
Om te demonstreren hoe containerisatie de spelregels heeft veranderd, laten we enkele decennia teruggaan. Vroeger kochten en gebruikten mensen servers om applicaties te draaien. Maar in de meeste gevallen waren de benodigde middelen voor uitvoering niet van tevoren bekend. Dit leidde ertoe dat bedrijven geld uitgaven aan de aankoop van dure krachtige servers, waarbij een deel van deze capaciteit niet volledig werd benut.
De volgende fase in de evolutie waren virtuele machines (VM), die de kwestie van onbenutte middelen oplosten. Deze technologie maakte het mogelijk om applicaties onafhankelijk van elkaar binnen één server te draaien, met volledig geïsoleerde ruimtes. Maar helaas heeft elke technologie zijn nadelen. Het draaien van een VM vereist een volledige besturingssysteem, wat CPU, RAM, opslag verbruikt en afhankelijk van het besturingssysteem moeten licentiekosten in overweging worden genomen. Deze factoren beïnvloeden de opstarttijd en compliceren de draagbaarheid.
En zo zijn we bij containerisatie aangekomen. Deze technologie loste opnieuw het vorige probleem op, omdat containers geen volledig besturingssysteem gebruiken, waardoor een groot aantal middelen vrijkomt en een snelle en flexibele oplossing voor draagbaarheid biedt.
Zeker, containerisatie is geen nieuwe technologie en werd voor het eerst geïntroduceerd eind jaren '70. In die tijd vonden er veel onderzoeken, ontwikkelingen en pogingen plaats. Maar het was Docker dat deze technologie adapteerde en toegankelijk maakte voor de massa. Tegenwoordig, wanneer we over containers spreken, bedoelen we in de meeste gevallen Docker. Wanneer we het hebben over Docker-containers, verwijzen we naar Linux-containers. We kunnen Windows- en macOS-systemen gebruiken om containers te draaien, maar het is belangrijk om te begrijpen dat er dan een extra laag ontstaat. Bijvoorbeeld, Docker op Mac draait onopgemerkt containers binnen een lichte Linux VM. We zullen hier later op terugkomen wanneer we het hebben over het draaien van Android-emulators in containers, omdat er hier een zeer belangrijke nuance is die we grondiger moeten bespreken.
Waarde voor automatiseringsinfrastructuur
We hebben ontdekt dat containerisatie en Docker geweldig zijn. Laten we dit bekijken in de context van automatisering, want elke tool of technologie moet een probleem oplossen. Laten we de voor de hand liggende problemen van testautomatisering in de context van UI-tests benoemen:
- een groot aantal afhankelijkheden bij de installatie van Selenium en vooral Appium;
- compatibiliteitsproblemen tussen versies van browsers, simulators en drivers;
- gebrek aan een geïsoleerde ruimte voor browsers/simulators, wat vooral kritiek is voor parallelle uitvoeringen;
- moeilijk te beheren en te onderhouden als het nodig is om 10, 50, 100 of zelfs 1000 browsers tegelijkertijd uit te voeren.
Maar aangezien Selenium de populairste tool voor automatisering is en Docker de populairste tool voor containerisatie, zou het niemand moeten verbazen dat iemand heeft geprobeerd ze te combineren om een krachtige tool te creëren voor het oplossen van de eerder genoemde problemen. Laten we dergelijke oplossingen nader bekijken.
Selenium grid in docker
Deze tool is de populairste ter wereld voor Selenium om meerdere browsers op verschillende machines te starten en vanuit een centraal punt te beheren. Voor het opstarten moet je minimaal 2 onderdelen registreren: Hub en Node(s). Hub is het centrale knooppunt dat alle verzoeken van tests ontvangt en deze verdeelt over de bijbehorende Nodes. Voor elke Node kunnen we een specifieke configuratie instellen, bijvoorbeeld door de gewenste browser en versie op te geven. We moeten echter zelf zorgen voor de compatibele stuurprogramma's voor de browsers en deze op de juiste Nodes installeren. Om deze reden wordt Selenium grid niet in pure vorm gebruikt, behalve in gevallen waarin we moeten werken met browsers die niet op Linux OS kunnen worden geïnstalleerd. Voor alle andere gevallen is het aanzienlijk flexibeler en correcter om Docker-images te gebruiken voor het uitvoeren van Selenium grid Hub en Nodes. Deze aanpak vereenvoudigt sterk het beheer van de knooppunten, omdat we het gewenste beeld kunnen kiezen met al geïnstalleerde compatibele versies van browsers en stuurprogramma's.
Ondanks de negatieve feedback over de stabiliteit van de werking, vooral bij het gelijktijdig starten van een groot aantal Nodes, blijft Selenium grid de populairste tool voor het parallel uitvoeren van Selenium-tests. Het is belangrijk op te merken dat er in de open-sourcegemeenschap voortdurend verschillende verbeteringen en aanpassingen aan deze tool worden toegevoegd, die proberen verschillende knelpunten aan te pakken.
Selenoid voor Web
Deze tool is een doorbraak in de wereld van Selenium, omdat hij direct uit de doos werkt en het leven van veel automatiseringsingenieurs aanzienlijk eenvoudiger heeft gemaakt. Dit is vooral geen simpele aanpassing van Selenium grid. In plaats daarvan hebben de ontwikkelaars een volledig nieuwe versie van Selenium Hub in de programmeertaal Golang gecreëerd, wat samen met lichte Docker-images voor verschillende browsers een impuls heeft gegeven aan de automatisering van tests. Bovendien moeten we in het geval van Selenium Grid vooraf alle benodigde browsers en hun versies definiëren, wat geen probleem is wanneer we met slechts één browser werken. Maar wanneer het gaat om meerdere ondersteunde browsers, is Selenoid de nummer één oplossing, dankzij de functie 'browser op aanvraag'. Het enige wat we hoeven te doen, is de benodigde images met browsers vooraf te laden en het configuratiebestand bij te werken waarmee Selenoid interactie heeft. Zodra Selenoid een verzoek van de tests ontvangt, start het automatisch de benodigde container met de juiste browser. Wanneer de test is voltooid, verwijdert Selenoid de container, waardoor middelen vrijkomen voor de volgende verzoeken. Deze aanpak elimineert volledig het bekende probleem van 'degradatie van knooppunten', dat we vaak in Selenium grid tegenkomen.
Maar helaas is Selenoid nog steeds geen zilveren kogel. We hebben de functie 'browser op aanvraag' gekregen, maar de functie 'middelen op aanvraag' is nog steeds niet beschikbaar. Voor het gebruik van Selenoid moeten we het op fysieke hardware of op een VM implementeren, wat betekent dat we van tevoren moeten weten hoeveel middelen we moeten toewijzen. Ik denk dat dit geen probleem is voor kleine projecten die 10, 20 of zelfs 30 browsers tegelijkertijd uitvoeren. Maar wat als we 100, 500, 1000 of meer nodig hebben? Het heeft geen enkele zin om zo'n aantal middelen voortdurend te onderhouden en ervoor te betalen. In sectie 5 en 6 van dit artikel zullen we oplossingen bespreken die het mogelijk maken om op te schalen, waardoor de kosten voor het bedrijf aanzienlijk worden verlaagd.
Selenoid voor Android
Na het succes van Selenoid als een tool voor webautomatisering wilden mensen iets soortgelijks voor Android. En dat is gebeurd – Selenoid is uitgebracht met ondersteuning voor Android. Vanuit een hoog niveau gebruikersperspectief is het principe vergelijkbaar met webautomatisering. Het enige verschil is dat in plaats van containers met browsers, Selenoid containers met Android-emulators opstart. Naar mijn mening is dit op dit moment de meest krachtige gratis tool om Android-tests parallel uit te voeren.
Ik zou heel graag niet over de negatieve kanten van deze tool willen praten, omdat ik het echt heel leuk vind. Maar er zijn toch dezelfde nadelen die ook betrekking hebben op webautomatisering, welke te maken hebben met schaling. Bovendien moet ik nog een beperking benoemen die een verrassing kan zijn als we de tool voor de eerste keer instellen. Voor het draaien van Android-images hebben we een fysieke machine of een VM met nested virtualisatie nodig – ondersteuning. In de praktische handleiding laat ik zien hoe je dit activeert op een Linux VM. Echter, als je een macOS-gebruiker bent en Selenoid lokaal wilt opzetten, zal het draaien van Android-tests niet mogelijk zijn. Maar je kunt altijd een Linux VM lokaal draaien met ingeschakelde 'nested virtualisatie' en Selenoid binnenin implementeren.
Illustratie van de huidige status van de infrastructuur
In de context van dit artikel zullen we 2 tools toevoegen ter illustratie van de infrastructuur. Dit zijn Selenium grid voor webtests en Selenoid voor Android-tests. In de handleiding op GitHub zal ik ook laten zien hoe je Selenoid kunt gebruiken voor het draaien van webtests.
Links om te verkennen
Vergelijkbare tools
- Er zijn andere containerization-tools, maar Docker is de meest populaire. Als je iets anders wilt proberen, houd er dan rekening mee dat de tools die we hebben bekeken voor het parallel draaien van Selenium-tests niet automatisch zullen werken.
- Zoals al gezegd, zijn er veel varianten van Selenium grid, bijvoorbeeld,.
4. CI / CD
Korte beschrijving van de technologie
De praktijk van continue integratie is vrij populair in de ontwikkeling en staat op dezelfde hoogte als versiesystemen. Ondanks dit gevoel heb ik dat er verwarring bestaat over de terminologie. In deze paragraaf wil ik drie varianten van deze technologie beschrijven vanuit mijn perspectief. Op internet vind je veel artikelen met verschillende interpretaties, en het is volkomen normaal als jouw mening hiervan afwijkt. Het belangrijkste is dat je op dezelfde golflengte zit met je collega's.
Er zijn dus drie termen: CI — Continuous Integration (continue integratie), CD — Continuous Delivery (continue levering) en weer CD — Continuous Deployment (continue uitrol).Voortaan zal ik deze termen in het Engels gebruiken.. Elke variant voegt enkele extra stappen toe aan je ontwikkelingspijplijn. Maar het woord continuous (continue) is het belangrijkste. In deze context bedoelen we iets dat van begin tot eind gebeurt, zonder onderbrekingen of handmatige tussenkomst. Laten we CI & CD en CD in deze context bekijken.
- Continue Integratie – is de eerste stap in de evolutie. Nadat we nieuwe code naar de server hebben gestuurd, verwachten we snel feedback dat onze wijzigingen in orde zijn. Gewoonlijk omvat CI het uitvoeren van statische codeanalyse tools en unit/intern API tests. Dit stelt ons in staat om binnen enkele seconden/minuten informatie over onze code te verkrijgen.
- Continue Levering is een meer geavanceerde stap, waarbij we integratie/UI-tests uitvoeren. Op dit niveau krijgen we echter niet zo snel resultaten als bij CI. Ten eerste vereisen deze soorten tests meer tijd om te doorlopen. Ten tweede moeten we onze wijzigingen in een test/staging omgeving uitrollen voordat we beginnen. Bovendien, als we het over mobiele ontwikkeling hebben, komt er een extra stap bij voor het bouwen van onze applicatie.
- Continue Deployment veronderstelt dat we onze wijzigingen automatisch uitrollen (release) naar productie, als alle acceptatietests zijn doorstaan in de vorige fasen. Daarnaast kan er na de release-fase verschillende stappen worden ingesteld, zoals het uitvoeren van smoke-tests op productie en het verzamelen van relevante metrics. Continuous Deployment is alleen mogelijk bij een goede dekking door geautomatiseerde tests. Als er handmatige tussenkomsten nodig zijn, inclusief testen, dan is dat niet meer. Continue (continu). Dan kunnen we zeggen dat onze pijplijn alleen overeenkomt met 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 inhoudt dat we onze wijzigingen en bijbehorende services moeten implementeren op testomgevingen. Continuous Integration is niet van toepassing voor deze taak en we moeten ervoor zorgen dat we minimaal Continuous Delivery-praktijken implementeren. Continuous Deployment heeft ook zin in de context van UI-tests, als we van plan zijn deze op productie uit te voeren.
En voordat we naar de illustratie van de wijziging in de architectuur kijken, wil ik een paar woorden zeggen over GitLab CI. In tegenstelling tot andere CI/CD-tools biedt GitLab een externe repository en veel andere aanvullende functies. Dus GitLab is meer dan CI. Het bevat out-of-the-box versiebeheer, Agile management, CI/CD pipelines, loggingtools en metrics. De architectuur van GitLab bestaat uit GitLab CI/CD en GitLab Runner. Hier volgt een korte beschrijving van de officiële site:
Gitlab CI/CD is een webapplicatie met een API die zijn status in een database opslaat, projecten/bouwingen beheert en een gebruikersinterface biedt. GitLab Runner is een applicatie die builds verwerkt. Deze kan afzonderlijk worden geïmplementeerd en werkt met GitLab CI/CD via een API. Voor het uitvoeren van tests heb je zowel een Gitlab-instantie als een Runner nodig.
Illustratie van de huidige status van de infrastructuur
Links om te verkennen
Vergelijkbare tools
- En vele anderen
5. Cloudplatforms
Korte beschrijving van de technologie
In dit gedeelte bespreken we een populaire trend die 'publieke cloud' wordt genoemd. Ondanks de enorme voordelen die de eerder beschreven virtualisatie- en containerisatietechnologieën bieden, hebben we nog steeds rekenkracht nodig. Bedrijven kopen dure servers of huren datacenters, maar in dat geval moeten we berekeningen maken (soms onrealistisch) over hoeveel middelen we nodig hebben, of we deze 24/7 zullen gebruiken en voor welke doeleinden. Bijvoorbeeld, voor productie is een server die 24/7 draait vereist, maar hebben we soortgelijke middelen nodig voor testen buiten werktijd? Dit hangt ook af van het type test dat we uitvoeren. Een voorbeeld kunnen belastings- of stresstests zijn, die we in niet-werktijd willen uitvoeren om de resultaten de volgende dag te krijgen. Maar, zeker, 24/7 serverbeschikbaarheid is niet vereist voor end-to-end automatiseringstests en zeker niet voor handmatige testomgevingen. Voor dergelijke situaties zou het goed zijn om precies het aantal middelen te ontvangen dat we op aanvraag nodig hebben, deze te gebruiken en te stoppen met betalen wanneer ze niet meer nodig zijn. Bovendien zou het geweldig zijn om ze onmiddellijk te ontvangen met een paar muisklikken of door een paar scripts uit te voeren. Dit is waar publieke cloud om de hoek komt kijken. Laten we eens kijken naar de definitie:
"De publieke cloud wordt gedefinieerd als computer diensten die door externe aanbieders via het openbare internet worden aangeboden, waardoor ze beschikbaar zijn voor iedereen die ze wil gebruiken of kopen. Ze kunnen gratis zijn of op aanvraag worden verkocht, waardoor klanten alleen betalen voor het verbruik van CPU-cycles, opslag of bandbreedte."
Er heerst de opvatting dat publieke clouds duur zijn. Maar het sleutelidee is het verlagen van de kosten voor bedrijven. Zoals eerder vermeld, stellen publieke clouds ons in staat om middelen op aanvraag te verkrijgen en alleen te betalen voor de tijd dat we deze gebruiken. Ook vergeten we soms dat medewerkers salaris ontvangen en dat specialisten ook een dure hulpbron zijn. Het is belangrijk om te overwegen dat publieke clouds de ondersteuning van infrastructuur aanzienlijk vergemakkelijken, waardoor ingenieurs zich kunnen concentreren op belangrijkere taken.
Waarde voor automatiseringsinfrastructuur
Welke specifieke middelen hebben we nodig voor end-to-end UI-tests? Dit zijn voornamelijk virtuele machines of clusters (we bespreken Kubernetes in de volgende sectie) voor het uitvoeren van browsers en emulators. Hoe meer browsers en emulators we gelijktijdig willen draaien, hoe meer CPU en geheugen we nodig hebben, en hoe meer kosten we daarvoor moeten betalen. Publieke cloudoplossingen in de context van geautomatiseerd testen stellen ons in staat om een groot aantal (100, 200, 1000 …) browsers/emulators op aanvraag uit te voeren, de testresultaten zo snel mogelijk te krijgen en te stoppen met het betalen voor zulke extreem resource-intensieve capaciteiten.
De meest populaire cloudproviders zijn Amazon Web Services (AWS), Microsoft Azure en Google Cloud Platform (GCP). In de praktische gids worden voorbeelden van GCP gepresenteerd, maar in het algemeen maakt het niet uit wat je precies gebruikt voor automatiseringstaken. Ze bieden allemaal ongeveer dezelfde functionaliteit. Gewoonlijk richt de gids zich op de gehele infrastructuur van het bedrijf en de bedrijfsvereisten, wat buiten het bereik van dit artikel valt. Voor automatiseringsingenieurs is het interessanter om het gebruik van cloudproviders te vergelijken met het gebruik van cloudplatforms specifiek voor testdoeleinden, zoals Sauce Labs, BrowserStack, BitBar, enzovoort. Laten we dat ook doen! Naar mijn mening is Sauce Labs de bekendste cloud-testfarm, dus heb ik deze gekozen voor vergelijking.
GCP versus Sauce Labs voor automatiseringsdoeleinden:
Stel je voor dat we tegelijkertijd 8 webtests en 8 Android-tests moeten uitvoeren. Hiervoor zullen we GCP gebruiken en 2 virtuele machines met Selenoid opzetten. Op de eerste zullen we 8 containers met browsers opzetten. Op de tweede 8 containers met emulators. Laten we naar de prijzen kijken:
Voor het draaien van één container met Chrome hebben we nodig n1-standard-1 machine. Voor Android is dat n1-standard-4 voor één emulator. In feite is een flexibeler en goedkoper alternatief het toewijzen van specifieke gebruikerswaarden voor CPU/geheugen, maar op dit moment is dat niet essentieel voor vergelijking met Sauce Labs.
Hier zijn de tarieven voor het gebruik van Sauce Labs:
Ik neem aan dat je al het verschil hebt opgemerkt, maar ik zal toch een tabel met berekeningen voor onze taak geven:
Benodigde middelen
Maandelijks
Werkuren(8 uur - 20 uur)
Werkuren+ Preemptible
GCP voor Web
n1-standard-1 x 8 = n1-standard-8
$194.18
23 dagen * 12u * 0.38 = 104.88$
23 dagen * 12u * 0.08 = 22.08$
Sauce Labs voor Web
Virtuele Cloud8 parallelle testen
$1.559
—
—
GCP voor Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 dagen * 12u * 1.52 = 419.52$
23 dagen * 12u * 0.32 = 88.32$
Sauce Labs voor Android
Echte Apparaat Cloud 8 parallelle testen
$1.999
—
—
Zoals je ziet, is het prijsverschil enorm, vooral als je testen alleen binnen het werkdag van twaalf uur uitvoert. Maar je kunt je uitgaven nog verder verlagen door gebruik te maken van preemptible machines. Wat zijn dat?
Een preemptible VM is een instantie die je kunt creëren en draaien voor een veel lagere prijs dan normale instanties. Echter, Compute Engine kan deze instanties beëindigen (preempt) als het toegang tot die middelen nodig heeft voor andere taken. Preemptible instanties zijn overtollige Compute Engine capaciteit, dus hun beschikbaarheid varieert met het gebruik.
Als je apps fouttolerant zijn en mogelijke instantie-preempties kunnen weerstaan, kunnen preemptible instanties je Compute Engine kosten aanzienlijk verlagen. Bijvoorbeeld, batchverwerkingsjobs kunnen op preemptible instanties draaien. Als sommige van die instanties tijdens de verwerking beëindigd worden, vertraagt de taak, maar stopt deze niet volledig. Preemptible instanties voltooien je batchverwerkingsopdrachten zonder extra belasting op je bestaande instanties en zonder dat je de volle prijs voor extra normale instanties hoeft te betalen.
En dit is nog niet het einde! In werkelijkheid ben ik er van overtuigd dat niemand testen 12 uur lang zonder pauze uitvoert. En als dat zo is, kun je virtuele machines automatisch starten en stoppen wanneer ze niet nodig zijn. De werkelijke gebruikstijd kan tot 6 uur per dag dalen. Dan daalt de betaling in het kader van onze taak tot maar liefst 11$ per maand voor 8 browsers. Is dat niet prachtig? Maar met preemptible machines moeten we voorzichtig zijn en bereid zijn voor onderbrekingen en instabiliteit, hoewel deze situaties softwarematig kunnen worden voorspeld en behandeld. Het is het waard!
Maar ik zeg zeker niet ‘gebruik nooit cloud test farms’. Ze hebben verschillende voordelen. Eerst en vooral is het niet zomaar een virtuele machine, maar een compleet oplossing voor testautomatisering met een scala aan functionaliteit uit de doos: externe toegang, logs, screenshots, videoregistratie, verschillende browsers en fysieke mobiele apparaten. In veel situaties kan dit een onmisbare alternatieve luxe zijn. Vooral testplatforms zijn nuttig voor IOS-automatisering, wanneer openbare clouds alleen Linux/Windows-systemen kunnen bieden. Maar het gesprek over IOS komt in de volgende artikelen. Ik raad aan altijd naar de situatie te kijken en je van de taken te laten leiden: in sommige gevallen is het goedkoper en efficiënter om publieke clouds te gebruiken, terwijl in andere situaties testplatforms zeker de investering waard zijn.
Illustratie van de huidige status van de infrastructuur
Links om te verkennen
Vergelijkbare 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 tools die Docker ondersteunen: Selenium grid en Selenoid. Bovendien gebruiken we virtuele machines die via GCP zijn gemaakt om containers met browsers en emulators te draaien. Om kosten te besparen, draaien we deze virtuele machines alleen op aanvraag en stoppen we ze wanneer er niet getest wordt. Is er nog iets dat onze infrastructuur kan verbeteren? Ja! Maak kennis met Kubernetes (K8s)!
Laten we eerst bekijken hoe de woorden orkestratie, cluster en Kubernetes met elkaar verbonden zijn. Op hoog niveau is orkestratie een systeem dat applicaties implementeert en beheert. Voor de automatisering van tests zijn de containeriseerbare applicaties Selenium grid en Selenoid. Docker en K8s vullen elkaar aan. De eerste wordt gebruikt voor het implementeren van applicaties, de tweede voor orkestratie. K8s zelf is een cluster. De taak van het cluster is om VMs als Nodes te gebruiken, wat het mogelijk maakt om verschillende functionaliteiten, programma's en diensten op één server (cluster) te installeren. Als een van de Nodes uitvalt, nemen andere Nodes het over, wat zorgt voor ononderbroken werking van onze applicatie. Daarnaast heeft K8s belangrijke functionaliteit met betrekking tot schaling, waardoor we automatisch het optimale aantal middelen krijgen op basis van de belasting en de ingestelde limieten.
Eerlijk gezegd is het handmatig opzetten van Kubernetes vanaf nul een vrij complexe taak. Ik laat een link achter naar de bekende praktische gids "Kubernetes The Hard Way", en als je geïnteresseerd bent, kun je zelf oefenen. Maar gelukkig zijn er alternatieve manieren en tools. De gemakkelijkste manier is het gebruik van Google Kubernetes Engine (GKE) in GCP, wat je in staat stelt om een werkende cluster met een paar klikken te verkrijgen. Voor de eerste stappen raad ik deze benadering aan, omdat het je in staat stelt om je te concentreren op het leren hoe je K8s voor je taken kunt gebruiken in plaats van te onderzoeken hoe de interne componenten met elkaar geïntegreerd moeten zijn.
Waarde voor automatiseringsinfrastructuur
Laten we eens kijken naar enkele belangrijke functies die K8s biedt:
- applicatie-implementatie: het gebruik van een multi-node cluster in plaats van VMs;
- dynamische schaling: vermindert de kosten van resources die alleen op aanvraag worden gebruikt;
- zelfherstel (Self-healing): automatische herstel van pods (waardoor ook de containers worden hersteld);
- rollout van updates en terugdraaien van wijzigingen zonder downtime: het updaten van tools, browsers en emulators onderbreekt de werking van bestaande gebruikers niet.
Maar K8s is nog steeds geen zilveren kogel. Om alle voordelen en beperkingen in de context van de tools die we bekijken (Selenium grid, Selenoid) te begrijpen, bespreken we kort de structuur van K8s. Een cluster bevat twee soorten nodes: Master Nodes en Worker Nodes. Master Nodes zijn verantwoordelijk voor het beheer, de implementatie en scheduling decisions. Worker Nodes zijn de plaatsen waar applicaties draaien. Nodes bevatten ook de container runtime-omgeving. In ons geval is dit Docker, dat verantwoordelijk is voor containergerelateerde operaties. Maar er zijn ook alternatieve oplossingen, zoals. Het is belangrijk te begrijpen dat schaling of zelfherstel niet direct op containers van toepassing is. Dit wordt gerealiseerd door het toevoegen/verkleinen van het aantal pods, die op hun beurt containers bevatten (meestal één container per pod, maar afhankelijk van de taak kan dat ook meer zijn). De hiërarchie op hoog niveau bestaat uit worker nodes, waarin pods zijn opgenomen, waarin containers zijn opgestart.
De schaalfunctie is cruciaal en kan zowel worden toegepast op nodes binnen een cluster node-pool als op pods binnen een node. Er zijn 2 soorten schaalvergroting, die zowel betrekking hebben op nodes als op pods. Het eerste type – horizontaal – is schaalvergroting door het aantal nodes/pods te verhogen. Dit type heeft de voorkeur. Het tweede type, zoals verwacht, is verticaal. Schaalvergroting gebeurt door de grootte van nodes/pods te vergroten in plaats van hun aantal.
Laten we nu onze hulpmiddelen bekijken in de context van de hierboven genoemde termen.
Selenium grid
Zoals eerder vermeld, is Selenium grid een zeer populaire tool, en het is geen verrassing dat het is контейнеризирован (containerised). Het is dan ook niet verwonderlijk dat Selenium grid kan worden uitgerold in K8s. Een voorbeeld van hoe dit te doen, is te vinden in de officiële K8s-repository. Zoals altijd voeg ik de links aan het einde van de sectie toe. Daarnaast laat de praktische handleiding zien hoe dit te doen met Terraform. Er is ook een instructie over hoe het aantal pods te schalen die containers met browsers bevatten. Maar de functie van automatische schaalvergroting in de context van K8s is nog steeds een niet helemaal voor de hand liggende taak. Toen ik begon met studeren, vond ik geen praktische handleiding of aanbevelingen. Na enkele onderzoeken en experimenten met steun van het DevOps-team, hebben we gekozen voor de aanpak om containers met de benodigde browsers binnen één pod te draaien, die zich binnen één worker node bevindt. Deze methode stelt ons in staat om een horizontale schaalstrategieën voor nodes toe te passen door hun aantal te verhogen. Ik hoop dat de situatie in de toekomst verandert en dat we steeds meer beschrijvingen van de beste aanpakken en kant-en-klare oplossingen zullen zien, vooral na de release van Selenium grid 4 met een gewijzigde interne architectuur.
Selenoid:
Momenteel is de uitrol van Selenoid in K8s de grootste teleurstelling. Ze zijn niet compatibel. Theoretisch gezien kunnen we een Selenoid-container binnen een pod draaien, maar wanneer Selenoid containers met browsers begint te starten, bevinden ze zich nog steeds binnen dezelfde pod. Dit maakt schaling onmogelijk en als gevolg hiervan zal de werking van Selenoid binnen een cluster niet verschillen van de werking binnen een virtuele machine. Einde verhaal.
Moon:
Wetende dit knelpunt bij het gebruik van Selenoid, hebben ontwikkelaars een krachtiger hulpmiddel uitgebracht dat ze Moon noemden. Dit hulpmiddel was oorspronkelijk bedoeld voor gebruik met Kubernetes en als resultaat kan en moet de autoscaling-functie worden gebruikt. Bovendien zou ik zeggen dat dit op dit moment het enige hulpmiddel in de wereld van Selenium is dat out-of-the-box native K8s-clusterondersteuning heeft (niet meer, zie het volgende hulpmiddel ). De belangrijkste eigenschap van Moon die deze ondersteuning biedt, is:
Volledig stateless. Selenoid slaat informatie over momenteel actieve browsersessies in het geheugen op. Als om de een of andere reden zijn proces crasht, gaan alle actieve sessies verloren. Moon daarentegen heeft geen interne status en kan worden gerepliceerd over datacenters. Browsersessies blijven bestaan, zelfs als een of meerdere replicas uitvallen.
Dus, Moon is een geweldig oplossing, maar met één probleem: het is niet gratis. De prijs hangt af van het aantal sessies. Gratis kun je slechts 0-4 sessies draaien, wat niet erg nuttig is. Maar vanaf de vijfde sessie moet je $5 per sessie betalen. De situatie kan per bedrijf verschillen, maar in ons geval is het gebruik van Moon zinloos. Zoals ik eerder beschreef, kunnen we VM's met Selenium Grid op aanvraag opstarten of het aantal nodes in het cluster vergroten. Ongeveer voor één pipeline starten we 500 browsers en stoppen we alle bronnen na de tests. Als we Moon zouden gebruiken, zouden we extra $500 x 5 = $2500 per maand moeten betalen, ongeacht hoe vaak we tests draaien. En nogmaals, ik zeg niet 'gebruik Moon niet'. Voor jouw taken kan dit een onmisbare oplossing zijn, bijvoorbeeld als je in je organisatie veel projecten/teams hebt en je een enorm gezamenlijk cluster voor iedereen nodig hebt. Zoals altijd laat ik een link aan het eind en raad ik aan om alle noodzakelijke berekeningen in de context van jouw taak te maken.
Callisto: (Let op! Dit staat niet in het originele artikel en is alleen te vinden in de Russische vertaling.)
Zoals ik al zei, Selenium is een zeer populaire tool en de IT-sector ontwikkelt zich razendsnel. Terwijl ik aan de vertaling werkte, verscheen er een nieuwe veelbelovende tool Callisto (hallo Cypress en andere concurrenten van Selenium). Het werkt native met K8s en stelt je in staat om Selenoid-containers in pods te draaien, verdeeld over Nodes. Alles werkt meteen uit de doos, inclusief autoschaling. Fantastisch, maar het moet getest worden. Ik heb deze tool al kunnen opzetten en enkele experimenten uitgevoerd. Maar het is nog te vroeg om conclusies te trekken; na het verkrijgen van resultaten op de lange termijn, zal ik wellicht een review schrijven in latere artikelen. Voor nu laat ik alleen links voor zelfstandig onderzoek.
Illustratie van de huidige status van de infrastructuur
Links om te verkennen
Links om te verkennen
Vergelijkbare tools
7. Infrastructuur als code (IaC)
Korte beschrijving van de technologie
En zo zijn we aangekomen bij het laatste hoofdstuk. Gewoonlijk vallen deze technologie en de bijbehorende taken niet onder de verantwoordelijkheden van automatiseringsingenieurs. En daar zijn redenen voor. Ten eerste worden infrastructuurkwesties in veel organisaties onder controle gehouden door de DevOps-afdeling en maakt het development-team zich niet al te druk over wat de pipeline aandrijft en hoe alles moet worden onderhouden wat ermee verbonden is. Ten tweede, laten we eerlijk zijn, de praktijk van "Infrastructuur als code (IaC)" wordt nog steeds niet toegepast in veel bedrijven. Maar het is zeker een populaire trend geworden en het is belangrijk om betrokken te zijn bij de bijbehorende processen, benaderingen en tools. Of, op zijn minst, op de hoogte te blijven van de ontwikkelingen.
Laten we beginnen met de motivatie voor het gebruik van deze aanpak. We hebben al besproken dat we voor het uitvoeren van tests in GitlabCI minimaal de middelen nodig hebben om de Gitlab Runner te starten. Om containers met browsers/emulators te starten, moeten we VM's of een cluster reserveren. Naast de testmiddelen hebben we ook aanzienlijke rekenkracht nodig om de ontwikkel-, staging- en productieomgevingen te onderhouden, wat ook databases, automatische schema's, netwerconfiguraties, een load balancer, gebruikersrechten en meer omvat. Het belangrijkste probleem is de benodigde inspanning om dit alles te ondersteunen. Er zijn verschillende manieren waarop we wijzigingen kunnen aanbrengen en updates kunnen uitrollen. Bijvoorbeeld, in de context van GCP kunnen we de UI-console in de browser gebruiken en alle acties uitvoeren door op knoppen te klikken. Een alternatieve methode kan het gebruik van API-aanroepen zijn om met cloudentiteiten te communiceren of het toepassen van de gcloud-opdrachtregeltool om de benodigde bewerkingen uit te voeren. Maar met een werkelijk groot aantal verschillende entiteiten en infrastructuurelementen wordt het moeilijk of zelfs onmogelijk om alle operaties handmatig uit te voeren. Bovendien zijn al deze handmatige acties oncontroleerbaar. We kunnen ze niet ter review indienen voordat ze worden uitgevoerd, we kunnen geen versiebeheersysteem gebruiken en snel wijzigingen terugdraaien die geleid hebben tot een incident. Om dergelijke problemen op te lossen, hebben ingenieurs automatische bash/shell-scripts ontwikkeld en blijven ze dat doen, wat niet veel beter is dan de vorige methoden, aangezien het niet zo eenvoudig is om ze snel te lezen, te begrijpen, te onderhouden en aan te passen in procedurele stijl.
In dit artikel en praktijkgids gebruik ik 2 tools die betrekking hebben op de IaC-praktijk. Dit zijn Terraform en Ansible. Sommigen denken dat het geen zin heeft om ze tegelijkertijd te gebruiken, omdat hun functionaliteit vergelijkbaar is en ze onderling vervangbaar zijn. Maar het punt is dat ze aanvankelijk heel verschillende taken hebben. Het feit dat deze tools elkaar aanvullen, werd bevestigd tijdens een gezamenlijke presentatie door ontwikkelaars van HashiCorp en RedHat. Het conceptuele verschil is dat Terraform een provisioning-tool is voor het beheren van servers. Terwijl Ansible een configuratiebeheertool is, wiens taak het is om software op deze servers te installeren, configureren en beheren.
Een ander belangrijk onderscheidend kenmerk van deze tools is de stijl van het schrijven van code. In tegenstelling tot bash en Ansible gebruikt Terraform een declaratieve stijl, gebaseerd op de beschrijving van de gewenste eindtoestand die moet worden bereikt na uitvoering. Bijvoorbeeld, als we van plan zijn om 10 VMs te creëren en wijzigingen via Terraform toe te passen, krijgen we 10 VMs. Als we het script nogmaals uitvoeren, gebeurt er niets, omdat we al 10 VMs hebben, en Terraform weet hiervan, omdat het de huidige staat van de infrastructuur in het state-bestand opslaat. Ansible gebruikt daarentegen een procedurele aanpak en als we het vragen om 10 VMs te creëren, krijgen we bij de eerste uitvoering 10 VMs, net als bij Terraform. Maar na een tweede uitvoering hebben we al 20 VMs. Dit is het belangrijkste verschil. In de procedurele stijl slaan we de huidige staat niet op en beschrijven we gewoon de volgorde van stappen die moeten worden uitgevoerd. Uiteraard kunnen we verschillende situaties behandelen en enkele controles toevoegen om te controleren op de aanwezigheid van middelen en de huidige staat, maar het is niet zinvol om onze tijd te besteden aan het beheren van deze logica. Bovendien vergroot het de kans op fouten.
Samenvattend kan worden geconcludeerd dat Terraform met declaratieve notatie de geschiktere tool is voor het provisionen van servers. Het beheer van configuraties kan beter aan Ansible worden gedelegeerd. Laten we, nadat we dit hebben begrepen, naar voorbeelden van gebruik kijken in de context van automatisering.
Waarde voor automatiseringsinfrastructuur
Het is belangrijk om te begrijpen dat de infrastructuur voor testautomatisering moet worden beschouwd als een deel van de gehele infrastructuur van het bedrijf. Dit betekent dat alle IaC-praktijken wereldwijd moeten worden toegepast op de middelen van de hele organisatie. Wie daarvoor verantwoordelijk is, hangt af van uw processen. Het DevOps-team heeft meer ervaring met deze zaken en ziet het volledige plaatje. QA-engineers zijn echter sterker betrokken bij het bouwproces van automatisering en de structuur van de pipeline, wat hen in staat stelt om beter de benodigde wijzigingen en mogelijkheden voor verbetering te zien. De beste optie is om samen te werken, kennis en ideeën uit te wisselen om het gewenste resultaat te bereiken.
Hier zijn enkele voorbeelden van het gebruik van Terraform en Ansible in de context van testautomatisering en de tools die we eerder hebben besproken:
1. Beschrijf via Terraform de noodzakelijke kenmerken en parameters van VMs en clusters.
2. Installeer met Ansible de noodzakelijke testtools: docker, Selenoid, Selenium Grid en laad de benodigde versies van browsers/emulators.
3. Beschrijf via Terraform de kenmerken van de VM waarop GitLab Runner zal worden uitgevoerd.
4. Installeer met Ansible GitLab Runner en de benodigde ondersteunende tools, stel de instellingen en configuraties in.
Illustratie van de huidige status van de infrastructuur
Links om te bestuderen:
Vergelijkbare tools
Laten we samenvatten!
Stap
Technologie
Tools
Waarde voor automatiseringsinfrastructuur
1
Lokale uitvoering
Node.js, Selenium, Appium
- De meest populaire tools voor web en mobiel
- Ondersteuning voor meerdere talen en platforms (inclusief Node.js)
2
Versiebeheersystemen
Git
- Vergelijkbare voordelen met ontwikkelingscode
3
Containerisatie
Docker, Selenium-grid, Selenoid (Web, Android)
- Parallel testen
- Geïsoleerde omgevingen
- Eenvoudige, flexibele versie-updates
- Dynamisch stoppen van ongebruikte middelen
- Makkelijk in te stellen
4
CI / CD
Gitlab CI
- Tests zijn onderdeel van de pipeline
- Snelle feedback
- Zichtbaarheid voor het hele bedrijf/team
5
Cloudplatforms
Google Cloud Platform
- Middelen op aanvraag (betalen alleen wanneer nodig)
- Gemakkelijk te beheren en bij te werken
- Zichtbaarheid en controle over alle middelen
6
Orkestratie
Kubernetes
In de context van containers met browsers/emulators binnen pods:
- Schaalbaarheid / autoschaling
- Zelfherstellend
- Updates en terugrollingen zonder onderbrekingen
7
Infrastructure as Code (IaC)
Terraform, Ansible
- Vergelijkbare voordelen met ontwikkelingsinfrastructuur
- Alle voordelen van versiebeheer van code
- Eenvoudige wijzigingen en onderhoud
- Volledig geautomatiseerd
Mindmap-diagrammen: evolutie van infrastructuur
stap1: Lokaal
stap2: VCS
stap3: Containerisatie
stap4: CI/CD
stap5: Cloudplatforms
stap6: Orkestratie
stap7: IaC
Wat nu?
Dus, dit is het einde van het artikel. Maar in conclusie wil ik graag enkele afspraken met u maken.
Van uw kant
Zoals in het begin is gezegd, wil ik dat het artikel praktische voordelen biedt en u helpt de opgedane kennis in de praktijk toe te passen. Ik voeg nogmaals.
Maar stop daar niet, blijf oefenen, bestudeer de relevante links en boeken, leer hoe dit werkt in uw bedrijf, vind plekken die verbeterd kunnen worden en neem deel aan dit proces. Veel succes!
Van mijn kant
Uit de titel blijkt dat dit pas het eerste deel was. Hoewel het vrij omvangrijk is geworden, zijn er nog steeds belangrijke onderwerpen niet behandeld. In deel twee ben ik van plan om de automatiseringsinfrastructuur in de context van iOS te bespreken. Vanwege Apple's beperkingen met betrekking tot het draaien van iOS-simulaties alleen op macOS-systemen, is onze set oplossingen beperkt. Bijvoorbeeld, we zijn niet in staat om Docker te gebruiken voor het draaien van de simulator of publieke clouds voor het draaien van virtuele machines. Maar dat betekent niet dat er geen andere alternatieven zijn. Ik zal proberen u op de hoogte te houden van de nieuwste oplossingen en moderne tools!
Ook heb ik enkele grote onderwerpen met betrekking tot monitoring niet genoemd. In gedeelte 3 ben ik van plan om de meest populaire tools voor infrastructuurmonitoring te bespreken, evenals welke gegevens en metrics in overweging genomen moeten worden.
En ten slotte. In de toekomst ben ik van plan een videocursus te publiceren over het opzetten van testinfrastructuur en populaire tools. Op dit moment zijn er op het internet veel cursussen en lezingen over DevOps, maar al het materiaal is gepresenteerd in de context van ontwikkeling, niet van testautomatisering. Ik heb veel feedback nodig over de vraag of zo'n cursus interessant en waardevol zou zijn voor de test- en automatiseringsgemeenschap. Alvast bedankt!
Bron: habr.com
