Část 1: Web/Android
Poznámka: tento článek je překladem původní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 nedošlo ke zkreslení významu při překladu do ruštiny. Přeji příjemné studium!
V současnosti je specialita DevOps jednou z nejžádanějších v IT průmyslu. Pokud otevřete oblíbené stránky pro hledání zaměstnání a filtrujete podle platu, uvidíte, že pracovní místa související s DevOps jsou na začátku seznamu. Je však důležité pochopit, že se to týká především pozice „Senior“, což znamená, že kandidát má vysokou úroveň dovedností, znalostí technologie a nástrojů. S tím je spojena i vysoká míra odpovědnosti spojená s nepřetržitým provozem výroby. Začali jsme však zapomínat, co je DevOps. Zpočátku to nebyla žádná konkrétní osoba nebo oddělení. Pokud budeme hledat definice tohoto pojmu, najdeme mnoho krásných a správných podstatných jmen, jako je metodologie, praxe, kulturní filozofie, skupina pojmů a tak dále.
Moje specializace je testovací automatizační inženýr (QA automation engineer), ale věřím, že by to nemělo být spojeno pouze s psaním autotestů nebo vývojem architektury testovacího frameworku. V roce 2020 je také nezbytná znalost automatizační infrastruktury. To vám umožní organizovat proces automatizace sami, od spuštění testů až po poskytování výsledků všem zúčastněným v souladu s vašimi cíli. V důsledku toho jsou dovednosti DevOps nezbytností k dokončení práce. A to vše je dobré, ale bohužel je tu problém (spoiler: tento článek se pokouší tento problém zjednodušit). Jde o to, že DevOps je těžké. A to je zřejmé, protože společnosti nebudou platit moc za něco, co je snadné udělat... Ve světě DevOps existuje velké množství nástrojů, termínů a postupů, které je třeba zvládnout. To je obzvláště obtížné na začátku kariéry a závisí na nasbíraných technických zkušenostech.
Zdroj:
Zde pravděpodobně skončíme s úvodní částí a zaměříme se na účel tohoto článku.
O čem je tento článek
V tomto článku se podělím o své zkušenosti s budováním infrastruktury pro automatizaci testování. Na internetu je mnoho zdrojů informací o různých nástrojích a jejich použití, ale rád bych se na ně podíval čistě v kontextu automatizace. Věřím, že mnoho automatizačních inženýrů je obeznámeno se situací, kdy nikdo kromě vás neprovádí vyvinuté testy ani se nestará o jejich údržbu. V důsledku toho jsou testy zastaralé a musíte trávit čas jejich aktualizací. Na začátku kariéry to může být opět docela těžký úkol: moudře se rozhodnout, které nástroje by měly pomoci odstranit daný problém, jak je vybrat, nakonfigurovat a udržovat. Někteří testeři se obracejí o pomoc na DevOps (lidi) a buďme upřímní, tento přístup funguje. V mnoha případech to může být jediná možnost, protože nemáme přehled o všech závislostech. Jak ale víme, DevOps jsou hodně vytížení kluci, protože musí myslet na celou firemní infrastrukturu, nasazení, monitoring, mikroslužby a další podobné úkoly v závislosti na organizaci/týmu. Jak už to tak bývá, automatizace není prioritou. V takovém případě se musíme snažit udělat z naší strany všechno možné od začátku do konce. To sníží závislosti, zrychlí pracovní tok, zlepší naše dovednosti a umožní nám vidět větší obrázek toho, co se děje.
Článek představuje nejoblíbenější a nejoblíbenější nástroje a ukazuje, jak je krok za krokem použít k vybudování automatizační infrastruktury. Každá skupina je reprezentována nástroji, které byly testovány osobní zkušeností. To ale neznamená, že musíte používat to samé. Samotné nástroje nejsou důležité, objevují se a zastarávají. Naším inženýrským úkolem je pochopit základní principy: proč potřebujeme tuto skupinu nástrojů a jaké pracovní problémy můžeme s jejich pomocí vyřešit. Proto na konci každé části nechávám odkazy na podobné nástroje, které mohou být použity ve vaší organizaci.
Co v tomto článku není
Ještě jednou opakuji, že článek není o konkrétních nástrojích, takže zde nebudou žádné vkládání kódu z dokumentace a popisů konkrétních příkazů. Ale na konci každé části nechávám odkazy pro podrobné studium.
To se děje, protože:
- tento materiál lze velmi snadno najít v různých zdrojích (dokumentace, knihy, videokurzy);
- pokud začneme jít hlouběji, budeme muset napsat 10, 20, 30 dílů tohoto článku (zatímco plány jsou 2-3);
- Jen nechci ztrácet čas, protože možná budete chtít použít jiné nástroje k dosažení stejných cílů.
Praxe
Moc bych si přál, aby tento materiál byl užitečný pro každého čtenáře, a ne jen přečtený a zapomenutý. V každém studiu je velmi důležitou součástí praxe. Na to jsem se připravil. Čeká na vás i domácí úkol, abyste se ujistili, že bezmyšlenkovitě nekopírujete řádky právě prováděných příkazů.
Plán
Krok
Technika
Tools
1
Místní běh (připravte si ukázkové testy webu/androidu a spusťte je lokálně)
Node.js, Selenium, Appium
2
Systémy pro správu verzí
Git
3
Kontejnerizace
Docker, selenová mřížka, selenoid (web, Android)
4
CI/CD
Gitlab CI
5
Cloud platformy
Google Cloud Platform
6
Orchestrace
Kubernetes
7
Infrastruktura jako kód (IaC)
Terraform, Ansible
Struktura každé sekce
Aby byl příběh jasný, je každá část popsána podle následující osnovy:
- stručný popis technologie,
- hodnota pro automatizační infrastrukturu,
- ilustrace současného stavu infrastruktury,
- odkazy na studium,
- podobné nástroje.
1. Spusťte testy lokálně
Stručný popis technologie
Toto je pouze přípravný krok k místnímu spuštění demo testů a ověření, že projdou. V praktické části je použit Node.js, ale programovací jazyk a platforma také nejsou důležité a můžete použít ty, které se používají ve vaší firmě.
Jako nástroje pro automatizaci však doporučuji používat Selenium WebDriver pro webové platformy a Appium pro platformu Android, protože v dalších krocích použijeme obrázky Docker, které jsou přizpůsobeny pro práci s těmito nástroji. Navíc, s odkazem na pracovní požadavky, jsou tyto nástroje na trhu nejžádanější.
Jak jste si možná všimli, bereme v úvahu pouze testy webu a Androidu. Bohužel iOS je úplně jiný příběh (díky Applu). V nadcházejících dílech plánuji předvést řešení a postupy související s IOS.
Hodnota pro infrastrukturu automatizace
Z hlediska infrastruktury nepřináší místní běh žádnou hodnotu. Kontrolujete pouze, že testy běží na místním počítači v místních prohlížečích a simulátorech. Ale v každém případě je to nezbytný výchozí bod.
Ilustrace současného stavu infrastruktury
Odkazy k prozkoumání
Podobné nástroje
- jakýkoli programovací jazyk, který se vám líbí, ve spojení s testy Selenium/Appium;
- jakékoli testy;
- jakýkoli testovací běžec.
2. Systémy pro správu verzí (Git)
Stručný popis technologie
Pro nikoho nebude velkým zjevením, když řeknu, že kontrola verzí je nesmírně důležitou součástí vývoje, a to jak v týmu, tak individuálně. Na základě různých zdrojů lze s jistotou říci, že Git je nejoblíbenějším zástupcem. Systém správy verzí poskytuje mnoho výhod, jako je sdílení kódu, ukládání verzí, obnova do předchozích větví, sledování historie projektu a zálohování. Nebudeme se podrobně zabývat každým bodem, protože jsem si jist, že jej dobře znáte a používáte jej ve své každodenní práci. Pokud ale najednou ne, pak doporučuji přerušit čtení tohoto článku a tuto mezeru co nejdříve zaplnit.
Hodnota pro infrastrukturu automatizace
A zde si můžete položit rozumnou otázku: „Proč nám říká o Gitu? Každý to ví a používá to jak pro vývojový kód, tak pro automatický testovací kód.“ Budete mít naprostou pravdu, ale v tomto článku mluvíme o infrastruktuře a tato sekce slouží jako náhled na sekci 7: „Infrastruktura jako kód (IaC)“. Pro nás to znamená, že celá infrastruktura včetně testování je popsána formou kódu, takže na ni můžeme aplikovat i verzovací systémy a získat podobné výhody jako u vývojového a automatizačního kódu.
Na IaC se podíváme podrobněji v kroku 7, ale i nyní můžete začít používat Git lokálně vytvořením místního úložiště. Celkový obraz se rozšíří, když do infrastruktury přidáme vzdálené úložiště.
Ilustrace současného stavu infrastruktury
Odkazy k prozkoumání
Podobné nástroje
3. Kontejnerizace (Docker)
Stručný popis technologie
Abychom demonstrovali, jak kontejnerizace změnila pravidla hry, vraťme se v čase o několik desetiletí zpět. Tehdy lidé kupovali a používali serverové stroje ke spouštění aplikací. Ale ve většině případů nebyly požadované zdroje pro spuštění známy předem. V důsledku toho společnosti utrácely peníze na nákup drahých a výkonných serverů, ale část této kapacity nebyla zcela využita.
Další fází evoluce byly virtuální stroje (VM), které vyřešily problém plýtvání penězi za nevyužité zdroje. Tato technologie umožnila spouštět aplikace nezávisle na sobě na stejném serveru a přidělovala zcela izolovaný prostor. Ale bohužel každá technologie má své nevýhody. Provoz virtuálního počítače vyžaduje úplný operační systém, který spotřebovává CPU, RAM, úložiště a v závislosti na OS je třeba vzít v úvahu náklady na licence. Tyto faktory ovlivňují rychlost načítání a ztěžují přenositelnost.
A nyní se dostáváme ke kontejnerizaci. Tato technologie opět řeší předchozí problém, protože kontejnery nepoužívají plný OS, což uvolňuje velké množství zdrojů a poskytuje rychlé a flexibilní řešení pro přenositelnost.
Technologie kontejnerizace samozřejmě není nic nového a poprvé byla představena koncem 70. let. V té době bylo provedeno mnoho výzkumů, vývoje a pokusů. Byl to ale Docker, kdo tuto technologii přizpůsobil a učinil ji snadno dostupnou pro masy. V dnešní době, když mluvíme o kontejnerech, máme ve většině případů na mysli Docker. Když mluvíme o kontejnerech Docker, máme na mysli kontejnery Linux. Ke spouštění kontejnerů můžeme použít systémy Windows a macOS, ale je důležité si uvědomit, že v tomto případě se objeví další vrstva. Například Docker na Macu tiše spouští kontejnery uvnitř lehkého virtuálního počítače s Linuxem. K tomuto tématu se vrátíme, až budeme diskutovat o spuštění emulátorů Androidu uvnitř kontejnerů, takže zde je velmi důležitá nuance, kterou je třeba probrat podrobněji.
Hodnota pro infrastrukturu automatizace
Zjistili jsme, že kontejnerizace a Docker jsou cool. Podívejme se na to v kontextu automatizace, protože každý nástroj nebo technologie potřebuje vyřešit nějaký problém. Pojďme si nastínit zjevné problémy automatizace testování v kontextu testů uživatelského rozhraní:
- 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čů;
- nedostatek izolovaného prostoru pro prohlížeče/simulátory, což je zvláště důležité pro paralelní běh;
- obtížné spravovat a udržovat, pokud potřebujete současně provozovat 10, 50, 100 nebo dokonce 1000 prohlížečů.
Jelikož je ale Selenium nejoblíbenějším automatizačním nástrojem a Docker nejoblíbenějším kontejnerizačním nástrojem, nemělo by nikoho překvapit, že se je někdo pokusil zkombinovat a vytvořit tak výkonný nástroj k řešení výše zmíněných problémů. Zvažme taková řešení podrobněji.
Selenová mřížka v dockeru
Tento nástroj je nejoblíbenější ve světě Selenium pro provozování více prohlížečů na více strojích a jejich správu z centrálního centra. Chcete-li začít, musíte zaregistrovat alespoň 2 části: Hub a Node(y). Hub je centrální uzel, který přijímá všechny požadavky z testů a distribuuje je do příslušných uzlů. Pro každý Node můžeme nakonfigurovat specifickou konfiguraci, například zadáním požadovaného prohlížeče a jeho verze. Stále se však musíme sami postarat o kompatibilní ovladače prohlížeče a nainstalovat je na požadované Nody. Z tohoto důvodu se Selenium grid nepoužívá ve své čisté podobě, kromě případů, kdy potřebujeme pracovat s prohlížeči, které nelze nainstalovat na OS Linux. Pro všechny ostatní případy by výrazně flexibilním a správným řešením bylo použití obrazů Docker ke spuštění Selenium grid Hub a Nodes. Tento přístup značně zjednodušuje správu uzlů, protože si můžeme vybrat obraz, který potřebujeme, s kompatibilními verzemi prohlížečů a již nainstalovanými ovladači.
Navzdory negativním recenzím o stabilitě, zejména při paralelním běhu velkého počtu uzlů, je Selenium grid stále nejoblíbenějším nástrojem pro paralelní spouštění testů Selenium. Je důležité si uvědomit, že v open-source se neustále objevují různá vylepšení a úpravy tohoto nástroje, které bojují s různými úzkými místy.
Selenoid pro web
Tento nástroj je průlomem ve světě Selenium, protože funguje hned po vybalení a usnadňuje život mnoha automatizačním inženýrům. Za prvé, nejedná se o další modifikaci mřížky Selenium. Místo toho vývojáři vytvořili zcela novou verzi Selenium Hub v Golangu, která v kombinaci s odlehčenými obrázky Docker pro různé prohlížeče dala impuls k rozvoji automatizace testování. Navíc v případě Selenium Grid musíme předem určit všechny požadované prohlížeče a jejich verze, což při práci pouze s jedním prohlížečem není problém. Ale pokud jde o více podporovaných prohlížečů, Selenoid je řešením číslo jedna díky své funkci „prohlížeč na vyžádání“. Vše, co se od nás vyžaduje, je předem stáhnout potřebné obrázky pomocí prohlížečů a aktualizovat konfigurační soubor, se kterým Selenoid komunikuje. Poté, co Selenoid obdrží požadavek z testů, automaticky spustí požadovaný kontejner s požadovaným prohlížečem. Po dokončení testu Selenoid kontejner vyřadí, čímž uvolní zdroje pro budoucí požadavky. Tento přístup zcela eliminuje dobře známý problém „degradace uzlů“, se kterým se často setkáváme v mřížce Selenium.
Ale bohužel, Selenoid stále není stříbrná kulka. Získali jsme funkci „prohlížeč na vyžádání“, ale funkce „zdroje na vyžádání“ stále není k dispozici. Abychom mohli Selenoid používat, musíme jej nasadit na fyzický hardware nebo na VM, což znamená, že musíme předem vědět, kolik zdrojů je třeba alokovat. Myslím, že to není problém pro malé projekty, které provozují paralelně 10, 20 nebo dokonce 30 prohlížečů. Ale co když potřebujeme 100, 500, 1000 a více? Nemá smysl neustále udržovat a platit za takové množství zdrojů. V částech 5 a 6 tohoto článku budeme diskutovat o řešeních, která vám umožní škálovat, a tím výrazně snížit náklady společnosti.
Selenoid pro Android
Po úspěchu Selenoidu jako nástroje pro automatizaci webu lidé chtěli něco podobného pro Android. A stalo se – Selenoid byl vydán s podporou Androidu. Z pohledu uživatele na vysoké úrovni je princip fungování podobný automatizaci webu. Jediný rozdíl je v tom, že místo kontejnerů prohlížeče Selenoid spouští kontejnery emulátoru Android. Dle mého názoru jde v současnosti o nejvýkonnější bezplatný nástroj pro paralelní spouštění testů Androidu.
Opravdu bych nerad mluvil o negativních aspektech tohoto nástroje, protože se mi opravdu líbí. Stále však existují stejné nevýhody, které platí pro automatizaci webu a jsou spojeny s škálováním. Kromě toho musíme mluvit o jednom omezení, které může být překvapením, pokud nástroj nastavujeme poprvé. Ke spuštění bitových kopií Android potřebujeme fyzický stroj nebo virtuální počítač s podporou vnořené virtualizace. V průvodci jak na to demonstruji, jak to povolit na virtuálním počítači Linux. Pokud jste však uživatelem macOS a chcete Selenoid nasadit lokálně, nebude možné spustit testy Androidu. Ale vždy můžete spustit linuxový virtuální počítač lokálně s nakonfigurovanou „vnořenou virtualizací“ a nasadit Selenoid uvnitř.
Ilustrace současného stavu infrastruktury
V kontextu tohoto článku přidáme 2 nástroje pro ilustraci infrastruktury. Jedná se o Selenium grid pro webové testy a Selenoid pro testy Android. V tutoriálu GitHub vám také ukážu, jak používat Selenoid ke spouštění webových testů.
Odkazy k prozkoumání
Podobné nástroje
- Existují další kontejnerizační nástroje, ale Docker je nejoblíbenější. Pokud chcete vyzkoušet něco jiného, mějte na paměti, že nástroje, které jsme probrali pro paralelní spouštění testů Selenium, nebudou hned po vybalení fungovat.
- Jak již bylo řečeno, existuje mnoho modifikací selenové mřížky, např..
4.CI/CD
Stručný popis technologie
Praxe kontinuální integrace je ve vývoji poměrně populární a je na stejné úrovni jako systémy pro správu verzí. Navzdory tomu mám pocit, že v terminologii panuje zmatek. V tomto odstavci bych rád popsal 3 modifikace této technologie z mého pohledu. Na internetu najdete mnoho článků s různými výklady a je naprosto normální, pokud se váš názor liší. Nejdůležitější je, abyste byli s kolegy na stejné vlně.
Existují tedy 3 termíny: CI - Continuous Integration, CD - Continuous Delivery a opět CD - Continuous Deployment. (Níže budu tyto výrazy používat v angličtině). Každá modifikace přidává do vašeho vývojového kanálu několik dalších kroků. Ale slovo nepřetržitý (kontinuální) je to nejdůležitější. V této souvislosti máme na mysli něco, co se děje od začátku do konce, bez přerušení nebo ručního zásahu. Podívejme se v této souvislosti na CI & CD a CD.
- Průběžná integrace toto je první 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. CI obvykle zahrnuje spouštění nástrojů pro analýzu statického kódu a testy jednotek/interních API. To nám umožňuje získat informace o našem kódu během několika sekund/minut.
- Continuous Delivery je pokročilejší krok, kde spouštíme testy integrace/uživatelského rozhraní. V této fázi však nedosahujeme výsledků tak rychle jako u CI. Za prvé, dokončení těchto typů testů trvá déle. Za druhé, před spuštěním musíme implementovat naše změny do testovacího/stagingového prostředí. Navíc, pokud mluvíme o mobilním vývoji, objeví se další krok k vytvoření sestavení naší aplikace.
- Kontinuální nasazení předpokládá, že naše změny automaticky uvolníme do výroby, pokud prošly všemi akceptačními testy v předchozích fázích. Kromě toho můžete po fázi vydání konfigurovat různé fáze, jako je spouštění testů kouře na produkci a shromažďování požadovaných metrik. Průběžné zavádění je možné pouze s dobrým pokrytím automatickými testy. Pokud jsou vyžadovány nějaké ruční zásahy, včetně testování, pak to již není Nepřetržitý (kontinuální). Pak můžeme říci, že naše potrubí vyhovuje pouze praxi nepřetržitého doručování.
Hodnota pro infrastrukturu automatizace
V této části bych měl objasnit, že když mluvíme o end-to-end testech uživatelského rozhraní, znamená to, že bychom měli nasadit naše změny a související služby do testovacích prostředí. Průběžná integrace – proces není pro tento úkol použitelný a musíme se postarat o implementaci alespoň postupů průběžného doručování. Continuous Deployment má smysl i v kontextu testů uživatelského rozhraní, pokud je budeme spouštět v produkci.
A než se podíváme na ilustraci změny architektury, chci říci pár slov o GitLab CI. Na rozdíl od jiných nástrojů CI/CD poskytuje GitLab vzdálené úložiště a mnoho dalších doplňkových funkcí. GitLab je tedy více než CI. Zahrnuje správu zdrojového kódu, agilní správu, kanály CI/CD, nástroje pro protokolování a shromažďování metrik ihned po vybalení. Architektura GitLab se skládá z Gitlab CI/CD a GitLab Runner. Zde je krátký popis z oficiálních stránek:
Gitlab CI/CD je webová aplikace s API, která ukládá svůj stav do databáze, spravuje projekty/sestavení a poskytuje uživatelské rozhraní. GitLab Runner je aplikace, která zpracovává sestavení. Lze jej nasadit samostatně a funguje s GitLab CI/CD prostřednictvím API. Pro spuštění testů potřebujete jak instanci Gitlabu, tak Runner.
Ilustrace současného stavu infrastruktury
Odkazy k prozkoumání
Podobné nástroje
- A mnoho dalších
5. Cloudové platformy
Stručný popis technologie
V této části budeme hovořit o populárním trendu zvaném „veřejné mraky“. Navzdory obrovským výhodám, které výše popsané virtualizační a kontejnerizační technologie poskytují, stále potřebujeme výpočetní zdroje. Firmy si pořizují drahé servery nebo pronajímají datová centra, ale v tomto případě je nutné provést propočty (někdy nereálné), kolik zdrojů budeme potřebovat, zda je budeme využívat 24 hodin denně, 7 dní v týdnu a k jakým účelům. Produkce například vyžaduje server běžící XNUMX/XNUMX, ale potřebujeme podobné zdroje pro testování mimo pracovní dobu? Záleží také na typu prováděného testování. Příkladem mohou být zátěžové/zátěžové testy, které plánujeme spustit v mimopracovní době, abychom získali výsledky následující den. Rozhodně však není vyžadována nepřetržitá dostupnost serveru pro komplexní automatizované testy a zejména ne pro prostředí ručního testování. Pro takové situace by bylo dobré získat na požádání tolik zdrojů, kolik je potřeba, využít je a přestat platit, když už nebudou potřeba. Navíc by bylo skvělé získat je okamžitě pomocí několika kliknutí myší nebo spuštěním několika skriptů. K tomu slouží veřejné cloudy. Podívejme se na definici:
„Veřejný cloud je definován jako výpočetní služby nabízené poskytovateli třetích stran přes veřejný internet a zpřístupňují je každému, kdo je chce používat nebo si je zakoupit. Mohou být zdarma nebo prodávané na vyžádání, což umožňuje zákazníkům platit pouze za použití za cykly CPU, úložiště nebo šířku pásma, které spotřebují."
Existuje názor, že veřejné cloudy jsou drahé. Jejich klíčovou myšlenkou je ale snížení firemních nákladů. Jak již bylo zmíněno dříve, veřejné cloudy vám umožňují získávat zdroje na vyžádání a platit pouze za dobu, po kterou je používáte. Někdy také zapomínáme, že zaměstnanci dostávají platy a odborníci jsou také drahým zdrojem. Je třeba vzít v úvahu, že veřejné cloudy výrazně usnadňují podporu infrastruktury, což umožňuje inženýrům soustředit se na důležitější úkoly.
Hodnota pro infrastrukturu automatizace
Jaké konkrétní zdroje potřebujeme pro end-to-end testy uživatelského rozhraní? V podstatě se jedná o virtuální stroje nebo clustery (o Kubernetes si povíme v další části) pro běh prohlížečů a emulátorů. Čím více prohlížečů a emulátorů chceme současně provozovat, tím více CPU a paměti vyžaduje a tím více peněz za to musíme zaplatit. Veřejné cloudy nám tedy v kontextu automatizace testování umožňují spouštět velké množství (100, 200, 1000...) prohlížečů/emulátorů na vyžádání, získávat výsledky testů co nejrychleji a přestat platit za tak šíleně náročné Napájení.
Nejoblíbenějšími poskytovateli cloudu jsou Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Návod obsahuje příklady použití GCP, ale obecně nezáleží na tom, co používáte pro úlohy automatizace. Všechny poskytují přibližně stejné funkce. Při výběru poskytovatele se management obvykle zaměřuje na celkovou infrastrukturu a obchodní požadavky společnosti, což je nad rámec tohoto článku. Pro automatizační inženýry bude zajímavější porovnat využití cloudových poskytovatelů s využitím cloudových platforem speciálně pro testovací účely, jako jsou Sauce Labs, BrowserStack, BitBar a tak dále. Tak do toho taky! Sauce Labs je podle mě nejznámější cloudová testovací farma, proto jsem ji použil pro srovnání.
GCP vs Sauce Labs pro účely automatizace:
Představme si, že potřebujeme spustit 8 webových testů a 8 testů Androidu současně. K tomu použijeme GCP a spustíme 2 virtuální stroje se Selenoidem. Na prvním z nich zvedneme 8 kontejnerů s prohlížeči. Na druhém je 8 kontejnerů s emulátory. Pojďme se podívat na ceny:
Ke spuštění jednoho kontejneru s Chrome potřebujeme n1-standard-1 auto. V případě Androidu tomu tak bude n1-standard-4 pro jeden emulátor. Ve skutečnosti je flexibilnější a levnější způsob nastavení konkrétních uživatelských hodnot pro CPU/paměť, ale v tuto chvíli to není důležité pro srovnání se Sauce Labs.
A zde jsou tarify za používání Sauce Labs:
Věřím, že jste si již všimli rozdílu, ale přesto poskytnu tabulku s výpočty pro náš úkol:
Požadované zdroje
Měsíčně
Pracovní doba(8:8–XNUMX:XNUMX)
Pracovní doba+ Preemptivní
GCP pro web
n1-standard-1 x 8 = n1-standard-8
$194.18
23 dní * 12 h * 0.38 = 104.88 $
23 dní * 12 h * 0.08 = 22.08 $
Sauce Labs pro web
Paralelní testy Virtual Cloud8
$1.559
-
-
GCP pro Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 dní * 12 h * 1.52 = 419.52 $
23 dní * 12 h * 0.32 = 88.32 $
Sauce Labs pro Android
Real Device Cloud 8 paralelní testy
$1.999
-
-
Jak vidíte, rozdíl v ceně je obrovský, zvláště pokud spouštíte testy pouze během dvanáctihodinové pracovní doby. Ale můžete ještě více snížit náklady, pokud použijete stroje s preemptem. Co je to?
Preemptivní virtuální počítač je instance, kterou můžete vytvořit a spustit za mnohem nižší cenu než normální instance. Compute Engine však může tyto instance ukončit (preempt), pokud vyžaduje přístup k těmto prostředkům pro jiné úlohy. Preemptovatelné instance jsou nadbytečná kapacita Compute Engine, takže jejich dostupnost se liší podle použití.
Pokud jsou vaše aplikace odolné proti chybám a dokážou odolat možným preempcím instancí, pak mohou preemptovatelné instance výrazně snížit vaše náklady na výpočetní modul. Úlohy dávkového zpracování mohou například běžet na preemptivních instancích. Pokud se některá z těchto instancí během zpracování ukončí, úloha se zpomalí, ale úplně se nezastaví. Preemptibilní instance dokončují vaše úlohy dávkového zpracování, aniž by na vaše stávající instance nanášely další zátěž a aniž byste museli platit plnou cenu za další normální instance.
A stále není konec! Ve skutečnosti jsem si jistý, že nikdo neprovádí testy 12 hodin bez přestávky. A pokud ano, můžete automaticky spouštět a zastavovat virtuální stroje, když nejsou potřeba. Skutečná doba používání může být zkrácena na 6 hodin denně. Poté se platba v kontextu našeho úkolu sníží na 11 $ měsíčně pro 8 prohlížečů. Není to úžasné? Ale u preemptibilních strojů musíme být opatrní a připraveni na přerušení a nestabilitu, i když tyto situace lze zajistit a řešit softwarově. Stojí to za to!
Ale v žádném případě neříkám „nikdy nepoužívejte cloudové testovací farmy“. Mají řadu výhod. Za prvé, nejde jen o virtuální stroj, ale o plnohodnotné řešení pro automatizaci testování se sadou funkcí hned po vybalení: vzdálený přístup, protokoly, snímky obrazovky, nahrávání videa, různé prohlížeče a fyzická mobilní zařízení. V mnoha situacích to může být zásadní elegantní alternativa. Testovací platformy jsou užitečné zejména pro automatizaci IOS, kdy veřejné cloudy mohou nabízet pouze systémy Linux/Windows. O iOS si ale povíme v následujících článcích. Doporučuji se vždy podívat na situaci a vycházet z úkolů: v některých případech je levnější a efektivnější používat veřejné cloudy a jinde se testovací platformy za vynaložené peníze rozhodně vyplatí.
Ilustrace současného stavu infrastruktury
Odkazy k prozkoumání
Podobné nástroje:
6. Orchestr
Stručný popis technologie
Mám dobrou zprávu – jsme téměř u konce článku! V tuto chvíli se naše automatizační infrastruktura skládá z webových testů a testů Androidu, které paralelně spouštíme prostřednictvím GitLab CI pomocí nástrojů s podporou Dockeru: Selenium grid a Selenoid. Kromě toho používáme virtuální stroje vytvořené pomocí GCP k hostování 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ž neprobíhá testování. Je ještě něco, co může zlepšit naši infrastrukturu? Odpověď je ano! Seznamte se s Kubernetes (K8s)!
Nejprve se podívejme, jak spolu souvisí slova orchestrace, cluster a Kubernetes. Na vysoké úrovni je orchestrace systém, který nasazuje a spravuje aplikace. Pro automatizaci testování jsou takovými kontejnerovými aplikacemi Selenová mřížka a Selenoid. Docker a K8 se vzájemně doplňují. První se používá pro nasazení aplikací, druhý pro orchestraci. K8s je zase cluster. Úkolem clusteru je využívat VM jako Nodes, což umožňuje instalovat různé funkcionality, programy a služby v rámci jednoho serveru (clusteru). Pokud některý z uzlů selže, zvednou se další uzly, což zajišťuje nepřerušovaný provoz naší aplikace. Kromě toho má K8s důležitou funkcionalitu související se škálováním, díky které automaticky získáváme optimální množství zdrojů na základě zatížení a nastavených limitů.
Po pravdě řečeno, ruční nasazení Kubernetes od nuly není vůbec triviální úkol. Nechám odkaz na slavný návod "Kubernetes The Hard Way" a pokud máte zájem, můžete si to procvičit. Ale naštěstí existují alternativní metody a nástroje. Nejjednodušší je použít v GCP Google Kubernetes Engine (GKE), který vám umožní získat hotový cluster na pár kliknutí. Doporučuji použít tento přístup k zahájení učení, protože vám umožní soustředit se na učení, jak používat K8 pro vaše úkoly, místo toho, abyste se učili, jak by měly být vnitřní komponenty integrovány dohromady.
Hodnota pro infrastrukturu automatizace
Pojďme se podívat na několik významných funkcí, které K8 poskytuje:
- nasazení aplikací: použití clusteru s více uzly namísto virtuálních počítačů;
- dynamické škálování: snižuje náklady na zdroje, které se používají pouze na vyžádání;
- samoléčení: automatická obnova lusků (v důsledku čehož se obnovují i nádoby);
- zavádění aktualizací a vrácení změn bez prostojů: aktualizace nástrojů, prohlížečů a emulátorů nepřeruší práci současných uživatelů
Ale K8s stále není stříbrná kulka. Abychom pochopili všechny výhody a omezení v kontextu nástrojů, které zvažujeme (Selenium grid, Selenoid), krátce probereme strukturu K8. Cluster obsahuje dva typy uzlů: hlavní uzly a pracovní uzly. Hlavní uzly jsou zodpovědné za správu, nasazení a rozhodování o plánování. Pracovní uzly jsou místa, kde se spouštějí aplikace. Uzly také obsahují běhové prostředí kontejneru. V našem případě je to Docker, který je zodpovědný za operace související s kontejnery. Existují ale například i alternativní řešení. Je důležité pochopit, že škálování nebo samoopravování se nevztahuje přímo na nádoby. To se provádí přidáním/snížením počtu podů, které zase obsahují kontejnery (obvykle jeden kontejner na pod, ale v závislosti na úkolu jich může být více). Hierarchie na vysoké úrovni se skládá z pracovních uzlů, uvnitř kterých jsou pody, uvnitř kterých jsou zvednuté kontejnery.
Funkce škálování je klíčová a lze ji použít jak na uzly v rámci fondu uzlů clusteru, tak na pody v rámci uzlu. Existují 2 typy škálování, které platí pro uzly i pody. První typ je horizontální – ke změně měřítka dochází zvýšením počtu uzlů/podů. Tento typ je výhodnější. Druhý typ je tedy vertikální. Škálování se provádí zvětšením velikosti uzlů/podů, nikoli jejich počtu.
Nyní se podívejme na naše nástroje v kontextu výše uvedených pojmů.
Selenová mřížka
Jak již bylo zmíněno dříve, Selenium grid je velmi oblíbený nástroj a není žádným překvapením, že byl kontejnerizován. Proto není žádným překvapením, že Selenium grid lze nasadit v K8. Příklad, jak to udělat, najdete v oficiálním úložišti K8s. Jako obvykle přikládám odkazy na konec sekce. Kromě toho návod ukazuje, jak to udělat v Terraformu. Jsou zde také pokyny, jak škálovat počet podů, které obsahují kontejnery prohlížeče. Funkce automatického škálování ale v kontextu K8 stále není úplně samozřejmým úkolem. Když jsem začal studovat, nenašel jsem žádný praktický návod ani doporučení. Po několika studiích a experimentech s podporou týmu DevOps jsme zvolili přístup zvedání kontejnerů s potřebnými prohlížeči uvnitř jednoho podu, který je umístěn uvnitř jednoho pracovního uzlu. Tato metoda nám umožňuje aplikovat strategii horizontálního škálování uzlů zvýšením jejich počtu. Doufám, že se to v budoucnu změní a dočkáme se stále více popisů lepších přístupů a hotových řešení, zejména po vydání Selenium grid 4 se změněnou vnitřní architekturou.
selenoid:
Nasazení selenoidů v K8 je aktuálně největším zklamáním. Nejsou kompatibilní. Teoreticky můžeme vytvořit kontejner Selenoid uvnitř podu, ale když Selenoid začne spouštět kontejnery s prohlížeči, budou stále uvnitř stejného podu. To znemožňuje škálování a v důsledku toho se práce Selenoid uvnitř clusteru nebude lišit od práce uvnitř virtuálního stroje. Konec příběhu.
Měsíc:
S vědomím tohoto úzkého hrdla při práci se Selenoidem vydali vývojáři výkonnější nástroj s názvem Moon. Tento nástroj byl původně navržen pro práci s Kubernetes a v důsledku toho může a měla by být použita funkce automatického škálování. Navíc bych řekl, že momentálně ano jediný nástroj ve světě Selenium, který má nativní podporu clusteru K8s ihned po vybalení (již není k dispozici, viz další nástroj ). Klíčové funkce Moon, které poskytují tuto podporu, jsou:
Zcela bez státní příslušnosti. Selenoid ukládá do paměti informace o aktuálně spuštěných relacích prohlížeče. Pokud z nějakého důvodu jeho proces selže — pak jsou všechny spuštěné relace ztraceny. Moon naopak nemá žádný vnitřní stav a lze jej replikovat napříč datovými centry. Relace prohlížeče zůstávají živé, i když jedna nebo více replik vypadne.
Moon je tedy skvělé řešení, ale je tu jeden problém: není zdarma. Cena se odvíjí od počtu sezení. Zdarma můžete spustit pouze 0-4 relace, což není příliš užitečné. Počínaje pátou relací však budete muset zaplatit 5 USD za každou. Situace se může lišit společnost od společnosti, ale v našem případě je používání Moon nesmyslné. Jak jsem popsal výše, můžeme spouštět virtuální počítače se Selenium Grid na vyžádání nebo zvýšit počet uzlů v clusteru. Pro přibližně jeden kanál spustíme 500 prohlížečů a po dokončení testů zastavíme všechny zdroje. Pokud bychom použili Moon, museli bychom platit dalších 500 x 5 = 2500 XNUMX $ měsíčně, bez ohledu na to, jak často provádíme testy. Opět neříkám, že nepoužíváte Moon. Pro vaše úkoly to může být nepostradatelné řešení, například pokud máte ve vaší organizaci mnoho projektů/týmů a potřebujete obrovský společný cluster pro všechny. Jako vždy nechávám na konci odkaz a doporučuji provést všechny potřebné výpočty v kontextu vašeho úkolu.
Callisto: (Pozornost! Toto není v původním článku a je obsaženo pouze v ruském překladu)
Jak jsem řekl, Selenium je velmi oblíbený nástroj a oblast IT se velmi rychle rozvíjí. Zatímco jsem pracoval na překladu, objevil se na webu nový slibný nástroj Callisto (ahoj Cypress a další Selenium zabijáci). Funguje nativně s K8 a umožňuje vám spouštět kontejnery Selenoid v podech, distribuovaných mezi uzly. Vše funguje hned po vybalení, včetně automatického škálování. Fantastické, ale nutno vyzkoušet. Tento nástroj se mi již podařilo nasadit a provést několik experimentů. Ale je příliš brzy na to dělat závěry, po obdržení výsledků na dlouhou vzdálenost možná udělám recenzi v budoucích článcích. Zatím nechávám pouze odkazy pro nezávislý výzkum.
Ilustrace současného stavu infrastruktury
Odkazy k prozkoumání
Podobné nástroje
7. Infrastruktura jako kód (IaC)
Stručný popis technologie
A nyní se dostáváme k poslední části. Obvykle za tuto technologii a související úkoly nenesou odpovědnost technici automatizace. A jsou pro to důvody. Za prvé, v mnoha organizacích jsou problémy s infrastrukturou pod kontrolou oddělení DevOps a vývojové týmy se ve skutečnosti nestarají o to, jak funguje pipeline a jak je třeba podporovat vše, co s tím souvisí. Za druhé, buďme upřímní, praxe Infrastructure as Code (IaC) stále není v mnoha společnostech přijata. Rozhodně se ale stal oblíbeným trendem a je důležité snažit se zapojit do procesů, přístupů a nástrojů s tím spojených. Nebo alespoň zůstat v obraze.
Začněme motivací pro použití tohoto přístupu. Již jsme diskutovali o tom, že ke spuštění testů v GitlabCI budeme potřebovat minimálně prostředky ke spuštění Gitlab Runner. A abychom mohli spouštět kontejnery s prohlížeči/emulátory, musíme si rezervovat virtuální počítač nebo cluster. Kromě testovacích prostředků potřebujeme značné množství kapacity pro podporu vývojových, stagingových, produkčních prostředí, což zahrnuje také databáze, automatické plány, síťové konfigurace, nástroje pro vyrovnávání zátěže, uživatelská práva a tak dále. Klíčovým problémem je úsilí potřebné k podpoře toho všeho. Existuje několik způsobů, jak můžeme provádět změny a zavádět aktualizace. Například v kontextu GCP můžeme použít konzoli uživatelského rozhraní v prohlížeči a provádět všechny akce kliknutím na tlačítka. Alternativou by bylo použití volání API k interakci s cloudovými entitami nebo použití nástroje příkazového řádku gcloud k provedení požadovaných manipulací. Ale s opravdu velkým množstvím různých entit a prvků infrastruktury je obtížné nebo dokonce nemožné provádět všechny operace ručně. Všechny tyto ruční akce jsou navíc nekontrolovatelné. Nemůžeme je odeslat ke kontrole před provedením, používat systém správy verzí a rychle vrátit zpět změny, které vedly k incidentu. K vyřešení takových problémů inženýři vytvořili a vytvořili automatické bash/shell skripty, které nejsou o moc lepší než předchozí metody, protože je nelze tak snadno rychle přečíst, pochopit, udržovat a upravovat procedurálním stylem.
V tomto článku a návodu používám 2 nástroje související s praxí IaC. Jsou to Terraform a Ansible. Někteří lidé se domnívají, že nemá smysl je používat současně, protože jejich funkčnost je podobná a jsou vzájemně zaměnitelné. Faktem ale je, že zpočátku dostávají úplně jiné úkoly. A že by se tyto nástroje měly doplňovat, potvrdili na společné prezentaci vývojáři zastupující HashiCorp a RedHat. Koncepční rozdíl spočívá v tom, že Terraform je zřizovací nástroj pro správu samotných serverů. Zatímco Ansible je nástroj pro správu konfigurace, jehož úkolem je instalovat, konfigurovat a spravovat software na těchto serverech.
Dalším klíčovým rozlišovacím znakem těchto nástrojů je styl kódování. 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 má být dosaženo jako výsledek provedení. Pokud například vytvoříme 10 VM a aplikujeme změny prostřednictvím Terraformu, získáme 10 VM. Pokud skript spustíme znovu, nic se nestane, protože již máme 10 VM a Terraform o tom ví, protože ukládá aktuální stav infrastruktury do stavového souboru. Ale Ansible používá procedurální přístup, a pokud jej požádáte o vytvoření 10 VM, pak při prvním spuštění dostaneme 10 VM, podobně jako Terraform. Ale po restartu už budeme mít 20 VM. Toto je důležitý rozdíl. V procedurálním stylu neukládáme aktuální stav a jednoduše popisujeme sekvenci kroků, které je nutné provést. Samozřejmě můžeme řešit různé situace, přidat několik kontrol na existenci zdrojů a aktuální stav, ale nemá smysl ztrácet čas a vynakládat úsilí na ovládání této logiky. Navíc se tím zvyšuje riziko chyb.
Shrneme-li vše výše uvedené, můžeme dojít k závěru, že Terraform a deklarativní zápis jsou vhodnějším nástrojem pro poskytování serverů. Ale je lepší delegovat práci správy konfigurace na Ansible. S tím mimo, podívejme se na případy použití v kontextu automatizace.
Hodnota pro infrastrukturu automatizace
Jediné, co je zde důležité, je pochopit, že infrastruktura pro automatizaci testování by měla být považována za součást celé infrastruktury společnosti. To znamená, že všechny postupy IaC musí být aplikovány globálně na zdroje celé organizace. Kdo je za to zodpovědný, závisí na vašich procesech. Tým DevOps je v těchto otázkách zkušenější, vidí celý obraz toho, co se děje. Inženýři QA jsou však více zapojeni do procesu automatizace budov a struktury potrubí, což jim umožňuje lépe vidět všechny požadované změny a příležitosti ke zlepšení. Nejlepší možností je spolupracovat, vyměňovat si znalosti a nápady k dosažení očekávaného výsledku.
Zde je několik příkladů použití Terraform a Ansible v kontextu automatizace testování a nástrojů, o kterých jsme hovořili dříve:
1. Popište potřebné charakteristiky a parametry virtuálních počítačů a clusterů pomocí Terraformu.
2. Pomocí Ansible nainstalujte nástroje potřebné pro testování: docker, Selenoid, Selenium Grid a stáhněte si požadované verze prohlížečů/emulátorů.
3. Pomocí Terraformu popište vlastnosti virtuálního počítače, ve kterém bude spuštěn GitLab Runner.
4. Nainstalujte GitLab Runner a potřebné doprovodné nástroje pomocí Ansible, nastavte nastavení a konfigurace.
Ilustrace současného stavu infrastruktury
Odkazy k prozkoumání:
Podobné nástroje
Pojďme si to shrnout!
Krok
Technika
Tools
Hodnota pro infrastrukturu automatizace
1
Místní běh
Node.js, Selenium, Appium
- Nejoblíbenější nástroje pro web a mobily
- Podporuje mnoho jazyků a platforem (včetně Node.js)
2
Systémy pro správu verzí
Git
- Podobné výhody s vývojovým kódem
3
Kontejnerizace
Docker, selenová mřížka, selenoid (web, Android)
- Paralelní běh testů
- Izolovaná prostředí
- Jednoduché, flexibilní upgrady verzí
- Dynamické zastavení nevyužitých zdrojů
- Snadné nastavení
4
CI/CD
Gitlab CI
- Testuje část potrubí
- Rychlá zpětná vazba
- Viditelnost pro celou společnost/tým
5
Cloud platformy
Google Cloud Platform
- Zdroje na vyžádání (platíme pouze v případě potřeby)
- Snadná správa a aktualizace
- Viditelnost a kontrola všech zdrojů
6
Orchestrace
Kubernetes
V kontextu kontejnerů s prohlížeči/emulátory uvnitř modulů:
- Měřítko/automatické škálování
- Samoléčení
- Aktualizace a vrácení zpět 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
- Snadno provádět změny a udržovat
- Plně automatizované
Diagramy myšlenkových map: vývoj infrastruktury
Krok 1: Místní
krok 2: VCS
Krok 3: Kontejnerizace
Krok 4: CI/CD
Krok 5: Cloudové platformy
Krok 6: Orchestr
Krok 7: IaC
Co bude dál?
Tak toto je konec článku. Ale na závěr bych s vámi rád uzavřel nějaké dohody.
Z tvé strany
Jak jsem řekl na začátku, byl bych rád, kdyby byl článek praktický a pomohl vám uplatnit získané znalosti v reálné práci. znovu přidávám.
Ale ani poté se nezastavujte, cvičte, prostudujte si relevantní odkazy a knihy, zjistěte, jak to ve vaší firmě funguje, najděte místa, která lze zlepšit, a zapojte se do toho. Hodně štěstí!
Z mé strany
Už z názvu je vidět, že se jednalo pouze o první díl. Navzdory tomu, že se ukázalo, že je poměrně rozsáhlý, stále zde nejsou pokryta důležitá témata. Ve druhé části se plánuji podívat na infrastrukturu automatizace v kontextu IOS. Vzhledem k omezením společnosti Apple na spouštění simulátorů iOS pouze na systémech macOS je naše nabídka řešení zúžená. Například nemůžeme použít Docker ke spuštění simulátoru nebo veřejné cloudy ke spuštění virtuálních strojů. To ale neznamená, že neexistují jiné alternativy. Pokusím se vás informovat o pokročilých řešeních a moderních nástrojích!
Také jsem nezmínil docela velká témata související s monitoringem. V části 3 se podívám na nejoblíbenější nástroje pro monitorování infrastruktury a na to, jaká data a metriky je třeba vzít v úvahu.
A nakonec. V budoucnu plánuji vydat videokurz o budování testovací infrastruktury a oblíbených nástrojů. V současné době je na internetu poměrně dost 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 otázce opravdu potřebuji zpětnou vazbu, zda bude takový kurz zajímavý a hodnotný pro komunitu testerů a automatizačních inženýrů. Děkuji předem!
Zdroj: www.habr.com