Časť 1: Web/Android
Poznámka: tento článok je prekladom pôvodného článku do ruštiny Všetky ilustrácie, odkazy, citácie a výrazy sú však zachované v pôvodnom jazyku, aby sa predišlo skresleniu významu pri preklade do ruštiny. Prajem príjemné učenie!
V súčasnosti je špecialita DevOps jednou z najžiadanejších v IT priemysle. Ak otvoríte obľúbené stránky na hľadanie zamestnania a filtrujete podľa platu, uvidíte, že pracovné miesta súvisiace s DevOps sú na začiatku zoznamu. Je však dôležité pochopiť, že sa to týka najmä pozície „Senior“, čo znamená, že kandidát má vysokú úroveň zručností, znalostí technológie a nástrojov. S tým je spojená aj vysoká miera zodpovednosti spojená s nepretržitým chodom výroby. Začali sme však zabúdať, čo je DevOps. Spočiatku to nebola žiadna konkrétna osoba alebo oddelenie. Ak budeme hľadať definície tohto pojmu, nájdeme veľa krásnych a správnych podstatných mien, ako napríklad metodológia, praktiky, kultúrna filozofia, skupina pojmov atď.
Mojou špecializáciou je inžinier pre automatizáciu testov (QA automation engineer), no verím, že by sa to nemalo spájať len s písaním autotestov alebo vývojom architektúry testovacieho rámca. V roku 2020 je nevyhnutná aj znalosť automatizačnej infraštruktúry. To vám umožňuje organizovať proces automatizácie sami, od spúšťania testov až po poskytovanie výsledkov všetkým zainteresovaným stranám v súlade s vašimi cieľmi. V dôsledku toho sú zručnosti DevOps nevyhnutné na vykonanie úlohy. A to všetko je dobré, ale bohužiaľ je tu problém (spoiler: tento článok sa pokúša tento problém zjednodušiť). Ide o to, že DevOps je ťažké. A to je zrejmé, pretože spoločnosti nebudú platiť veľa za niečo, čo sa dá ľahko urobiť... Vo svete DevOps existuje veľké množstvo nástrojov, termínov a praktík, ktoré si treba osvojiť. To je obzvlášť ťažké na začiatku kariéry a závisí to od nahromadených technických skúseností.
Zdroj:
Tu pravdepodobne skončíme s úvodnou časťou a zameriame sa na účel tohto článku.
O čom je tento článok?
V tomto článku sa podelím o svoje skúsenosti s budovaním infraštruktúry automatizácie testov. Na internete je veľa zdrojov informácií o rôznych nástrojoch a ich používaní, no rád by som sa na ne pozrel čisto v kontexte automatizácie. Verím, že mnohí automatizační inžinieri sú oboznámení so situáciou, keď nikto okrem vás nespúšťa vyvinuté testy ani sa nestará o ich údržbu. Výsledkom je, že testy sú zastarané a musíte tráviť čas ich aktualizáciou. Na začiatku kariéry to môže byť opäť dosť náročná úloha: múdro sa rozhodnúť, ktoré nástroje by mali pomôcť odstrániť daný problém, ako ich vybrať, nakonfigurovať a udržiavať. Niektorí testeri sa obracajú o pomoc na DevOps (ľudí) a povedzme si úprimne, tento prístup funguje. V mnohých prípadoch to môže byť jediná možnosť, pretože nemáme prehľad o všetkých závislostiach. Ale ako vieme, DevOps sú veľmi vyťažení chalani, pretože musia myslieť na celú firemnú infraštruktúru, nasadenie, monitoring, mikroslužby a ďalšie podobné úlohy v závislosti od organizácie/tímu. Ako to už zvyčajne býva, automatizácia nie je prioritou. V takom prípade sa musíme snažiť urobiť z našej strany všetko možné od začiatku do konca. To zníži závislosti, urýchli pracovný tok, zlepší naše zručnosti a umožní nám vidieť väčší obraz toho, čo sa deje.
Článok predstavuje najobľúbenejšie a najpopulárnejšie nástroje a ukazuje, ako ich použiť na vybudovanie automatizačnej infraštruktúry krok za krokom. Každá skupina je zastúpená nástrojmi, ktoré boli testované osobnou skúsenosťou. To však neznamená, že musíte použiť to isté. Samotné nástroje nie sú dôležité, objavujú sa a zastarávajú. Našou inžinierskou úlohou je pochopiť základné princípy: prečo potrebujeme túto skupinu nástrojov a aké pracovné problémy môžeme s ich pomocou vyriešiť. Preto na konci každej sekcie nechávam odkazy na podobné nástroje, ktoré možno použiť vo vašej organizácii.
Čo nie je v tomto článku
Ešte raz zopakujem, že článok nie je o konkrétnych nástrojoch, takže tam nebudú žiadne vložky kódu z dokumentácie a popisy konkrétnych príkazov. Ale na konci každej časti nechávam odkazy na podrobné štúdium.
Deje sa tak preto, lebo:
- tento materiál sa dá veľmi ľahko nájsť v rôznych zdrojoch (dokumentácia, knihy, video kurzy);
- ak začneme ísť hlbšie, budeme musieť napísať 10, 20, 30 častí tohto článku (pričom plány sú 2-3);
- Len nechcem strácať čas, pretože možno budete chcieť použiť iné nástroje na dosiahnutie rovnakých cieľov.
Prax
Naozaj by som chcel, aby bol tento materiál užitočný pre každého čitateľa, a nie len prečítaný a zabudnutý. V každom štúdiu je prax veľmi dôležitou súčasťou. Na toto som sa pripravil. Čaká na vás aj domáca úloha, aby ste sa uistili, že bezmyšlienkovite nekopírujete riadky vykonávaných príkazov.
Plán
Krok
Technológia
náradie
1
Lokálne spustenie (pripravte si webové / androidové demo testy a spustite ich lokálne)
Node.js, Selén, Appium
2
Systémy kontroly verzií
ísť
3
Kontajnerizácia
Docker, Selenium grid, Selenoid (web, Android)
4
CI/CD
Gitlab CI
5
Cloud platformy
Google Cloud Platform
6
Orchestration
Kubernetes
7
Infraštruktúra ako kód (IaC)
Terraform, Ansible
Štruktúra každej sekcie
Aby bol príbeh jasný, každá časť je opísaná podľa nasledujúcej osnovy:
- stručný popis technológie,
- hodnota pre automatizačnú infraštruktúru,
- znázornenie súčasného stavu infraštruktúry,
- odkazy na štúdium,
- podobné nástroje.
1. Spustite testy lokálne
Stručný popis technológie
Toto je len prípravný krok na lokálne spustenie demo testov a overenie ich úspešnosti. V praktickej časti je použitý Node.js, ale programovací jazyk a platforma tiež nie sú dôležité a môžete použiť tie, ktoré sa používajú vo vašej firme.
Ako automatizačné nástroje však odporúčam používať Selenium WebDriver pre webové platformy, respektíve Appium pre platformu Android, keďže v ďalších krokoch použijeme obrázky Docker, ktoré sú prispôsobené práve na prácu s týmito nástrojmi. Navyše, vzhľadom na pracovné požiadavky, sú tieto nástroje na trhu najžiadanejšie.
Ako ste si mohli všimnúť, berieme do úvahy iba webové testy a testy Androidu. Bohužiaľ, iOS je úplne iný príbeh (vďaka Apple). V nasledujúcich častiach plánujem predstaviť riešenia a postupy súvisiace so systémom IOS.
Hodnota pre automatizačnú infraštruktúru
Z hľadiska infraštruktúry neprináša lokálne beh žiadnu hodnotu. Kontrolujete iba to, že testy bežia na lokálnom počítači v lokálnych prehliadačoch a simulátoroch. Ale v každom prípade je to nevyhnutný východiskový bod.
Ilustrácia súčasného stavu infraštruktúry
Odkazy na preskúmanie
Podobné nástroje
- akýkoľvek programovací jazyk, ktorý sa vám páči, v spojení s testami Selenium/Appium;
- akékoľvek testy;
- akýkoľvek testovací bežec.
2. Systémy na kontrolu verzií (Git)
Stručný popis technológie
Pre nikoho nebude veľkým odhalením, ak poviem, že kontrola verzií je mimoriadne dôležitou súčasťou vývoja v tíme aj individuálne. Na základe rôznych zdrojov možno s istotou povedať, že Git je najobľúbenejším zástupcom. Systém správy verzií poskytuje mnoho výhod, ako je zdieľanie kódu, ukladanie verzií, obnovenie do predchádzajúcich pobočiek, monitorovanie histórie projektu a zálohy. Nebudeme podrobne rozoberať každý bod, pretože som si istý, že ho dobre poznáte a používate ho pri svojej každodennej práci. Ale ak zrazu nie, potom odporúčam prerušiť čítanie tohto článku a vyplniť túto medzeru čo najskôr.
Hodnota pre automatizačnú infraštruktúru
A tu si môžete položiť rozumnú otázku: „Prečo nám hovorí o Git? Každý to vie a používa to ako pre vývojový kód, tak pre automatický testovací kód.“ Budete mať úplnú pravdu, ale v tomto článku hovoríme o infraštruktúre a táto časť slúži ako náhľad na časť 7: „Infraštruktúra ako kód (IaC)“. Pre nás to znamená, že celá infraštruktúra vrátane testovania je popísaná vo forme kódu, takže môžeme na ňu aplikovať aj verzovacie systémy a získať podobné výhody ako pri vývojovom a automatizačnom kóde.
Na IaC sa pozrieme podrobnejšie v 7. kroku, ale aj teraz môžete začať používať Git lokálne vytvorením lokálneho úložiska. Celkový obraz sa rozšíri, keď do infraštruktúry pridáme vzdialené úložisko.
Ilustrácia súčasného stavu infraštruktúry
Odkazy na preskúmanie
Podobné nástroje
3. Kontajnerizácia (Docker)
Stručný popis technológie
Aby sme demonštrovali, ako kontajnerizácia zmenila pravidlá hry, vráťme sa v čase o niekoľko desaťročí späť. Vtedy ľudia kupovali a používali serverové stroje na spúšťanie aplikácií. Vo väčšine prípadov však požadované zdroje na spustenie neboli vopred známe. V dôsledku toho spoločnosti míňali peniaze na nákup drahých a výkonných serverov, ale časť tejto kapacity nebola úplne využitá.
Ďalším stupňom evolúcie boli virtuálne stroje (VM), ktoré vyriešili problém plytvania peniazmi za nevyužité zdroje. Táto technológia umožnila spúšťať aplikácie nezávisle na sebe v rámci toho istého servera a prideľovala úplne izolovaný priestor. Ale, bohužiaľ, každá technológia má svoje nevýhody. Spustenie VM vyžaduje úplný operačný systém, ktorý spotrebúva CPU, RAM, úložisko a v závislosti od OS treba brať do úvahy aj náklady na licencie. Tieto faktory ovplyvňujú rýchlosť načítania a sťažujú prenosnosť.
A teraz sa dostávame ku kontajnerovaniu. Táto technológia opäť rieši predchádzajúci problém, pretože kontajnery nepoužívajú plný OS, čo uvoľňuje veľké množstvo zdrojov a poskytuje rýchle a flexibilné riešenie prenosnosti.
Samozrejme, technológia kontajnerovania nie je žiadnou novinkou a prvýkrát bola predstavená koncom 70. rokov. V tých dňoch sa uskutočnilo veľa výskumov, vývoja a pokusov. Ale bol to Docker, ktorý túto technológiu prispôsobil a urobil ju ľahko dostupnú pre masy. V dnešnej dobe, keď hovoríme o kontajneroch, máme vo väčšine prípadov na mysli Docker. Keď hovoríme o kontajneroch Docker, máme na mysli kontajnery Linux. Na spustenie kontajnerov môžeme použiť systémy Windows a macOS, ale je dôležité pochopiť, že v tomto prípade sa objaví ďalšia vrstva. Napríklad Docker na Macu ticho spúšťa kontajnery vo vnútri ľahkého Linuxového VM. K tejto téme sa vrátime, keď budeme diskutovať o spustení emulátorov Androidu v kontajneroch, takže tu je veľmi dôležitá nuansa, ktorú je potrebné podrobnejšie prediskutovať.
Hodnota pre automatizačnú infraštruktúru
Zistili sme, že kontajnerizácia a Docker sú v pohode. Pozrime sa na to v kontexte automatizácie, pretože každý nástroj alebo technológia potrebuje vyriešiť nejaký problém. Načrtneme zjavné problémy automatizácie testov v kontexte testov používateľského rozhrania:
- obrovské množstvo závislostí pri inštalácii Selenium a najmä Appium;
- problémy s kompatibilitou medzi verziami prehliadačov, simulátorov a ovládačov;
- nedostatok izolovaného priestoru pre prehliadače/simulátory, čo je obzvlášť dôležité pre paralelný chod;
- náročné na správu a údržbu, ak potrebujete súčasne spustiť 10, 50, 100 alebo dokonca 1000 XNUMX prehliadačov.
Ale keďže Selenium je najobľúbenejší automatizačný nástroj a Docker je najobľúbenejší kontajnerový nástroj, nemalo by byť prekvapením, že sa ich niekto pokúsil skombinovať a vytvoriť tak výkonný nástroj na riešenie vyššie spomínaných problémov. Zvážme takéto riešenia podrobnejšie.
Selénová mriežka v doku
Tento nástroj je najpopulárnejší vo svete Selenium na spustenie viacerých prehliadačov na viacerých počítačoch a ich správu z centrálneho rozbočovača. Ak chcete začať, musíte zaregistrovať aspoň 2 časti: Hub a Node(y). Hub je centrálny uzol, ktorý prijíma všetky požiadavky z testov a distribuuje ich do príslušných uzlov. Pre každý Node môžeme nakonfigurovať špecifickú konfiguráciu, napríklad zadaním požadovaného prehliadača a jeho verzie. Stále sa však musíme sami postarať o kompatibilné ovládače prehliadačov a nainštalovať ich na požadované Nody. Z tohto dôvodu sa Selenium grid nepoužíva vo svojej čistej forme, okrem prípadov, keď potrebujeme pracovať s prehliadačmi, ktoré nie je možné nainštalovať na OS Linux. Vo všetkých ostatných prípadoch by výrazne flexibilným a správnym riešením bolo použitie obrázkov Docker na spustenie rozbočovača a uzlov Selenium grid. Tento prístup výrazne zjednodušuje správu uzlov, pretože si môžeme vybrať požadovaný obrázok s kompatibilnými verziami prehliadačov a už nainštalovanými ovládačmi.
Napriek negatívnym hodnoteniam stability, najmä pri paralelnom spustení veľkého počtu uzlov, je Selenium grid stále najobľúbenejším nástrojom na paralelné spustenie testov Selenium. Je dôležité poznamenať, že v open-source sa neustále objavujú rôzne vylepšenia a úpravy tohto nástroja, ktoré bojujú s rôznymi úzkymi miestami.
Selenoid pre web
Tento nástroj je prelomom vo svete Selenium, pretože funguje hneď po vybalení z krabice a výrazne uľahčil život mnohým automatizačným inžinierom. V prvom rade nejde o ďalšiu úpravu Selénovej mriežky. Namiesto toho vývojári vytvorili úplne novú verziu Selenium Hub v Golang, ktorá v kombinácii s odľahčenými obrázkami Docker pre rôzne prehliadače dala impulz vývoju automatizácie testov. Navyše v prípade Selenium Grid musíme vopred určiť všetky požadované prehliadače a ich verzie, čo pri práci len s jedným prehliadačom nie je problém. Ale pokiaľ ide o viacero podporovaných prehliadačov, Selenoid je riešením číslo jedna vďaka svojej funkcii „prehliadač na požiadanie“. Všetko, čo sa od nás vyžaduje, je vopred stiahnuť potrebné obrázky pomocou prehliadačov a aktualizovať konfiguračný súbor, s ktorým Selenoid interaguje. Keď Selenoid dostane požiadavku z testov, automaticky spustí požadovaný kontajner s požadovaným prehliadačom. Po dokončení testu Selenoid zruší kontajner, čím uvoľní zdroje pre budúce požiadavky. Tento prístup úplne odstraňuje dobre známy problém „degradácie uzlov“, s ktorým sa často stretávame v mriežke Selenium.
Ale, bohužiaľ, Selenoid stále nie je strieborná guľka. Dostali sme funkciu „prehliadač na požiadanie“, ale funkcia „zdroje na požiadanie“ stále nie je k dispozícii. Ak chcete použiť Selenoid, musíme ho nasadiť na fyzický hardvér alebo na VM, čo znamená, že musíme vopred vedieť, koľko zdrojov je potrebné alokovať. Myslím, že to nie je problém pre malé projekty, ktoré bežia paralelne s 10, 20 alebo dokonca 30 prehliadačmi. Ale čo ak potrebujeme 100, 500, 1000 a viac? Nemá zmysel neustále udržiavať a platiť za toľko zdrojov. V častiach 5 a 6 tohto článku budeme diskutovať o riešeniach, ktoré vám umožňujú škálovať a tým výrazne znížiť náklady spoločnosti.
Selenoid pre Android
Po úspechu Selenoidu ako nástroja na automatizáciu webu chceli ľudia niečo podobné pre Android. A stalo sa – Selenoid bol vydaný s podporou Androidu. Z pohľadu používateľa na vysokej úrovni je princíp fungovania podobný ako pri automatizácii webu. Jediný rozdiel je v tom, že namiesto kontajnerov prehliadača Selenoid spúšťa kontajnery emulátora Android. Podľa môjho názoru je to momentálne najvýkonnejší bezplatný nástroj na paralelné spustenie testov Androidu.
Naozaj by som nerád hovoril o negatívnych aspektoch tohto nástroja, pretože sa mi naozaj páči. Stále však existujú rovnaké nevýhody, ktoré sa vzťahujú na automatizáciu webu a sú spojené so škálovaním. Okrem toho musíme hovoriť o jednom obmedzení, ktoré môže byť prekvapením, ak nástroj nastavujeme prvýkrát. Na spustenie obrazov Androidu potrebujeme fyzický počítač alebo VM s podporou vnorenej virtualizácie. V návode ukážem, ako to povoliť na virtuálnom počítači so systémom Linux. Ak ste však používateľom macOS a chcete Selenoid nasadiť lokálne, nebude možné spustiť testy Androidu. Ale vždy môžete spustiť Linux VM lokálne s nakonfigurovanou „vnorenou virtualizáciou“ a nasadiť Selenoid vo vnútri.
Ilustrácia súčasného stavu infraštruktúry
V kontexte tohto článku pridáme 2 nástroje na ilustráciu infraštruktúry. Ide o Selenium grid pre webové testy a Selenoid pre Android testy. V návode na GitHub vám tiež ukážem, ako používať Selenoid na spustenie webových testov.
Odkazy na preskúmanie
Podobné nástroje
- Existujú aj iné nástroje kontajnerizácie, ale Docker je najobľúbenejší. Ak chcete vyskúšať niečo iné, majte na pamäti, že nástroje, ktoré sme prebrali na paralelné spustenie testov Selenium, nebudú hneď po vybalení fungovať.
- Ako už bolo povedané, existuje veľa modifikácií selénovej mriežky, napr..
4.CI/CD
Stručný popis technológie
Postup nepretržitej integrácie je vo vývoji pomerne populárny a je na rovnakej úrovni ako systémy na správu verzií. Napriek tomu mám pocit, že v terminológii panuje zmätok. V tomto odseku by som rád popísal 3 modifikácie tejto technológie z môjho pohľadu. Na internete nájdete veľa článkov s rôznymi výkladmi a je úplne normálne, ak sa váš názor líši. Najdôležitejšie je, že ste s kolegami na rovnakej vlne.
Existujú teda 3 pojmy: CI – kontinuálna integrácia, CD – kontinuálne doručovanie a opäť CD – kontinuálne nasadzovanie. (Nižšie budem tieto výrazy používať v angličtine). Každá modifikácia pridáva do vášho vývojového kanála niekoľko ďalších krokov. Ale slovo nepretržitý (kontinuálne) je najdôležitejšia vec. V tomto kontexte máme na mysli niečo, čo sa deje od začiatku do konca, bez prerušenia alebo manuálneho zásahu. Pozrime sa v tomto kontexte na CI & CD a CD.
- Nepretržitá integrácia toto je prvý krok evolúcie. Po odoslaní nového kódu na server očakávame rýchlu spätnú väzbu, že naše zmeny sú v poriadku. CI zvyčajne zahŕňa spustenie nástrojov na analýzu statického kódu a testy jednotiek/interných API. To nám umožňuje získať informácie o našom kóde v priebehu niekoľkých sekúnd/minút.
- Nepretržité dodávanie je pokročilejší krok, kde spúšťame integračné/UI testy. V tejto fáze však nedosahujeme výsledky tak rýchlo ako pri CI. Po prvé, dokončenie týchto typov testov trvá dlhšie. Po druhé, pred spustením musíme nasadiť naše zmeny do testovacieho/predstavovacieho prostredia. Navyše, ak hovoríme o mobilnom vývoji, potom sa objaví ďalší krok na vytvorenie zostavy našej aplikácie.
- Nepretržité nasadenie predpokladá, že naše zmeny automaticky uvoľníme do výroby, ak prešli všetkými akceptačnými testami v predchádzajúcich fázach. Okrem toho môžete po fáze vydania nakonfigurovať rôzne fázy, ako je napríklad spustenie testov dymu vo výrobe a zhromažďovanie záujmových metrík. Nepretržité nasadzovanie je možné len s dobrým pokrytím automatickými testami. Ak sú potrebné nejaké manuálne zásahy vrátane testovania, potom to už nie je Nepretržitý (nepretržité). Potom môžeme povedať, že náš plynovod je v súlade iba s praxou nepretržitého doručovania.
Hodnota pre automatizačnú infraštruktúru
V tejto časti by som mal objasniť, že keď hovoríme o end-to-end testoch používateľského rozhrania, znamená to, že by sme mali nasadiť naše zmeny a súvisiace služby do testovacích prostredí. Nepretržitá integrácia – proces nie je pre túto úlohu použiteľný a musíme sa postarať o implementáciu aspoň postupov nepretržitého doručovania. Continuous Deployment má zmysel aj v kontexte testov používateľského rozhrania, ak ich budeme spúšťať v produkcii.
A predtým, ako sa pozrieme na ilustráciu zmeny architektúry, chcem povedať pár slov o GitLab CI. Na rozdiel od iných nástrojov CI/CD poskytuje GitLab vzdialené úložisko a mnoho ďalších doplnkových funkcií. GitLab je teda viac ako CI. Zahŕňa správu zdrojového kódu, agilnú správu, kanály CI/CD, protokolovacie nástroje a zber metrík hneď po vybalení. Architektúra GitLab pozostáva z Gitlab CI/CD a GitLab Runner. Tu je krátky popis z oficiálnej stránky:
Gitlab CI/CD je webová aplikácia s API, ktorá ukladá svoj stav do databázy, spravuje projekty/zostavy a poskytuje používateľské rozhranie. GitLab Runner je aplikácia, ktorá spracováva zostavy. Dá sa nasadiť samostatne a funguje s GitLab CI/CD cez API. Na spustenie testov potrebujete inštanciu Gitlabu aj Runner.
Ilustrácia súčasného stavu infraštruktúry
Odkazy na preskúmanie
Podobné nástroje
- A veľa ďalších
5. Cloudové platformy
Stručný popis technológie
V tejto časti budeme hovoriť o populárnom trende nazývanom „verejné oblaky“. Napriek obrovským výhodám, ktoré poskytujú vyššie opísané technológie virtualizácie a kontajnerovania, stále potrebujeme výpočtové zdroje. Firmy si kupujú drahé servery alebo prenajímajú dátové centrá, no v tomto prípade je potrebné urobiť prepočty (niekedy až nereálne), koľko zdrojov budeme potrebovať, či ich budeme využívať 24 hodín denne, 7 dní v týždni a na aké účely. Napríklad produkcia vyžaduje server bežiaci XNUMX hodín denne, XNUMX dní v týždni, ale potrebujeme podobné zdroje na testovanie mimo pracovného času? Závisí to aj od typu vykonávaného testovania. Príkladom môžu byť záťažové/záťažové testy, ktoré plánujeme spustiť počas mimopracovných hodín, aby sme získali výsledky nasledujúci deň. Nepretržitá dostupnosť servera sa však rozhodne nevyžaduje pre komplexné automatizované testy a najmä nie pre prostredia manuálneho testovania. Pre takéto situácie by bolo dobré na požiadanie získať toľko zdrojov, koľko je potrebné, použiť ich a prestať platiť, keď už nebudú potrebné. Okrem toho by bolo skvelé získať ich okamžite pomocou niekoľkých kliknutí myšou alebo spustením niekoľkých skriptov. Na to slúžia verejné cloudy. Pozrime sa na definíciu:
„Verejný cloud je definovaný ako výpočtové služby, ktoré ponúkajú poskytovatelia tretích strán cez verejný internet a sprístupňujú ich každému, kto ich chce používať alebo si ich kúpiť. Môžu byť bezplatné alebo predávané na požiadanie, čo umožňuje zákazníkom platiť iba za použitie za cykly CPU, úložisko alebo šírku pásma, ktoré spotrebujú."
Existuje názor, že verejné cloudy sú drahé. Ich kľúčovou myšlienkou je však zníženie nákladov spoločnosti. Ako už bolo spomenuté, verejné cloudy vám umožňujú získať zdroje na požiadanie a platiť len za čas, počas ktorého ich používate. Niekedy tiež zabúdame, že zamestnanci dostávajú platy a odborníci sú tiež drahým zdrojom. Je potrebné vziať do úvahy, že verejné cloudy výrazne uľahčujú podporu infraštruktúry, čo umožňuje inžinierom sústrediť sa na dôležitejšie úlohy.
Hodnota pre automatizačnú infraštruktúru
Aké konkrétne zdroje potrebujeme na komplexné testy používateľského rozhrania? V podstate ide o virtuálne stroje alebo klastre (o Kubernetes si povieme v ďalšej časti) na spustenie prehliadačov a emulátorov. Čím viac prehliadačov a emulátorov chceme spustiť súčasne, tým viac procesora a pamäte vyžaduje a tým viac peňazí za to musíme zaplatiť. Verejné cloudy nám teda v kontexte automatizácie testovania umožňujú spustiť veľké množstvo (100, 200, 1000 XNUMX...) prehliadačov/emulátorov na požiadanie, získať výsledky testov čo najrýchlejšie a prestať platiť za takéto šialene náročné moc.
Najpopulárnejšími poskytovateľmi cloudu sú Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Táto príručka poskytuje príklady používania GCP, ale vo všeobecnosti nezáleží na tom, čo používate na úlohy automatizácie. Všetky poskytujú približne rovnakú funkčnosť. Pri výbere poskytovateľa sa manažment zvyčajne zameriava na celú infraštruktúru a obchodné požiadavky spoločnosti, čo je nad rámec tohto článku. Pre automatizačných inžinierov bude zaujímavejšie porovnať využitie cloudových poskytovateľov s využitím cloudových platforiem špeciálne na testovacie účely, ako sú Sauce Labs, BrowserStack, BitBar a pod. Tak poďme na to tiež! Sauce Labs je podľa mňa najznámejšia cloudová testovacia farma, a preto som ju použil na porovnanie.
GCP vs Sauce Labs na účely automatizácie:
Predstavme si, že potrebujeme súčasne spustiť 8 webových testov a 8 testov Androidu. Na to použijeme GCP a spustíme 2 virtuálne stroje so Selenoidom. Na prvom vytvoríme 8 kontajnerov s prehliadačmi. Na druhom je 8 kontajnerov s emulátormi. Poďme sa pozrieť na ceny:
Na spustenie jedného kontajnera s prehliadačom Chrome potrebujeme n1-štandard-1 auto. V prípade Androidu to tak bude n1-štandard-4 pre jeden emulátor. V skutočnosti je flexibilnejším a lacnejším spôsobom nastavenie špecifických užívateľských hodnôt pre CPU/Memory, ale v súčasnosti to nie je dôležité pre porovnanie so Sauce Labs.
A tu sú tarify za používanie Sauce Labs:
Verím, že ste si už všimli rozdiel, ale stále poskytnem tabuľku s výpočtami pre našu úlohu:
Požadované zdroje
Mesačne
Pracovný čas(8:8 – XNUMX:XNUMX)
Pracovný čas+ Preddavok
GCP pre web
n1-štandard-1 x 8 = n1-štandard-8
$194.18
23 dní * 12 hodín * 0.38 = 104.88 USD
23 dní * 12 hodín * 0.08 = 22.08 USD
Sauce Labs pre web
Virtuálne Cloud8 paralelné testy
$1.559
-
-
GCP pre Android
n1-štandard-4 x 8: n1-štandard-16
$776.72
23 dní * 12 hodín * 1.52 = 419.52 USD
23 dní * 12 hodín * 0.32 = 88.32 USD
Sauce Labs pre Android
Real Device Cloud 8 paralelné testy
$1.999
-
-
Ako vidíte, rozdiel v nákladoch je obrovský, najmä ak testujete iba počas dvanásťhodinového pracovného obdobia. Ale môžete znížiť náklady ešte viac, ak použijete predkupné stroje. Čo je to?
Preemptibilný VM je inštancia, ktorú môžete vytvoriť a spustiť za oveľa nižšiu cenu ako bežné inštancie. Compute Engine však môže tieto inštancie ukončiť (preemgovať), ak vyžaduje prístup k týmto prostriedkom pre iné úlohy. Preemptovateľnými inštanciami sú nadmerná kapacita Compute Engine, takže ich dostupnosť sa líši v závislosti od používania.
Ak sú vaše aplikácie odolné voči chybám a dokážu vydržať možné preempcie inštancií, potom môžu preemptovateľné inštancie výrazne znížiť vaše náklady na Compute Engine. Napríklad úlohy dávkového spracovania môžu bežať na preemptovateľných inštanciách. Ak sa niektoré z týchto inštancií počas spracovania ukončia, úloha sa spomalí, ale nezastaví sa úplne. Preemptibilné inštancie dokončia vaše úlohy dávkového spracovania bez toho, aby na vaše existujúce inštancie priniesli dodatočné pracovné zaťaženie a bez toho, aby ste museli platiť plnú cenu za ďalšie normálne inštancie.
A stále nie je koniec! V skutočnosti som si istý, že nikto nerobí testy 12 hodín bez prestávky. A ak áno, potom môžete automaticky spustiť a zastaviť virtuálne stroje, keď nie sú potrebné. Skutočný čas používania sa môže skrátiť na 6 hodín denne. Potom sa platba v kontexte našej úlohy zníži na 11 USD mesačne pre 8 prehliadačov. Nie je to úžasné? Ale pri preemptovateľných strojoch musíme byť opatrní a pripravení na prerušenia a nestabilitu, hoci tieto situácie je možné zabezpečiť a zvládnuť softvérovo. Stojí to za to!
V žiadnom prípade však nehovorím „nikdy nepoužívajte cloudové testovacie farmy“. Majú množstvo výhod. V prvom rade nejde len o virtuálny stroj, ale o plnohodnotné riešenie automatizácie testov so sadou funkcií hneď po vybalení: vzdialený prístup, protokoly, snímky obrazovky, nahrávanie videa, rôzne prehliadače a fyzické mobilné zariadenia. V mnohých situáciách to môže byť nevyhnutná elegantná alternatíva. Testovacie platformy sú užitočné najmä pre automatizáciu IOS, keď verejné cloudy môžu ponúkať iba systémy Linux/Windows. O iOS si ale povieme až v nasledujúcich článkoch. Odporúčam vždy sa pozrieť na situáciu a vychádzať z úloh: v niektorých prípadoch je lacnejšie a efektívnejšie využívať verejné cloudy a v iných sa testovacie platformy rozhodne oplatí za vynaložené peniaze.
Ilustrácia súčasného stavu infraštruktúry
Odkazy na preskúmanie
Podobné nástroje:
6. Orchester
Stručný popis technológie
Mám dobrú správu – sme takmer na konci článku! V súčasnosti sa naša infraštruktúra automatizácie skladá z webových testov a testov Androidu, ktoré paralelne spúšťame cez GitLab CI pomocou nástrojov s podporou Docker: Selenium grid a Selenoid. Okrem toho používame virtuálne stroje vytvorené prostredníctvom GCP na hosťovanie kontajnerov s prehliadačmi a emulátormi. Aby sme znížili náklady, spúšťame tieto virtuálne stroje len na požiadanie a zastavujeme ich, keď sa nevykonáva testovanie. Existuje ešte niečo, čo môže zlepšiť našu infraštruktúru? Odpoveď je áno! Zoznámte sa s Kubernetes (K8s)!
Najprv sa pozrime na to, ako spolu súvisia slová orchestrácia, klaster a Kubernetes. Na vysokej úrovni je orchestrácia systém, ktorý nasadzuje a spravuje aplikácie. Pre automatizáciu testov sú takýmito kontajnerovými aplikáciami Selenium Grid a Selenoid. Docker a K8 sa navzájom dopĺňajú. Prvý sa používa na nasadenie aplikácií, druhý na orchestráciu. K8s je zase klaster. Úlohou klastra je využívať VM ako uzly, čo umožňuje inštalovať rôzne funkcionality, programy a služby v rámci jedného servera (klastra). Ak niektorý z uzlov zlyhá, zdvihnú sa ďalšie uzly, čo zaisťuje nepretržitú prevádzku našej aplikácie. Okrem toho má K8s dôležitú funkcionalitu súvisiacu so škálovaním, vďaka ktorej automaticky získavame optimálne množstvo zdrojov na základe zaťaženia a nastavených limitov.
V skutočnosti manuálne nasadenie Kubernetes od začiatku nie je vôbec triviálna úloha. Nechám vám odkaz na slávny návod „Kubernetes The Hard Way“ a ak máte záujem, môžete si ho precvičiť. Ale našťastie existujú alternatívne metódy a nástroje. Najjednoduchšie je použiť v GCP Google Kubernetes Engine (GKE), ktorý vám umožní získať hotový klaster niekoľkými kliknutiami. Odporúčam použiť tento prístup na začatie učenia, pretože vám umožní zamerať sa na učenie sa, ako používať K8 pre vaše úlohy, namiesto toho, aby ste sa učili, ako by mali byť interné komponenty integrované.
Hodnota pre automatizačnú infraštruktúru
Poďme sa pozrieť na niekoľko významných funkcií, ktoré K8 poskytuje:
- nasadenie aplikácií: použitie klastra s viacerými uzlami namiesto virtuálnych počítačov;
- dynamické škálovanie: znižuje náklady na zdroje, ktoré sa používajú iba na požiadanie;
- samoliečba: automatické obnovenie strukov (v dôsledku čoho sa obnovia aj nádoby);
- zavádzanie aktualizácií a vrátenie zmien bez prestojov: aktualizácia nástrojov, prehliadačov a emulátorov nepreruší prácu súčasných používateľov
Ale K8s stále nie je strieborná guľka. Aby sme pochopili všetky výhody a obmedzenia v kontexte nástrojov, ktoré zvažujeme (Selenium grid, Selenoid), stručne si rozoberieme štruktúru K8. Klaster obsahuje dva typy uzlov: hlavné uzly a pracovné uzly. Hlavné uzly sú zodpovedné za riadenie, nasadenie a rozhodnutia o plánovaní. Pracovné uzly sú miesta, kde sa spúšťajú aplikácie. Uzly tiež obsahujú prostredie spustenia kontajnera. V našom prípade je to Docker, ktorý je zodpovedný za operácie súvisiace s kontajnermi. Ale sú aj alternatívne riešenia napr. Je dôležité pochopiť, že odstraňovanie vodného kameňa alebo samoopravovanie sa nevzťahuje priamo na nádoby. Toto sa realizuje pridaním/znížením počtu modulov, ktoré zase obsahujú kontajnery (zvyčajne jeden kontajner na modul, ale v závislosti od úlohy ich môže byť aj viac). Hierarchia na vysokej úrovni pozostáva z pracovných uzlov, vo vnútri ktorých sú moduly, v ktorých sú zdvihnuté kontajnery.
Funkcia škálovania je kľúčová a možno ju použiť na oba uzly v rámci skupiny uzlov klastra a pody v rámci uzla. Existujú 2 typy škálovania, ktoré sa vzťahujú na uzly aj pody. Prvý typ je horizontálny – škálovanie nastáva zvýšením počtu uzlov/podov. Tento typ je výhodnejší. Druhý typ je teda vertikálny. Škálovanie sa vykonáva zväčšením veľkosti uzlov/podov a nie ich počtu.
Teraz sa pozrime na naše nástroje v kontexte vyššie uvedených pojmov.
Selénová mriežka
Ako už bolo spomenuté, Selenium grid je veľmi populárny nástroj a nie je prekvapením, že bol kontajnerovaný. Preto nie je žiadnym prekvapením, že mriežka Selenium môže byť nasadená v K8. Príklad, ako to urobiť, nájdete v oficiálnom úložisku K8s. Ako obvykle pripájam odkazy na konci časti. Okrem toho, návod ukazuje, ako to urobiť v Terraforme. Sú tam aj pokyny, ako škálovať počet modulov, ktoré obsahujú kontajnery prehliadača. Ale funkcia automatického škálovania v kontexte K8 stále nie je úplne samozrejmá úloha. Keď som začal študovať, nenašiel som žiadne praktické návody ani odporúčania. Po niekoľkých štúdiách a experimentoch s podporou tímu DevOps sme zvolili prístup zdvíhania kontajnerov s potrebnými prehliadačmi vo vnútri jedného podu, ktorý sa nachádza vo vnútri jedného pracovného uzla. Táto metóda nám umožňuje aplikovať stratégiu horizontálneho škálovania uzlov zvýšením ich počtu. Dúfam, že sa to v budúcnosti zmení a budeme vidieť čoraz viac popisov lepších prístupov a hotových riešení, najmä po vydaní Selenium grid 4 so zmenenou vnútornou architektúrou.
selenoid:
Nasadenie selenoidov v K8 je momentálne najväčším sklamaním. Nie sú kompatibilné. Teoreticky môžeme vytvoriť kontajner Selenoid vo vnútri podu, ale keď Selenoid začne spúšťať kontajnery s prehliadačmi, budú stále v tej istej pod. To znemožňuje škálovanie a v dôsledku toho sa práca Selenoidu v klastri nebude líšiť od práce vo virtuálnom stroji. Koniec príbehu.
Mesiac:
Keďže vývojári poznali túto prekážku pri práci so Selenoidom, vydali výkonnejší nástroj s názvom Moon. Tento nástroj bol pôvodne navrhnutý na prácu s Kubernetes a v dôsledku toho môže a mala by sa použiť funkcia automatického škálovania. Navyše by som povedal, že momentálne áno iba nástroj vo svete Selenium, ktorý má natívnu podporu klastrov K8s hneď po vybalení (už nie je k dispozícii, pozrite si nasledujúci nástroj ). Kľúčové vlastnosti Moon, ktoré poskytujú túto podporu, sú:
Úplne bez štátnej príslušnosti. Selenoid ukladá do pamäte informácie o aktuálne spustených reláciách prehliadača. Ak z nejakého dôvodu jeho proces zlyhá, všetky spustené relácie sa stratia. Moon naopak nemá žiadny vnútorný stav a možno ho replikovať v dátových centrách. Relácie prehliadača zostávajú živé, aj keď jedna alebo viacero replík zlyhá.
Moon je teda skvelé riešenie, ale je tu jeden problém: nie je zadarmo. Cena závisí od počtu sedení. Zadarmo môžete spustiť iba 0-4 relácie, čo nie je obzvlášť užitočné. Od piatej relácie však budete musieť zaplatiť 5 dolárov za každú. Situácia sa môže líšiť od spoločnosti k spoločnosti, ale v našom prípade je používanie Moon zbytočné. Ako som opísal vyššie, virtuálne počítače so Selenium Grid môžeme spúšťať na požiadanie alebo zvýšiť počet uzlov v klastri. Pre približne jeden kanál spustíme 500 prehliadačov a po dokončení testov zastavíme všetky zdroje. Ak by sme použili Moon, museli by sme zaplatiť ďalších 500 x 5 = 2500 XNUMX dolárov mesačne, bez ohľadu na to, ako často vykonávame testy. Opäť nehovorím, že nepoužívajte Moon. Pre vaše úlohy to môže byť nepostrádateľné riešenie, napríklad ak máte v organizácii veľa projektov/tímov a potrebujete obrovský spoločný klaster pre všetkých. Ako vždy nechávam na konci odkaz a odporúčam vykonať všetky potrebné výpočty v kontexte vašej úlohy.
Callisto: (Pozor! Toto nie je v pôvodnom článku a je obsiahnuté iba v ruskom preklade)
Ako som už povedal, Selenium je veľmi populárny nástroj a oblasť IT sa veľmi rýchlo rozvíja. Kým som pracoval na preklade, objavil sa na webe nový sľubný nástroj s názvom Callisto (ahoj Cypress a ďalší Selenium zabijaci). Natívne funguje s K8 a umožňuje vám spúšťať kontajnery Selenoid v podoch, distribuovaných cez uzly. Všetko funguje hneď po vybalení, vrátane automatického škálovania. Fantastické, ale treba vyskúšať. Tento nástroj sa mi už podarilo nasadiť a spustiť niekoľko experimentov. Ale je príliš skoro robiť závery, po získaní výsledkov na veľkú vzdialenosť možno urobím recenziu v budúcich článkoch. Zatiaľ nechávam len odkazy na nezávislý výskum.
Ilustrácia súčasného stavu infraštruktúry
Odkazy na preskúmanie
Podobné nástroje
7. Infraštruktúra ako kód (IaC)
Stručný popis technológie
A teraz sa dostávame k poslednej časti. Za túto technológiu a súvisiace úlohy zvyčajne nezodpovedajú automatizační inžinieri. A sú na to dôvody. Po prvé, v mnohých organizáciách sú problémy s infraštruktúrou pod kontrolou oddelenia DevOps a vývojové tímy sa naozaj nestarajú o to, čo robí plynovod funkčný a ako je potrebné podporovať všetko, čo s tým súvisí. Po druhé, povedzme si úprimne, prax Infrastructure as Code (IaC) stále nie je prijatá v mnohých spoločnostiach. Ale rozhodne sa stal populárnym trendom a je dôležité snažiť sa byť zapojený do procesov, prístupov a nástrojov s tým spojených. Alebo aspoň zostaňte v obraze.
Začnime s motiváciou pre použitie tohto prístupu. Už sme diskutovali o tom, že na spustenie testov v GitlabCI budeme potrebovať minimálne prostriedky na spustenie Gitlab Runner. A aby sme mohli spúšťať kontajnery s prehliadačmi/emulátormi, musíme si rezervovať VM alebo klaster. Okrem testovacích zdrojov potrebujeme značné množstvo kapacít na podporu vývojových, stagingových, produkčných prostredí, ktoré zahŕňajú aj databázy, automatické plány, sieťové konfigurácie, nástroje na vyrovnávanie záťaže, používateľské práva atď. Kľúčovou otázkou je úsilie potrebné na podporu toho všetkého. Existuje niekoľko spôsobov, ako môžeme vykonávať zmeny a zavádzať aktualizácie. Napríklad v kontexte GCP môžeme použiť konzolu používateľského rozhrania v prehliadači a vykonávať všetky akcie kliknutím na tlačidlá. Alternatívou by bolo použitie volaní API na interakciu s cloudovými entitami alebo použitie nástroja príkazového riadka gcloud na vykonanie požadovaných manipulácií. Ale pri skutočne veľkom počte rôznych entít a prvkov infraštruktúry je ťažké alebo dokonca nemožné vykonávať všetky operácie manuálne. Všetky tieto manuálne akcie sú navyše nekontrolovateľné. Nemôžeme ich pred spustením odoslať na kontrolu, použiť systém správy verzií a rýchlo vrátiť späť zmeny, ktoré viedli k incidentu. Na vyriešenie takýchto problémov inžinieri vytvorili a vytvorili automatické bash/shell skripty, ktoré nie sú o nič lepšie ako predchádzajúce metódy, pretože nie je také ľahké ich rýchlo prečítať, pochopiť, udržiavať a upravovať v procedurálnom štýle.
V tomto článku a návode ako na to používam 2 nástroje súvisiace s praxou IaC. Sú to Terraform a Ansible. Niektorí ľudia sa domnievajú, že nemá zmysel používať ich súčasne, pretože ich funkčnosť je podobná a sú vzájomne zameniteľné. Faktom však je, že spočiatku dostávajú úplne iné úlohy. A to, že by sa tieto nástroje mali navzájom dopĺňať, potvrdili na spoločnej prezentácii vývojári zastupujúci HashiCorp a RedHat. Koncepčný rozdiel je v tom, že Terraform je nástroj na správu serverov. Zatiaľ čo Ansible je nástroj na správu konfigurácie, ktorého úlohou je inštalovať, konfigurovať a spravovať softvér na týchto serveroch.
Ďalším kľúčovým rozlišovacím znakom týchto nástrojov je štýl kódovania. Na rozdiel od bash a Ansible, Terraform používa deklaratívny štýl založený na popise požadovaného konečného stavu, ktorý sa má dosiahnuť ako výsledok popravy. Napríklad, ak vytvoríme 10 VM a použijeme zmeny cez Terraform, potom dostaneme 10 VM. Ak skript spustíme znova, nič sa nestane, keďže už máme 10 VM a Terraform o tom vie, pretože ukladá aktuálny stav infraštruktúry do súboru stavu. Ale Ansible používa procedurálny prístup a ak ho požiadate o vytvorenie 10 VM, tak pri prvom spustení dostaneme 10 VM, podobne ako Terraform. Ale po reštarte už budeme mať 20 VM. Toto je dôležitý rozdiel. V procedurálnom štýle neukladáme aktuálny stav a jednoducho opíšeme postupnosť krokov, ktoré je potrebné vykonať. Samozrejme, vieme zvládnuť rôzne situácie, pridať niekoľko kontrol existencie zdrojov a aktuálneho stavu, ale nemá zmysel strácať čas a vynakladať úsilie na ovládanie tejto logiky. Okrem toho sa tým zvyšuje riziko chýb.
Ak zhrnieme všetky vyššie uvedené skutočnosti, môžeme konštatovať, že Terraform a deklaratívna notácia sú vhodnejším nástrojom na poskytovanie serverov. Je však lepšie delegovať prácu správy konfigurácie na Ansible. S tým mimo, pozrime sa na prípady použitia v kontexte automatizácie.
Hodnota pre automatizačnú infraštruktúru
Jediná dôležitá vec, ktorú je potrebné pochopiť, je, že infraštruktúra automatizácie testov by sa mala považovať za súčasť celej infraštruktúry spoločnosti. To znamená, že všetky postupy IaC sa musia aplikovať globálne na zdroje celej organizácie. Kto je za to zodpovedný, závisí od vašich procesov. Tím DevOps je v týchto otázkach skúsenejší, vidí celý obraz toho, čo sa deje. Inžinieri QA sú však viac zapojení do procesu automatizácie budov a štruktúry potrubia, čo im umožňuje lepšie vidieť všetky požadované zmeny a príležitosti na zlepšenie. Najlepšou možnosťou je spolupracovať, vymieňať si poznatky a nápady na dosiahnutie očakávaného výsledku.
Tu je niekoľko príkladov použitia Terraform a Ansible v kontexte automatizácie testovania a nástrojov, o ktorých sme hovorili predtým:
1. Popíšte potrebné charakteristiky a parametre VM a klastrov pomocou Terraformu.
2. Pomocou Ansible nainštalujte nástroje potrebné na testovanie: docker, Selenoid, Selenium Grid a stiahnite si požadované verzie prehliadačov/emulátorov.
3. Pomocou Terraformu opíšte vlastnosti VM, v ktorom bude GitLab Runner spustený.
4. Nainštalujte GitLab Runner a potrebné sprievodné nástroje pomocou Ansible, nastavte nastavenia a konfigurácie.
Ilustrácia súčasného stavu infraštruktúry
Odkazy na preskúmanie:
Podobné nástroje
Poďme si to zhrnúť!
Krok
Technológia
náradie
Hodnota pre automatizačnú infraštruktúru
1
Miestny beh
Node.js, Selén, Appium
- Najpopulárnejšie nástroje pre web a mobil
- Podporuje mnoho jazykov a platforiem (vrátane Node.js)
2
Systémy kontroly verzií
ísť
- Podobné výhody s vývojovým kódom
3
Kontajnerizácia
Docker, Selenium grid, Selenoid (web, Android)
- Paralelne prebiehajúce testy
- Izolované prostredia
- Jednoduché, flexibilné aktualizácie verzií
- Dynamické zastavenie nevyužitých zdrojov
- Ľahko sa nastavuje
4
CI/CD
Gitlab CI
- Testuje časť potrubia
- Rýchla spätná väzba
- Viditeľnosť pre celú spoločnosť/tím
5
Cloud platformy
Google Cloud Platform
- Zdroje na požiadanie (platíme len v prípade potreby)
- Jednoduchá správa a aktualizácia
- Viditeľnosť a kontrola všetkých zdrojov
6
Orchestration
Kubernetes
V kontexte kontajnerov s prehliadačmi/emulátormi vo vnútri modulov:
- Škálovanie/automatické škálovanie
- Samoliečenie
- Aktualizácie a návraty bez prerušenia
7
Infraštruktúra ako kód (IaC)
Terraform, Ansible
- Podobné výhody s rozvojovou infraštruktúrou
- Všetky výhody verzie kódu
- Jednoduché zmeny a údržba
- Plne automatizované
Diagramy myšlienkových máp: vývoj infraštruktúry
Krok 1: Miestne
Krok 2: VCS
Krok 3: Kontajnerizácia
Krok 4: CI/CD
Krok 5: Cloudové platformy
Krok 6: Orchestrácia
Krok 7: IaC
Čo bude ďalej?
Takže, toto je koniec článku. Ale na záver by som s vami rád uzavrel nejaké dohody.
Z tvojej strany
Ako som povedal na začiatku, bol by som rád, keby bol článok praktický a pomohol vám uplatniť získané poznatky v reálnej práci. opäť pridávam.
Ale ani potom sa nezastavujte, cvičte, študujte relevantné odkazy a knihy, zistite, ako to vo vašej spoločnosti funguje, nájdite miesta, ktoré sa dajú zlepšiť a zapojte sa do toho. Veľa štastia!
Z mojej strany
Už z názvu môžete vidieť, že to bola len prvá časť. Napriek tomu, že sa ukázalo, že je dosť veľký, dôležité témy tu stále nie sú pokryté. V druhej časti sa plánujem pozrieť na infraštruktúru automatizácie v kontexte IOS. Vzhľadom na obmedzenia spoločnosti Apple týkajúce sa spúšťania simulátorov iOS iba na systémoch macOS je naša ponuka riešení zúžená. Nemôžeme napríklad použiť Docker na spustenie simulátora alebo verejné cloudy na spustenie virtuálnych počítačov. To však neznamená, že neexistujú žiadne iné alternatívy. Pokúsim sa vás informovať o pokročilých riešeniach a moderných nástrojoch!
Taktiež som nespomenul celkom veľké témy týkajúce sa monitoringu. V časti 3 sa pozriem na najobľúbenejšie nástroje na monitorovanie infraštruktúry a na to, aké údaje a metriky je potrebné zvážiť.
A nakoniec. V budúcnosti plánujem vydať video kurz o budovaní testovacej infraštruktúry a populárnych nástrojov. V súčasnosti je na internete pomerne veľa kurzov a prednášok o DevOps, ale všetky materiály sú prezentované v kontexte vývoja, nie automatizácie testovania. V tejto otázke naozaj potrebujem spätnú väzbu, či bude takýto kurz zaujímavý a hodnotný pre komunitu testerov a automatizačných inžinierov. Vopred ďakujem!
Zdroj: hab.com