Část 1: Web / Android
Poznámka: tento článek je překlad originálního článku do ruštiny Všechny ilustrace, odkazy, citace a termíny jsou však zachovány v původním jazyce, aby se předešlo zkreslení významu při překladu do ruštiny. Přeji vám příjemné studium!
V současnosti je specializace DevOps jednou z nejžádanějších v IT průmyslu. Pokud navštívíte populární pracovní portály a nastavíte filtr podle mezd, uvidíte, že pracovní nabídky související s DevOps se nacházejí na začátku seznamu. Je však důležité pochopit, že se to většinou týká pozice 'Senior', což znamená, že kandidát má vysokou úroveň dovedností a znalostí technologií a nástrojů. S tím se pojí také vysoká míra odpovědnosti za bezproblémový chod produkce. Zapomněli jsme však, co DevOps vlastně je. Původně to nebyl konkrétní člověk nebo oddělení. Pokud budeme hledat definice tohoto termínu, najdeme mnoho krásných a správných podstatných jmen, jako jsou metodologie, praxe, kulturní filozofie, skupina konceptů a tak dále.
Moje specializace - inženýr pro automatizaci testování (QA automation engineer), ale domnívám se, že by neměla být spojena pouze s psaním automatizovaných testů nebo vývojem architektury testovacího frameworku. V roce 2020 jsou znalosti infrastruktury automatizace také nezbytné. To umožňuje uspořádat proces automatizace samostatně, počínaje spouštěním testů a konče poskytováním výsledků všem zainteresovaným stranám v souladu s cíli. Výsledkem jsou dovednosti DevOps, které jsou nezbytným faktorem pro vykonávání této práce. A to je všechno hezké, ale bohužel existuje problém (spoilery: tento článek se snaží tento problém zjednodušit). Spočívá v tom, že DevOps je složité. A to je zřejmé, neboť firmy nebudou platit hodně za něco, co se dá snadno udělat… Ve světě DevOps existuje mnoho nástrojů, termínů a praktik, které je třeba zvládnout. Zejména na začátku kariéry je to obtížné a závisí to na nasbíraných technických zkušenostech.
Zdroj:
Tady bychom asi měli zakončit s úvodní částí a soustředit se na cíle tohoto článku.
O čem je tento článek
V tomto článku se chci podělit o své zkušenosti s budováním infrastruktury pro automatizaci testování. Na internetu lze najít mnoho zdrojů informací o různých nástrojích a jejich použití, ale rád bych je posoudil výhradně z pohledu automatizace. Předpokládám, že mnoha inženýrům automatizace je známá situace, kdy testy, které jste vytvořili, nikdo kromě vás nespouští a nezajímá se o jejich údržbu. V důsledku toho se testy stávají zastaralými a je nutné věnovat čas jejich aktualizaci. Opět, na začátku kariéry může být takový úkol docela složitý: správně se rozhodnout, které nástroje by měly pomoci vyřešit tento problém, jak je vybrat, nastavit a udržovat. Někteří testovači se obracejí na DevOps (lidi) a, buďme upřímní, takový přístup funguje. V mnoha případech to může být jediné řešení, protože nám chybí přehled o všech závislostech. Jak víme, DevOps jsou velmi zaměstnaní lidé, protože se musí starat o infrastrukturu celé firmy, nasazení, monitorování, mikroservisy a další podobné úkoly podle organizace/týmu. Jak to bývá, automatizace není na prvním místě. V takovém případě bychom se měli snažit udělat vše, co je v našich silách od začátku do konce. To sníží závislosti, urychlí pracovní proces, zlepší naše dovednosti a umožní nám vidět širší obraz toho, co se děje.
V článku jsou uvedeny nejžádanější a nejoblíbenější nástroje a ukázáno, jak je použít k postupnému budování infrastruktury automatizace. Každá skupina je představena nástroji, které byly ověřeny na osobní zkušenosti. Ale to neznamená, že musíte používat totéž. Samotné nástroje nejsou důležité, objevují se a zastarávají. Naším inženýrským úkolem je pochopení základních principů: proč potřebujeme tuto skupinu nástrojů a jaké pracovní úkoly můžeme s jejich pomocí vyřešit. Proto na konci každé sekce zanechávám odkazy na podobné nástroje, které se možná používají ve vaší organizaci.
Co v tomto článku není
Ještě jednou opakuji, že článek není o konkrétních nástrojích, proto zde nebudou žádné úryvky kódu z dokumentace a popisy konkrétních příkazů. Na konci každé sekce však ponechávám odkazy pro podrobné studium.
To bylo uděláno z důvodu, že:
- tento materiál je velmi snadno dostupný v různých zdrojích (dokumentace, knihy, videokurzy);
- pokud se do toho ponoříme, budeme muset napsat 10, 20, 30 částí tohoto článku (zatímco plánujeme 2-3);
- jednoduše nechci plýtvat vaším časem, protože možná chcete použít jiné nástroje k dosažení stejných cílů.
Praxe
Rád bych, aby byl tento materiál užitečný pro každého čtenáře, a ne jen přečtený a zapomenutý. Při každém studiu je praxe velmi důležitým prvkem. Proto jsem připravil. Také vás čeká domácí úkol, abyste si byli jisti, že jste bezmyšlenkovitě nekopírovali řádky vykonávaných příkazů
Plán
Krok
Technologie
Nástroje
1
Lokální spuštění (příprava webových / android demo testů a jejich spuštění místně)
Node.js, Selenium, Appium
2
Systémy správy verzí
Git
3
Kontejnerizace
Docker, Selenium grid, Selenoid (Web, Android)
4
CI / CD
Gitlab CI
5
Cloudové platformy
Google Cloud Platform
6
Orchestrace
Kubernetes
7
Infrastruktura jako kód (IaC)
Terraform, Ansible
Struktura každé sekce
Abychom udrželi vyprávění vizuálně přehledné, každá sekce je popsána podle následujícího plánu:
- krátký popis technologie,
- hodnota pro automatizaci infrastruktury,
- ilustrace aktuálního stavu infrastruktury,
- odkazy k studiu,
- podobné nástroje.
1. Lokální spuštění testů
Krátký popis technologie
To je pouze přípravný krok pro spuštění demonstračních testů místně a pro ověření, že úspěšně probíhají. V praktické části se používá Node.js, ale programovací jazyk a platforma nejsou také důležité a můžete použít ty, které se používají ve vaší společnosti.
Jako automatizační nástroje však doporučuji používat Selenium WebDriver pro webové platformy a Appium pro platformu Android, protože v dalších krocích budeme používat Docker obrazy, které jsou speciálně navrženy pro práci s těmito nástroji. Kromě toho, jak ukazují požadavky v pracovních inzerátech, jsou tyto nástroje na trhu nejžádanější.
Jak jste si mohli všimnout, zaměřujeme se pouze na webové a Android testy. Bohužel IOS je zcela jiný příběh (děkujeme Apple). Plánuji ukázat řešení a praktiky související s IOS v dalších částech.
Hodnota pro automatizační infrastrukturu
Z pohledu infrastruktury nemá lokální spuštění žádnou hodnotu. Pouze ověřujete, že testy fungují na lokálním stroji v lokálních prohlížečích a simulátorech. Každopádně je to však potřebný výchozí bod.
Ilustrace aktuálního stavu infrastruktury
Odkazy pro studium
Podobné nástroje
- jakýkoli programovací jazyk, který máte rádi, v kombinaci se Selenium/Appium – testy;
- jakékoli testy;
- jakýkoli testovací běžec.
2. Systémy verzování (Git)
Krátký popis technologie
Pro nikoho nebude velkým překvapením, když řeknu, že systém verzování je nesmírně důležitou součástí vývoje jak v týmu, tak individuálně. Na základě různých zdrojů můžeme s jistotou říci, že Git je nejpopulárnější reprezentant. Systém verzování poskytuje mnoho výhod, jako je sdílení kódu, ukládání verzí, obnovení do předchozích větví, sledování historie projektu, zálohování. Nebudeme diskutovat o každém bodě podrobně, protože jsem si jistý, že s tímto jste dobře obeznámeni a používáte to v každodenní práci. Ale pokud ne, doporučuji pozastavit čtení tohoto článku a co nejdříve tento nedostatek dohnat.
Hodnota pro automatizační infrastrukturu
A zde se můžete zeptat: „Proč nám vypráví o Gitu? To všichni znají a používají jak pro kódování, tak pro automatizované testy.“ Budete naprosto v právu, ale v tomto článku hovoříme o infrastruktuře a tato sekce hraje roli úvodu k sekci 7: „Infrastruktura jako kód (IaC)“. Pro nás to znamená, že celá infrastruktura, včetně testovací, je popsána jako kód, a proto na ni můžeme také aplikovat systémy verzování a získat podobné výhody jako pro vývojový a automatizační kód.
Podíváme se na IaC podrobněji v kroku 7, ale už nyní můžete začít používat Git lokálně tím, že vytvoříte místní repozitář. Celkový obraz se rozšíří, když přidáme k infrastruktuře vzdálený repozitář.
Ilustrace aktuálního stavu infrastruktury
Odkazy pro studium
Podobné nástroje
3. Kontejnery (Docker)
Krátký popis technologie
Abychom ukázali, jak kontejnery změnily pravidla hry, vraťme se o několik desetiletí zpět. V té době lidé nakupovali a používali serverové stroje pro spuštění aplikací. V mnoha případech však nebyly předem známy potřebné zdroje pro spuštění. To vedlo k tomu, že společnosti utrácely peníze za nákup drahých výkonných serverů, ale část těchto zdrojů nebyla plně využita.
Dalším stupněm evoluce byly virtuální stroje (VM), které vyřešily problém utrácení peněz za nevyužívané zdroje. Tato technologie umožnila spouštět aplikace nezávisle na sobě uvnitř jednoho serveru a přidělovala zcela izolovaný prostor. Bohužel však každá technologie má své nevýhody. Spuštění VM vyžaduje plnohodnotný operační systém, který spotřebovává CPU, RAM, úložiště a v závislosti na OS je nutné zvážit náklady na licenci. Tyto faktory ovlivňují rychlost spuštění a komplikují přenositelnost.
A tak jsme se dostali ke kontejnerizaci. Znovu tato technologie vyřešila předchozí problém, protože kontejnery nevyžadují plnohodnotný OS, což uvolňuje značné množství zdrojů a poskytuje rychlé a flexibilní řešení pro přenositelnost.
Samozřejmě, technologie kontejnerizace není nic nového a poprvé byla představena na konci 70. let. V té době bylo provedeno mnoho výzkumů, prací a pokusů. Ale právě Docker tuto technologii přizpůsobil a učinil ji snadno dostupnou pro masy. V dnešní době, když mluvíme o kontejneru, většinou máme na mysli Docker. Když hovoříme o Docker kontejnerech, máme na mysli Linux kontejnery. Můžeme použít Windows a macOS systémy pro spuštění kontejnerů, ale je důležité pochopit, že v takovém případě vzniká další vrstva. Například, Docker na Macu tiše spouští kontejnery uvnitř lehkého Linux VM. K tomuto tématu se ještě vrátíme, když budeme diskutovat o spuštění emulátorů Androidu uvnitř kontejnerů, protože zde vzniká velmi důležitý nuance, kterou je třeba podrobněji prozkoumat.
Hodnota pro automatizační infrastrukturu
Zjistili jsme, že kontejnerizace a Docker jsou skvělé. Podívejme se na to v kontextu automatizace, neboť každý nástroj nebo technologie by měly vyřešit nějaký problém. Pojďme stanovit zřejmé problémy automatizace testování v kontextu UI testů:
- obrovské množství závislostí při instalaci Selenium a zejména Appium;
- problémy s kompatibilitou mezi verzemi prohlížečů, simulátorů a ovladačů;
- absence izolovaného prostoru pro prohlížeče/simulátory, což je zvláště kritické pro paralelní spuštění;
- těžké na správu a údržbu, pokud je třeba současně spustit 10, 50, 100 nebo dokonce 1000 prohlížečů.
Ale protože Selenium je nejpopulárnějším nástrojem automatizace a Docker je nejpopulárnějším nástrojem kontejnerizace, nemělo by nikoho překvapit, že se někdo pokusil je spojit, aby získal mocný nástroj pro řešení výše zmíněných problémů. Pojďme se na taková řešení podívat podrobněji.
Selenium grid v Dockeru
Tento nástroj je nejpopulárnější na světě Selenium pro spuštění několika prohlížečů na několika strojích a jejich správu z centrálního uzlu. K jeho spuštění je potřeba registrovat alespoň 2 části: Hub a Node(y). Hub je centrální uzel, který přijímá všechny požadavky od testů a rozděluje je mezi odpovídající Nodes. Pro každý Node můžeme nastavit konkrétní konfiguraci, například zadáním požadovaného prohlížeče a jeho verze. Nicméně, stále se musíme postarat o kompatibilní ovladače pro prohlížeče a nainstalovat je na příslušné Nodes. Z tohoto důvodu se Selenium grid běžně nepoužívá v čisté podobě, s výjimkou případů, kdy potřebujeme pracovat s prohlížeči, které nelze nainstalovat na Linux OS. Pro všechny ostatní případy bude mnohem flexibilnějším a správným řešením využití Docker obrazů pro spuštění Selenium grid Hub a Nodes. Tento přístup velmi usnadňuje správu uzlů, protože můžeme vybrat požadovaný obraz s již nainstalovanými kompatibilními verzemi prohlížečů a ovladačů.
I přes negativní zpětnou vazbu o stabilitě práce, zejména při spuštění velkého počtu Nodes paralelně, zůstává Selenium grid stále nejpopulárnějším nástrojem pro paralelní spuštění Selenium testů. Je důležité poznamenat, že v open-source neustále vznikají různé opravy a modifikace tohoto nástroje, které se snaží eliminovat různá úzká místa.
Selenoid pro Web
Tento nástroj je revolucí ve světě Selenium, protože funguje okamžitě a značně usnadnil život mnoha automatizačním inženýrům. Především se nejedná o další modifikaci Selenium grid. Místo toho vývojáři vytvořili zcela novou verzi Selenium Hub v jazyce Golang, což spolu s lehkými Docker obrazy pro různé prohlížeče posunulo automatizaci testování kupředu. Navíc v případě Selenium Grid musíme předem určit všechny požadované prohlížeče a jejich verze, což není problém, když pracujeme pouze s jedním prohlížečem. Ale když jde o více podporovaných prohlížečů, Selenoid je řešení číslo jedna díky funkci 'prohlížeč na požádání'. Všechno, co potřebujeme, je předem stáhnout potřebné obrazy s prohlížeči a aktualizovat konfigurační soubor, se kterým Selenoid interaguje. Jakmile Selenoid obdrží požadavek od testů, automaticky spustí potřebný kontejner s požadovaným prohlížečem. Když test skončí, Selenoid zastaví kontejner, čímž uvolní zdroje pro další požadavky. Tento přístup zcela odstraňuje známý problém 'degradace uzlů', se kterým se často setkáváme v Selenium grid.
Ale, bohužel, Selenoid stále není stříbrná kulka. Získali jsme funkci 'prohlížeč na požádání', ale funkce 'zdroje na požádání' stále není k dispozici. Pro použití Selenoidu ho musíme nasadit na fyzickém hardwaru nebo na VM, což znamená, že musíme předem vědět, kolik zdrojů je třeba přidělit. Myslím, že to není problém pro malé projekty, které spouští 10, 20 nebo dokonce 30 prohlížečů současně. Ale co když potřebujeme 100, 500, 1000 a více? Není vůbec smysluplné neustále udržovat a platit za takové množství zdrojů. V sekcích 5 a 6 tohoto článku probereme řešení, která umožňují škálování, čímž značně snižují náklady společnosti.
Selenoid pro Android
Po úspěchu Selenoid jako nástroje pro webovou automatizaci lidé toužili po něčem podobném pro Android. A to se splnilo – Selenoid byl vydán s podporou Androidu. Z pohledu uživatele je princip fungování podobný webové automatizaci. Jediný rozdíl spočívá v tom, že místo kontejnerů s prohlížeči Selenoid spouští kontejnery s Android emulátory. Podle mého názoru je to v současnosti nejsilnější bezplatný nástroj pro spuštění Android testů paralelně.
O negativních stránkách tohoto nástroje bych opravdu nerad mluvil, protože se mi skutečně velmi líbí. Přesto se tu vyskytují stejné nedostatky, které se týkají i webové automatizace, související se škálovatelností. Kromě toho je třeba se zmínit o dalším omezení, které může být překvapením, pokud tento nástroj nastavujete poprvé. Pro spuštění Android obrazů potřebujeme fyzický stroj nebo VM s podporou vnořené virtualizace. V praktickém průvodci ukážu, jak to aktivovat na Linux VM. Pokud jste však uživatel macOS a chcete Selenoid nasadit lokálně, spuštění Android testů nebude možné. Můžete však vždy spustit Linux VM lokálně s nastavenou ‚vnořenou virtualizací‘ a nasadit Selenoid uvnitř.
Ilustrace aktuálního stavu infrastruktury
V kontextu tohoto článku přidáme 2 nástroje k ilustraci infrastruktury. Tím je Selenium grid pro webové testy a Selenoid pro Android testy. V průvodci na GitHubu také ukážu, jak použít Selenoid pro spuštění webových testů.
Odkazy pro studium
Podobné nástroje
- Existují i jiné nástroje pro kontejnerizaci, ale Docker je nejpopulárnější. Pokud chcete vyzkoušet něco jiného, mějte na paměti, že nástroje, které jsme probrali pro paralelní spuštění Selenium testů, nebudou fungovat ihned.
- Jak již bylo zmíněno, existuje mnoho modifikací Selenium grid, například,.
4. CI / CD
Krátký popis technologie
Praktika neustálé integrace je v oblasti vývoje poměrně populární a stojí na stejné úrovni jako systémy pro správu verzí. Přesto mám pocit, že existuje zmatek v terminologii. V tomto odstavci bych chtěl popsat 3 modifikace této technologie z mého pohledu. Na internetu můžete najít mnoho článků s různými interpretacemi, a to je naprosto normální, pokud se váš názor liší. Nejhlavnější je, abyste byli na stejné vlně se svými kolegy.
Existují tedy 3 termíny: CI — Continuous Integration (neustálá integrace), CD — Continuous Delivery (neustálá dodávka) a znovu CD — Continuous Deployment (neustálé nasazení). (Dále budu používat tyto termíny v anglickém jazyce). Každá modifikace přidává několik dalších kroků do vašeho vývojového procesu. Ale slovo continuous (neustálá) je nejdůležitější. V tomto kontextu máme na mysli něco, co probíhá od začátku do konce, bez přerušení nebo manuální intervence. Podívejme se na CI & CD a CD v tomto kontextu.
- Continuous Integration – je počáteční krok evoluce. Po odeslání nového kódu na server očekáváme rychlou zpětnou vazbu, že naše změny jsou v pořádku. Obvykle CI zahrnuje spuštění nástrojů pro statickou analýzu kódu a modulové/vnitřní API testy. To nám umožňuje získat informace o našem kódu již za několik sekund/minut.
- Continuous Delivery je pokročilejší krok, na kterém spouštíme integrační/UI testy. Na této úrovni však nezískáváme výsledky tak rychle jako v případě CI. Zaprvé, tyto typy testů vyžadují více času na dokončení. Zadruhé, před spuštěním musíme rozvinout naše změny na testovací/staging prostředí. Navíc, pokud mluvíme o mobilním vývoji, přibývá další fáze na vytváření sestavení naší aplikace.
- Continuous Deployment předpokládá, že automaticky nasazujeme (release) naše změny na produkci, pokud byly úspěšně splněny všechny akceptační testy v předchozích fázích. Kromě toho lze po fázi uvolnění nastavit různé kroky, jako je spuštění smoke testů na produkci a shromažďování zajímavých metrik. Continuous Deployment je možné pouze při dobrém pokrytí automatizovanými testy. Pokud jsou potřeba nějaké ruční zásahy, včetně testování, pak to již není Continuous (nepřetržité). Tak můžeme říct, že náš pipeline splňuje pouze praxi Continuous Delivery.
Hodnota pro automatizační infrastrukturu
V této části bych měl objasnit, že když mluvíme o end-to-end UI testech, znamená to, že musíme nasadit naše změny a související služby na testovací prostředí. Continuous Integration není pro tento úkol vhodný a musíme se postarat o implementaci alespoň praxí Continuous Delivery. Continuous Deployment také dává smysl v kontextu UI testů, pokud máme v úmyslu je spouštět na produkci.
A než se podíváme na ilustraci změny architektury, chci říct několik slov o GitLab CI. Na rozdíl od jiných CI/CD nástrojů, GitLab poskytuje vzdálené úložiště a mnoho dalších doplňkových funkcí. Takže GitLab je víc než jen CI. Obsahuje řízení zdrojového kódu, Agile management, CI/CD pipelines, nástroje pro logování a shromažďování metrik. Architektura GitLab se skládá z GitLab CI/CD a GitLab Runner. Přináším krátký popis z oficiálního webu:
Gitlab CI/CD je webová aplikace s API, která ukládá svůj stav v databázi, spravuje projekty/buildy a poskytuje uživatelské rozhraní. GitLab Runner je aplikace, která zpracovává buildy. Může být nasazen samostatně a pracuje s GitLab CI/CD prostřednictvím API. Pro běh testů potřebujete jak instanci Gitlabu, tak Runner.
Ilustrace aktuálního stavu infrastruktury
Odkazy pro studium
Podobné nástroje
- A mnoho dalších
5. Cloudové platformy
Krátký popis technologie
V této části se budeme bavit o populárním trendu, který se nazývá 'veřejné cloudování'. I když technologie virtualizace a kontejnerizace nabízejí obrovské výhody, stále potřebujeme výpočetní zdroje. Firmy nakupují drahé servery nebo si pronajímají datová centra, ale v takovém případě je potřeba udělat výpočty (někdy nerealistické) o tom, kolik zdrojů budeme potřebovat, zda je budeme používat 24/7 a k jakým účelům. Například pro produkční prostředí potřebujeme server, který bude fungovat nonstop, ale potřebujeme stejné zdroje pro testování mimo pracovní dobu? To také závisí na typu prováděného testování. Příkladem mohou být zátěžové/stresové testy, které plánujeme provádět mimo pracovní hodiny, abychom získali výsledky na následující den. Ale rozhodně není nutná nepřetržitá dostupnost serverů pro end-to-end automatizované testy a obzvláště pro prostředí manuálního testování. Pro takové situace by bylo skvělé mít k dispozici tolik zdrojů, kolik potřebujeme na vyžádání, používat je a přestat platit, když už nejsou potřeba. Navíc by bylo skvělé získat je okamžitě, pouhým kliknutím myší nebo spuštěním několika skriptů. K tomu slouží veřejné cloudy. Pojďme se podívat na definici:
„Veřejný cloud je definován jako výpočetní služby nabízené třetími stranami přes veřejný internet, což je činí dostupnými pro každého, kdo je chce použít nebo zakoupit. Mohou být zdarma nebo prodávány na požádání, což zákazníkům umožňuje platit pouze za využité cykly CPU, úložný prostor nebo šířku pásma.“
Existuje názor, že veřejné cloudy jsou drahé. Ale jejich klíčová myšlenka spočívá ve snižování nákladů společnosti. Jak bylo již zmíněno, veřejné cloudy umožňují získat zdroje na vyžádání a platit pouze za dobu jejich využití. Také někdy zapomínáme, že zaměstnanci dostávají mzdu a specialisté jsou také drahým zdrojem. Je třeba zohlednit, že veřejné cloudy výrazně usnadňují údržbu infrastruktury, což umožňuje inženýrům soustředit se na důležitější úkoly.
Hodnota pro automatizační infrastrukturu
Jaké konkrétní zdroje potřebujeme pro end-to-end UI testy? V zásadě to jsou virtuální stroje nebo clustery (o Kubernetes se budeme bavit v další sekci), které slouží k spuštění prohlížečů a emulatorů. Čím více prohlížečů a emulatorů chceme spustit najednou, tím více CPU a paměti potřebujeme, a tím více peněz za to musíme zaplatit. Veřejné cloudy tedy v kontextu automatizace testování umožňují spouštět velké množství (100, 200, 1000 …) prohlížečů/emulatorů na vyžádání, dostávat výsledky testování co nejrychleji a přestat platit za tak nesmírně nákladné zdroje.
Nejpopulárnějšími cloudovými poskytovateli jsou Amazon Web Services (AWS), Microsoft Azure a Google Cloud Platform (GCP). V praktickém průvodci jsou uvedeny příklady použití GCP, ale celkově není důležité, co přesně použijete pro úkoly automatizace. Všichni poskytují zhruba stejné funkce. Obecně se zaměřuje průvodce na celou infrastrukturu firmy a obchodní požadavky, což je mimo rámec tohoto článku. Pro inženýry automatizace bude zajímavější porovnat používání cloudových poskytovatelů s použitím cloudových platforem konkrétně pro účely testování, jako jsou Sauce Labs, BrowserStack, BitBar a tak dále. Tak už to udělejme! Podle mého názoru je Sauce Labs nejznámější farmou pro cloudové testování, proto jsem ji vzal pro srovnání.
GCP vs Sauce Labs pro účely automatizace:
Představme si, že potřebujeme spustit najednou 8 webových testů a 8 Android testů. K tomu použijeme GCP a spustíme 2 virtuální stroje se Selenoidem. Na prvním vytvoříme 8 kontejnerů s prohlížeči. Na druhém 8 kontejnerů s emulátory. Podívejme se na ceny:
Pro spuštění jednoho kontejneru s Chrome, budeme potřebovat n1-standard-1 stroj. V případě Androidu to bude n1-standard-4 pro jednoho emulátora. Ve skutečnosti je flexibilnější a levnější způsob, jak určit konkrétní uživatelské hodnoty pro CPU/paměť, ale v tuto chvíli pro srovnání se Sauce Labs to není zásadní.
A tady jsou tarify za používání Sauce Labs:
Předpokládám, že jste si už všimli rozdílu, ale přesto uvádím tabulku s výpočty pro náš úkol:
Potřebné zdroje
Měsíčně
Pracovní hodiny(8 ráno — 8 večer)
Pracovní hodiny+ Preemptible
GCP pro web
n1-standard-1 x 8 = n1-standard-8
$194.18
23 dny * 12h * 0.38 = 104.88$
23 dny * 12h * 0.08 = 22.08$
Sauce Labs pro web
Virtuální Cloud8 paralelní testy
$1.559
—
—
GCP pro Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 dny * 12h * 1.52 = 419.52$
23 dny * 12h * 0.32 = 88.32$
Sauce Labs pro Android
Reálné zařízení Cloud 8 paralelní testy
$1.999
—
—
Jak je vidět, rozdíl v ceně je obrovský, zejména pokud se testy spouštějí pouze v běžné dvanáctihodinové pracovní době. Ale náklady lze snížit ještě více, pokud se použijí preemptible stroje. Co to vlastně je?
Preemptible VM je instance, kterou můžete vytvořit a spouštět za mnohem nižší cenu než normální instance. Nicméně, Compute Engine může tyto instance ukončit (preempt), pokud potřebuje přístup k těmto zdrojům pro jiné úkoly. Preemptible instance představují nadbytečnou kapacitu Compute Engine, takže jejich dostupnost se mění v závislosti na využití.
Pokud jsou vaše aplikace odolné proti chybám a mohou snést možné přerušení instancí, mohou preemptible instance výrazně snížit vaše náklady na Compute Engine. Například dávkové zpracování může probíhat na preemptible instancích. Pokud některé z těchto instancí během zpracování skončí, úloha se zpomalí, ale úplně se nezastaví. Preemptible instance dokončují vaše úkoly dávkového zpracování bez toho, aby kladly další zátěž na vaše stávající instance a bez toho, abyste museli platit plnou cenu za další normální instance.
A to ještě není všechno! Ve skutečnosti jsem si jistý, že nikdo nespouští testy po dobu 12 hodin bez přestávky. A pokud je to tak, můžete automaticky spouštět a zastavovat virtuální stroje, když nejsou potřeba. Skutečný čas používání může klesnout na 6 hodin denně. Poté se platba v kontextu našeho úkolu sníží až na 11$ měsíčně za 8 prohlížečů. Není to skvělé? Ale s preemptible stroji musíme být opatrní a připraveni na přerušení a nestabilní chování, i když tyto situace mohou být předvídány a zpracovány programově. Opatří to!
Ale rozhodně neříkám ‚nikdy nepoužívejte cloudové testovací farmy‘. Mají řadu výhod. Především to není jen virtuální stroj, ale kompletní řešení pro automatizaci testování s celou sadou funkcí z krabice: vzdálený přístup, protokoly, screenshoty, nahrávání videa, různé prohlížeče a fyzická mobilní zařízení. V mnoha situacích může být to nezbytnou skvělou alternativou. Zejména testovací platformy jsou užitečné pro automatizaci IOS, kdy veřejné cloudy mohou nabídnout pouze Linuxové/Windowsové systémy. Ale o IOS budeme hovořit v dalších článcích. Doporučuji se vždy řídit situací a vycházet z úkolů: v některých je levnější a efektivnější používat veřejné cloudy, v jiných testovací platformy určitě stojí za utracené peníze.
Ilustrace aktuálního stavu infrastruktury
Odkazy pro studium
Podobné nástroje:
6. Orchestrace
Krátký popis technologie
Mám dobrou zprávu – jsme téměř na konci článku! Naše automatizační infrastruktura v současnosti obsahuje webové a Android testy, které spouštíme paralelně pomocí GitLab CI, s nástroji podporujícími Docker: Selenium grid a Selenoid. Navíc využíváme virtuální stroje vytvořené prostřednictvím GCP pro nasazení kontejnerů s prohlížeči a emulátory. Abychom snížili náklady, spouštíme tyto virtuální stroje pouze na vyžádání a zastavujeme je, když se testování neprovádí. Existuje něco dalšího, co může zlepšit naši infrastrukturu? Odpověď je – ano! Seznamte se s Kubernetes (K8s)!
Nejprve prozkoumejme, jak jsou slova orchestrace, cluster a Kubernetes navzájem propojena. Na vysoké úrovni je orchestrace systém, který nasazuje a spravuje aplikace. Pro automatizaci testování jsou takovými kontejnerizovanými aplikacemi Selenium grid a Selenoid. Docker a K8s se vzájemně doplňují. První slouží k nasazení aplikací, druhý k orchestrace. K8s je zároveň cluster. Úkolem clusteru je používat VM jako uzly, což umožňuje instalovat různé funkce, programy a služby v rámci jednoho serveru (clusteru). Pokud některý uzel selže, ostatní uzly převezmou, což zajišťuje nepřetržitý provoz naší aplikace. Kromě toho má K8s důležitou funkčnost související se škálováním, díky čemuž automaticky získáváme optimální množství zdrojů na základě zatížení a nastavených limitů.
Opravdu, ruční nasazení Kubernetes od nuly není vůbec triviální úkol. Odkážu na známého praktického průvodce "Kubernetes The Hard Way", a pokud máte zájem, můžete si to vyzkoušet. Naštěstí však existují alternativní metody a nástroje. Nejdostupnější z nich je použití Google Kubernetes Engine (GKE) v GCP, což vám umožní získat připravený klastr po několika kliknutích. Pro začátek doporučuji použít právě tento přístup, protože vám umožní soustředit se na to, jak používat K8s pro své úkoly, místo zkoumání toho, jak by měly být vzájemně integrovány vnitřní komponenty.
Hodnota pro automatizační infrastrukturu
Podívejme se na několik významných funkcí, které K8s poskytuje:
- nasazení aplikace: využití multi-nodového klastru, místo VM;
- dynamické škálování: snižuje náklady na zdroje, které jsou používány pouze na vyžádání;
- samoobnovování (Self-healing): automatické obnovení pods (což vede k obnovení i kontejnerů);
- nasazení aktualizací a návratů změn bez výpadku: aktualizace nástrojů, prohlížečů a emulátorů nepřerušuje práci aktuálních uživatelů.
Ale K8s stále není stříbrná kulka. Pro pochopení všech výhod a omezení v kontextu námi zvažovaných nástrojů (Selenium grid, Selenoid) stručně prodiskutujeme strukturu K8s. Klast obsahuje dva typy uzlů: Master Nodes a Workers Nodes. Master Nodes jsou zodpovědné za řízení, nasazení a rozhodování o plánování. Workers Nodes jsou místa, kde běží aplikace. Uzly také obsahují prostředí pro spuštění kontejnerů. V našem případě je to Docker, který zajišťuje operace spojené s kontejnery. Existují však i alternativní řešení, například. Je důležité pochopit, že škálování nebo samoobnovování se přímo netýká kontejnerů. To se realizuje přidáním/odebráním počtu pods, které obsahují kontejnery (obvykle jeden kontejner na pod, ale v závislosti na úkolu jich může být více). Vysokoúrovňová hierarchie představuje workers nodes, uvnitř kterých se nacházejí pods, uvnitř kterých běží kontejnery.
Funkce škálování je klíčová a může být aplikována jak na uzly uvnitř cluster node-pool, tak na pody uvnitř uzlu. Existují 2 typy škálování, které se vztahují jak k uzlům, tak k podům. První typ je horizontální - škálování se provádí zvýšením počtu uzlů/podů. Tento typ je preferovanější. Druhý typ, odpovídajícím způsobem, je vertikální. Škálování se provádí zvýšením velikosti uzlů/podů, nikoli jejich počtu.
Nyní se podíváme na naše nástroje v kontextu výše zmíněných termínů.
Selenium grid
Jak bylo zmíněno dříve, Selenium grid je velmi populární nástroj, a není překvapením, že byl kontejnerizován. Není proto překvapující, že Selenium grid může být nasazen v K8s. Příklad, jak toho dosáhnout, lze nalézt v oficiálním K8s repozitáři. Jak obvykle, odkazy přikládám na konci sekce. Kromě toho je v praktickém průvodci ukázáno, jak toho dosáhnout pomocí Terraformu. Také existuje návod, jak škálovat počet podů, které obsahují kontejnery s prohlížeči. Funkce automatického škálování v kontextu K8s je však stále ne zcela jasný úkol. Když jsem začal studovat, nenašel jsem žádný praktický průvodce nebo doporučení. Po několika výzkumech a experimentech s podporou DevOps týmu jsme zvolili přístup nasazování kontejnerů s požadovanými prohlížeči uvnitř jednoho podu, který se nachází uvnitř jednoho worker uzlu. Tento způsob nám umožňuje aplikovat strategii horizontálního škálování uzlů zvýšením jejich počtu. Doufám, že se situace v budoucnu změní a uvidíme čím dál více popisů nejlepších přístupů a hotových řešení, zejména po vydání Selenium grid 4 se změněnou vnitřní architekturou.
Selenoid:
V současné době je nasazení Selenoidu v K8s největší zklamání. Nejsou kompatibilní. Teoreticky můžeme nasadit Selenoid kontejner uvnitř podu, ale když Selenoid začne spouštět kontejnery s prohlížeči, budou se stále nacházet uvnitř tohoto samého podu. To znemožňuje škálování a jako výsledek nebude práce Selenoidu uvnitř clusteru mít žádný rozdíl oproti práci uvnitř virtuálního stroje. Konec příběhu.
Moon:
S vědomím této úzké brány při práci se Selenoidem vyvinuli vývojáři výkonnější nástroj nazvaný Moon. Tento nástroj byl původně navržen pro práci s Kubernetes a v důsledku toho je možné a nutné využívat funkci automatického škálování. Navíc bych řekl, že v současnosti je to jedinou nástroj v oblasti Selenium, který má nativní podporu pro K8s cluster již v základu (už ne, viz další nástroj ). Klíčovou vlastností Moon, která tuto podporu zajišťuje, je:
Úplně bezstavový. Selenoid ukládá v paměti informace o právě běžících relacích prohlížeče. Pokud se z nějakého důvodu jeho proces zhroutí — všechny běžící relace jsou ztraceny. Moon naopak nemá žádný interní stav a může být replikován napříč datovými centry. Relace prohlížeče zůstávají aktivní, i když jeden nebo více replik selže.
Takže Moon je skvělé řešení, ale s jedním problémem: není zdarma. Cena závisí na počtu relací. Zdarma lze spustit pouze 0-4 relace, což není příliš užitečné. Od páté relace se však platí 5 $ za každou. Situace se může lišit od společnosti ke společnosti, ale v našem případě je použití Moon bezvýznamné. Jak jsem již popsal výše, můžeme spouštět VM se Selenium Grid na požádání nebo zvýšit počet Nodes v clusteru. Přibližně na jeden pipeline spouštíme 500 prohlížečů a po dokončení testů přerušujeme všechny zdroje. Kdybychom používali Moon, museli bychom zaplatit dalších 500 x 5 = 2500 $ měsíčně, a nezáleží na tom, jak často testy spouštíme. A opět, neříkám „nepoužívejte Moon“. Pro vaše úkoly to může být nezbytné řešení, například pokud máte ve vaší organizaci mnoho projektů/týmů a potřebujete obrovský společný cluster pro všechny. Jak už bylo řečeno, na konci zanechám odkaz a doporučím provést veškeré nezbytné výpočty v kontextu vašeho úkolu.
Callisto: (Pozor! Toto není v původním článku a nachází se pouze v ruském překladu)
Jak jsem řekl, Selenium je velmi populární nástroj a oblast IT se rychle vyvíjí. Když jsem pracoval na překladu, na síti se objevil nový slibný nástroj Callisto (pozdrav Cypress a ostatním zabijákům Selenium). Pracuje nativně s K8s a umožňuje spouštět Selenoid kontejnery v podech, rozloženě po uzlech. Všechno funguje ihned po vybalení, včetně automatického škálování. Fantastické, ale je potřeba to otestovat. Už se mi podařilo tento nástroj nasadit a provést několik experimentů. Ale je příliš brzy na závěry, po získání výsledků na dlouhé vzdálenosti, možná udělám recenzi v následujících článcích. Zatím nechávám pouze odkazy pro samostatné výzkumy.
Ilustrace aktuálního stavu infrastruktury
Odkazy pro studium
Odkazy pro studium
Podobné nástroje
7. Infrastruktura jako kód (IaC)
Krátký popis technologie
A zde jsme se dostali k poslední části. Obvykle tato technologie a s ní spojené úkoly nepatří do zodpovědnosti inženýrů pro automatizaci. A na to jsou své důvody. Zaprvé, v mnoha organizacích jsou infrastrukturní otázky pod kontrolou oddělení DevOps a vývojový tým se příliš nezajímá o to, na čem pipeline běží a jak je třeba udržovat všechno, co s tím souvisí. Zadruhé, buďme upřímní, praxe „Infrastruktura jako kód (IaC)“ se stále v mnoha společnostech neuplatňuje. Ale určitě to se stalo populárním trendem a je důležité snažit se zúčastnit souvisejících procesů, přístupů a nástrojů. Nebo alespoň být v obraze.
Začněme motivací pro použití tohoto přístupu. Již jsme prodiskutovali, že k spuštění testů v GitlabCI potřebujeme alespoň prostředky pro spuštění Gitlab Runneru. A pro spuštění kontejnerů s prohlížeči/emulátory musíme rezervovat VM nebo klastr. Kromě prostředků pro testování potřebujeme také značný počet zdrojů pro údržbu vývojových, stagingových a produkčních prostředí, což zahrnuje databáze, automatizované plány, síťovou konfiguraci, vyvažování zatížení, uživatelská práva a tak dále. Klíčovým problémem jsou požadované úsilí k udržení toho všeho. Existuje několik způsobů, jak můžeme provádět změny a vydávat aktualizace. Například v kontextu GCP můžeme použít UI konzoli v prohlížeči a provádět všechny akce klikáním na tlačítka. Alternativou může být použití API volání k interakci s cloudovými entitami nebo použití nástroje gcloud pro provedení potřebných manipulací. Avšak při skutečně velkém počtu různých entit a infrastrukturních prvků se stává obtížné nebo dokonce nemožné provádět všechny operace ručně. Navíc všechny tyto ruční akce jsou nekontrolovatelné. Nemůžeme je poslat na přezkum před provedením, používat systém správy verzí a rychle vrátit změny, které vedly k incidentu. Pro řešení těchto problémů inženýři vytváří a stále vytvářejí automatické bash/shell skripty, což není o mnoho lepší než předchozí metody, protože je není snadné rychle přečíst, pochopit, udržovat a modifikovat v procedurálním stylu.
V tomto článku a praktickém průvodci používám 2 nástroje spojené s praktikou IaC. Jsou to Terraform a Ansible. Někteří se domnívají, že nemá smysl používat je současně, protože jejich funkčnost je podobná a jsou vzájemně zastupitelné. Ale problém je v tom, že původně mají zcela odlišné úkoly. A fakt, že tyto nástroje by si měly navzájem doplňovat, byl potvrzen na společné prezentaci vývojáři z firem HashiCorp a RedHat. Konceptuální rozdíl spočívá v tom, že Terraform je provisioningový nástroj pro správu samotných serverů. Zatímco Ansible je nástroj pro správu konfigurací, jehož úkolem je instalace, nastavení a správa softwaru na těchto serverech.
Další klíčovou odlišující vlastností těchto nástrojů je styl psaní kódu. Na rozdíl od bash a Ansible používá Terraform deklarativní styl, založený na popisu požadovaného konečného stavu, kterého je třeba dosáhnout v důsledku provedení. Například, pokud hodláme vytvořit 10 VMs a aplikovat změny prostřednictvím Terraform, dostaneme 10 VMs. Pokud aplikujeme skript znovu, nic se nestane, protože již máme 10 VMs, a Terraform si toho je vědom, protože uchovává aktuální stav infrastruktury v state souboru. Na druhou stranu Ansible používá procedurální přístup a pokud jej požádáme, aby vytvořil 10 VMs, při prvním spuštění získáme 10 VMs, stejně jako s Terraform. Ale po opětovném spuštění již budeme mít 20 VMs. V tom je podstatný rozdíl. V procedurálním stylu neuchováváme aktuální stav a prostě popisujeme sekvenci kroků, které mají být provedeny. Samozřejmě můžeme zpracovat různé situace, přidat několik kontrol na existenci zdrojů a aktuální stav, ale nemá smysl trávit náš čas a vynakládat úsilí na kontrolu této logiky. Navíc to zvyšuje riziko chyb.
Shrneme-li vše výše uvedené, můžeme dojít k závěru, že pro provisioning serverů je vhodnějším nástrojem Terraform a deklarativní notace. Na správu konfigurací je lepší delegovat na Ansible. Až to pochopíme, podívejme se na příklady použití v kontextu automatizace.
Hodnota pro automatizační infrastrukturu
Je důležité chápat, že infrastruktura automatizace testování by měla být vnímána jako součást celé infrastruktury společnosti. To znamená, že všechny praktiky IaC by měly být aplikovány globálně na zdroje celé organizace. Kdo je za to zodpovědný, závisí na vašich procesech. DevOps tým má v těchto otázkách větší zkušenosti, vidí celkový obraz. Nicméně QA inženýři jsou více zapojeni do procesu budování automatizace a struktury pipeline, což jim umožňuje lépe vidět veškeré potřebné změny a příležitosti pro zlepšení. Nejlepším řešením je pracovat společně, sdílet znalosti a nápady k dosažení očekávaného výsledku.
Uvedu několik příkladů použití Terraform a Ansible v kontextu automatizace testování a nástrojů, které jsme předtím diskutovali:
1. Popisovat pomocí Terraform potřebné vlastnosti a parametry virtuálních strojů a clusterů.
2. Nainstalovat pomocí Ansible potřebné nástroje pro testování: docker, Selenoid, Selenium Grid a stáhnout potřebné verze prohlížečů/emulátorů.
3. Popisovat pomocí Terraform vlastnosti virtuálního stroje, na kterém bude spuštěn GitLab Runner.
4. Nainstalovat pomocí Ansible GitLab Runner a potřebné související nástroje, nastavit parametry a konfigurace.
Ilustrace aktuálního stavu infrastruktury
Odkazy pro studium:
Podobné nástroje
Shrňme to!
Krok
Technologie
Nástroje
Hodnota pro automatizační infrastrukturu
1
Místní provoz
Node.js, Selenium, Appium
- Nejpopulárnější nástroje pro web a mobil
- Podpora mnoha jazyků a platforem (včetně Node.js)
2
Systémy správy verzí
Git
- Podobné výhody s vývojovým kódem
3
Kontejnerizace
Docker, Selenium grid, Selenoid (Web, Android)
- Paralelní spouštění testů
- Izolovaná prostředí
- Jednoduché, flexibilní aktualizace verzí
- Dynamické zastavení nepoužívaných zdrojů
- Snadné nastavení
4
CI / CD
Gitlab CI
- Testy jsou součástí kontejneru
- Rychlá zpětná vazba
- Viditelnost pro celou společnost/tým
5
Cloudové platformy
Google Cloud Platform
- Zdroje na vyžádání (platíme jen když potřebujeme)
- Snadno spravovatelné a aktualizovatelné
- Viditelnost a kontrola všech zdrojů
6
Orchestrace
Kubernetes
V kontextu kontejnerů s prohlížeči/emulátory uvnitř pods:
- Škálování/automatické škálování
- Samovyléčení
- Aktualizace a návraty bez přerušení
7
Infrastruktura jako kód (IaC)
Terraform, Ansible
- Podobné výhody s vývojovou infrastrukturou
- Všechny výhody verzování kódu
- Snadné provádění změn a údržba
- Úplně automatizováno
Mind map diagramy: evoluce infrastruktury
krok 1: Lokální
krok 2: VCS
krok 3: Kontejnery
krok 4: CI/CD
krok 5: Cloudové platformy
krok 6: Orchestraci
krok 7: IaC
Co dál?
A tak, to je konec článku. Na závěr bych rád s vámi dohodl některé dohody.
Z vaší strany
Jak jsem již uvedl na začátku, chtěl bych, aby článek měl praktický přínos a pomohl vám aplikovat získané znalosti v reálné práci. Znovu přidávám.
Ale ani po tom se nezastavujte, procvičujte, studujte relevantní odkazy a knihy, zjistěte, jak to funguje ve vaší firmě, hledejte místa, která lze zlepšit a zapojte se do toho. Hodně štěstí!
Z mojí strany
Z názvu je patrné, že to byla pouze první část. I když byla docela dlouhá, zde stále nejsou probrána důležitá témata. Ve druhé části plánuji prozkoumat automatizaci infrastruktury v kontextu iOS. Vzhledem k omezením Apple týkajícím se spouštění simulátorů iOS pouze na systémech macOS je náš soubor řešení omezený. Například jsme zbaveni možnosti používat Docker k spuštění simulátoru nebo veřejných cloudů ke spuštění virtuálních strojů. Ale to neznamená, že neexistují jiné alternativy. Pokusím se vás informovat o nejmodernějších řešení a nástrojích!
Také jsem nezmínil docela velká témata týkající se monitorování. V části 3 se chci zaměřit na nejpopulárnější nástroje pro monitorování infrastruktury a také jaká data a metriky je třeba brát v úvahu.
A nakonec. V budoucnu plánuji vydat video kurz o vytváření testovací infrastruktury a populárních nástrojích. V současnosti je na internetu poměrně mnoho kurzů a přednášek o DevOps, ale všechny materiály jsou prezentovány v kontextu vývoje, nikoli automatizace testování. V této záležitosti velmi potřebuji zpětnou vazbu, zda by takový kurz byl zajímavý a cenný pro komunitu testerů a automatizátorů. Děkuji předem!
Zdroj: habr.com
