Časť 1: Web / Android
Poznámka: tento článok je prekladom pôvodného článku do ruštiny Avšak všetky ilustrácie, odkazy, citáty a termíny sú zachované v pôvodnom jazyku, aby sa predišlo skresleniu významu pri preklade do ruštiny. Prajem vám príjemné štúdium!
V súčasnosti je špecializácia DevOps jednou z najžiadanejších v IT priemysle. Ak otvoríte populárne pracovné portály a nastavíte filter na mzdy, uvidíte, že pracovné ponuky súvisiace s DevOps sú na začiatku zoznamu. Je však dôležité si uvedomiť, že to sa väčšinou týka pozícií 'Senior', čo naznačuje, že uchádzač má vysokú úroveň zručností a znalosť technológie a nástrojov. S tým sú spojené aj vysoké zodpovednosti za bezproblémovú prevádzku produkcie. Avšak zabúdame, čo DevOps vlastne je. Pôvodne to nebola nejaká konkrétna osoba alebo oddelenie. Ak hľadáme definície tohto termínu, nájdeme veľa krásnych a správnych podstatných mien, ako sú metodológia, praktiky, kultúrna filozofia, skupina konceptov a podobne.
Moja špecializácia je inžinier automatizácie testovania (QA automation engineer), ale považujem ju za viac než len písanie automatizovaných testov alebo vývoj architektúry testovacieho rámca. V roku 2020 sú vedomosti o automatizačnej infraštruktúre tiež nevyhnutné. Umožňuje to organizovať proces automatizácie samostatne, od spustenia testov až po poskytovanie výsledkov všetkým zúčastneným stranám v súlade s stanovenými cieľmi. Výsledkom je, že zručnosti DevOps sú nevyhnutným faktorom na vykonávanie tejto práce. A to je skvelé, ale, bohužiaľ, existuje problém (spoiler: tento článok sa pokúša zjednodušiť tento problém). Spočíva v tom, že DevOps je ťažké. A to je jasné, veď spoločnosti nebudú platiť veľa za to, čo sa robí jednoducho… V svete DevOps je množstvo nástrojov, termínov a praktík, s ktorými sa treba oboznámiť. Najmä na začiatku kariéry to môže byť náročné a závisí to od nadobudnutých technických skúseností.
Zdroj:
Tu by sme asi mohli uzavrieť úvodnú časť a zamerať sa na cieľ 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 testovania. Na internete je mnoho zdrojov informácií o rôznych nástrojoch a o tom, ako ich používať, ale rád by som ich preskúmal výlučne v kontexte automatizácie. Myslím, že mnohým inžinierom automatizácie je známa situácia, keď testy vyvinuté vami nikto okrem vás nespúšťa a nestará sa o ich údržbu. V dôsledku toho sa testy stávajú zastaranými a musíte stráviť čas ich aktualizovaním. Opäť, na začiatku kariéry to môže byť dosť zložitá úloha: správne určiť, ktoré nástroje by mali pomôcť odstrániť tento problém, ako ich vybrať, nastaviť a udržiavať. Niektorí testeri sa obracajú na DevOps (ľudí) a, pravdupovediac, takýto 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 zaneprázdnení chlapci, pretože musia myslieť na infraštruktúru celej spoločnosti, nasadzovanie, monitorovanie, mikroservisy a iné podobné úlohy v závislosti od organizácie/tímy. Ako je zvykom, automatizácia nie je na prvom mieste. V tomto prípade sa musíme pokúsiť urobiť všetko, čo je v našich silách, od začiatku do konca. To zníži závislosti, urýchli pracovný proces, zlepší naše zručnosti a umožní nám vidieť širší obraz toho, čo sa deje.
V článku sú predložené najžiadanejšie a najpopulárnejšie nástroje a ukazuje sa, ako ich používať na krok za krokom budovanie infraštruktúry automatizácie. Každá skupina je predstavená nástrojmi, ktoré boli overené na osobnej skúsenosti. Ale to neznamená, že by ste mali používať to isté. Samotné nástroje nie sú dôležité, objavujú sa a zastarávajú. Našou inžinierskou úlohou je pochopenie základných princípov: prečo potrebujeme túto skupinu nástrojov a aké pracovné úlohy môžeme s ich pomocou vyriešiť. Preto na konci každej sekcie zanechávam odkazy na podobné nástroje, ktoré možno používate vo vašej organizácii.
Čo v tomto článku nenájdete
Ešte raz opakujem, že článok nie je o konkrétnych nástrojoch, takže tu nebudú žiadne kódové ukážky z dokumentácie a popisy konkrétnych príkazov. Ale na konci každej sekcie zanechávam odkazy na podrobné štúdium.
To sa robí z dôvodu, že:
- tento materiál je veľmi ľahko dostupný v rôznych zdrojoch (dokumentácia, knihy, video kurzy);
- ak sa do toho ponoríme, budeme musieť napísať 10, 20, 30 častí tohto článku (keď v pláne sú 2-3);
- jednoducho nechcem strácať váš čas, pretože možno chcete použiť iné nástroje na dosiahnutie tých istých cieľov.
Praktika
Veľmi by som si prial, aby bol tento materiál užitočný pre každého čitateľa, a nie len prečítaný a zabudnutý. Pri každom štúdiu je prax veľmi dôležitou súčasťou. Na to som pripravil. Takisto vás čaká domáca úloha, aby ste si boli istí, že ste bezmyšlienkovito nekopírovali riadky vykonávaných príkazov
Plán
Krok
Technológia
Nástroje
1
Lokálne spúšťanie (príprava web / android demo testov a ich spustenie lokálne)
Node.js, Selenium, Appium
2
Systémy správy verzií
Git
3
Kontajnerizácia
Docker, Selenium grid, Selenoid (Web, Android)
4
CI / CD
Gitlab CI
5
Cloudové platformy
Google Cloud Platform
6
Orkestrácia
Kubernetes
7
Infrastruktúra ako kód (IaC)
Terraform, Ansible
Štruktúra každej sekcie
Pre udržanie prehľadnosti rozprávania je každá sekcia popísaná podľa nasledujúceho plánu:
- stručné zhrnutie technológie,
- hodnota pre infraštruktúru automatizácie,
- ilustrácia súčasného stavu infraštruktúry,
- odkazy na štúdium,
- podobné nástroje.
1. Lokálne spúšťanie testov
Stručné zhrnutie technológie
Toto je len prípravný krok na spustenie demonštračných testov lokálne a na overenie, že úspešne prechádzajú. V praktickej časti sa používa Node.js, ale programovací jazyk a platforma nie sú také dôležité a môžete použiť tie, ktoré sa používajú vo vašej spoločnosti.
Odporúčam však používať Selenium WebDriver pre webové platformy a Appium pre platformu Android, pretože v nasledujúcich krokoch budeme používať Docker obrazy, ktoré sú špeciálne prispôsobené na prácu s týmito nástrojmi. Okrem toho, odvolávajúc sa na požiadavky v inzerátoch na zamestnanie, tieto nástroje sú najžiadanejšie na trhu.
Ako ste si mohli všimnúť, zameriavame sa len na web a Android testy. Bohužiaľ, IOS je úplne iný prípad (ďakujeme Apple). Plánujem predstaviť riešenia a praktiky súvisiace s IOS v nasledujúcich častiach.
Hodnota pre automatizačnú infraštruktúru
Z pohľadu infraštruktúry lokálne spustenie neprináša žiadnu hodnotu. Len overujete, že testy fungujú na lokálnom počítači v lokálnych prehliadačoch a simulátoroch. Ale aj tak je to nevyhnutný východiskový bod.
Ilustrácia aktuálneho stavu infraštruktúry
Odkazy na štúdium
Podobné nástroje
- akýkoľvek programovací jazyk, ktorý máte radi, spolu so Selenium/Appium - testami;
- akékoľvek testy;
- akýkoľvek test runner.
2. Systémy správy verzií (Git)
Stručné zhrnutie technológie
Nikto nebude prekvapený, ak poviem, že systém správy verzií je mimoriadne dôležitou súčasťou vývoja, či už v tíme alebo individuálne. Na základe rôznych zdrojov môžeme s istotou povedať, že Git je najpopulárnejším zástupcom. Systém správy verzií poskytuje množstvo výhod, ako je zdieľanie kódu, uchovávanie verzií, obnova na predchádzajúce vetvy, sledovanie histórie projektu, zálohy. Nebudeme rozoberať každú položku podrobne, pretože som si istý, že ste s tým dobre oboznámení a používate to v každodennej práci. Ale ak náhodou nie, odporúčam prerušiť čítanie tohto článku a čím skôr si tento nedostatok doplniť.
Hodnota pre automatizačnú infraštruktúru
A tu sa môžete opýtať: „Prečo nám hovorí o Gite? To všetci vedia a používajú ako pre kód vývoja, tak aj pre kód automatizovaných testov.“ Budete úplne pravdiví, ale v tomto článku hovoríme o infraštruktúre a táto sekcia zohráva úlohu prehľadu pre sekciu 7: „Infraštuktúra ako kód (IaC)“. Pre nás to znamená, že celá infraštruktúra, vrátane testovacej, je popísaná vo forme kódu, a preto môžeme na ňu uplatniť aj systémy správy verzií a získať podobné výhody ako pre kód vývoja a automatizácie.
O IaC sa podrobnejšie pozrieme v kroku 7, ale aj teraz môžete začať používať Git lokálne vytvorením lokálneho repozitára. Celkový obraz sa rozšíri, keď k infraštruktúre pridáme vzdialený repozitár.
Ilustrácia aktuálneho stavu infraštruktúry
Odkazy na štúdium
Podobné nástroje
3. Containerizácia (Docker)
Stručné zhrnutie technológie
Aby sme ukázali, ako containerizácia zmenila pravidlá hry, vráťme sa niekoľko desaťročí do minulosti. V tých časoch ľudia kupovali a používali serverové stroje na spúšťanie aplikácií. Avšak v mnohých prípadoch potrebné zdroje na spustenie neboli známe vopred. V dôsledku toho firmy míňali peniaze na drahé výkonné servery, ale časť tejto kapacity nebola plne využitá.
Ďalším krokom v evolúcii boli virtuálne stroje (VM), ktoré vyriešili problém míňania prostriedkov na nevyužité zdroje. Táto technológia umožnila spúšťanie aplikácií nezávisle od seba v rámci jedného servera, pričom každému pridelila plne izolovaný priestor. Bohužiaľ, akákoľvek technológia má svoje nevýhody. Spustenie VM si vyžaduje plnohodnotný operačný systém, ktorý spotrebováva CPU, RAM, úložisko a v závislosti od OS je nutné zohľadniť aj náklady na licenciu. Tieto faktory ovplyvňujú rýchlosť načítania a komplikujú prenosnosť.
A tak sme sa dostali k containerizácii. A opäť táto technológia vyriešila predchádzajúci problém, pretože kontajnery nevyžadujú plnohodnotný OS, čo umožňuje oslobodiť veľké množstvo zdrojov a poskytuje rýchle a flexibilné riešenie pre prenosnosť.
Samozrejme, technológia kontajnerizácie nie je nič nové a bola prvýkrát predstavená koncom 70. rokov. V tej dobe prebehlo množstvo výskumov, prác a pokusov. Ale práve Docker prispôsobil túto technológiu a sprístupnil ju pre masy. V súčasnosti, keď hovoríme o kontajneroch, väčšinou máme na mysli Docker. Keď hovoríme o Docker-kontajneroch, predpokladáme Linux-kontajnery. Môžeme používať Windows a macOS systémy na spúšťanie kontajnerov, ale je dôležité chápať, že v takom prípade vzniká dodatočná vrstva. Napríklad, Docker na Macu neviditeľne spúšťa kontajnery vo vnútri ľahkej Linux VM. K tejto téme sa ešte vrátime, keď budeme diskutovať o spustení Android-emulátorov vo vnútri kontajnerov, pretože tu sa objavuje veľmi dôležitý aspekt, ktorý je potrebné podrobne preskúmať.
Hodnota pre automatizačnú infraštruktúru
Zistili sme, že kontajnerizácia a Docker sú skvelé. Pozrime sa na to v kontexte automatizácie, veď každý nástroj alebo technológia by mali riešiť nejaký problém. Označme zjavné problémy automatizácie testovania v kontexte UI testov:
- 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;
- neprítomnosť izolovaného priestoru pre prehliadače/simulátory, čo je obzvlášť kritické pri paralelnom spúšťaní;
- ťažko sa spravuje a udržiava, ak je potrebné spustiť 10, 50, 100 alebo dokonca 1000 prehliadačov súčasne.
Ale keďže Selenium je najpopulárnejší nástroj na automatizáciu a Docker je najpopulárnejší nástroj na kontajnerizáciu, nemalo by nikoho prekvapiť, že sa niekto pokúsil ich skombinovať, aby získal mocný nástroj na riešenie vyššie uvedených problémov. Poďme sa na takéto riešenia pozrieť podrobnejšie.
Selenium grid v dockeri
Tento nástroj je najslávnejší na svete Selenium pre spúšťanie viacerých prehliadačov na viacerých počítačoch a ich správu z centrálneho uzla. Na spustenie je potrebné zaregistrovať aspoň 2 časti: Hub a Node(s). Hub je centrálny uzol, ktorý prijíma všetky požiadavky z testov a distribuuje ich na príslušné Nodes. Pre každý Node môžeme nastaviť konkrétnu konfiguráciu, napríklad určiť potrebný prehliadač a jeho verziu. Avšak my stále musíme sami dbať na kompatibilné ovládače pre prehliadače a nainštalovať ich na potrebné Nodes. Z tohto dôvodu sa Selenium grid nepoužíva v čistej forme, s výnimkou tých prípadov, keď potrebujeme pracovať s prehliadačmi, ktoré nie je možné nainštalovať na Linux OS. V všetkých ostatných prípadoch bude výrazne flexibilným a správnym riešením použitie Docker obrazov na spustenie Selenium grid Hub a Nodes. Takýto prístup veľmi zjednodušuje správu uzlov, pretože si môžeme vybrať požadovaný obraz s už nainštalovanými kompatibilnými verziami prehliadačov a ovládačov.
Napriek negatívnym hodnoteniam o stabilite práce, najmä pri spúšťaní veľkého počtu Nodes paralelne, si Selenium grid stále udržiava status najpopulárnejšieho nástroja pre paralelné spúšťanie Selenium testov. Je dôležité poznamenať, že v open-source neustále vznikajú rôzne vylepšenia a modifikácie tohto nástroja, ktoré sa snažia riešiť rôzne úzke miesta.
Selenoid pre Web
Tento nástroj predstavuje prelom v oblasti Selenium, pretože funguje okamžite po rozbalení a výrazne uľahčil život mnohým inžinierom automatizácie. Predovšetkým nejde o bežnú modifikáciu Selenium grid. Namiesto toho vývojári vytvorili úplne novú verziu Selenium Hub v jazyku Golang, čo v kombinácii s ľahkými Docker obrazmi pre rôzne prehliadače viedlo k pokroku v automatizácii testovania. Navyše, v prípade Selenium Grid musíme vopred definovať všetky požadované prehliadače a ich verzie, čo nie je problém, keď pracujeme len s jedným prehliadačom. Ale keď ide o niekoľko podporovaných prehliadačov, Selenoid je číslo jedna riešenie, vďaka funkcii 'prehliadač na požiadanie'. Všetko, čo od nás vyžaduje, je vopred stiahnuť potrebné obrazy s prehliadačmi a aktualizovať konfiguračný súbor, s ktorým interaguje Selenoid. Po získaní požiadavky od testov Selenoid automaticky spustí potrebný kontajner s požadovaným prehliadačom. Keď test skončí, Selenoid zastaví kontajner, čím uvoľní prostriedky pre ďalšie požiadavky. Takýto prístup úplne eliminuje známy problém 'degradácie uzlov', s ktorým sa často stretávame v Selenium grid.
Ale, žiaľ, Selenoid stále nie je strieborná guľka. Získali sme funkciu 'prehliadač na požiadanie', ale funkcia 'zdroje na požiadanie' stále nie je k dispozícii. Pre používanie Selenoidu musíme nasadiť na fyzickom hardvéri alebo na VM, čo znamená, že musíme vopred vedieť, koľko zdrojov je potrebné prideliť. Myslím, že to nie je problém pre malé projekty, ktoré spúšťajú 10, 20 alebo dokonca 30 prehliadačov paralelne. Ale čo ak potrebujeme 100, 500, 1000 a viac? Nemá zmysel neustále udržiavať a platiť za také množstvo zdrojov. V sekcii 5 a 6 tohto článku prediskutujeme riešenia, ktoré umožňujú škálovateľnosť, čím výrazne znižujú náklady spoločnosti.
Selenoid pre Android
Po úspechu Selenoid ako nástroja pre webovú automatizáciu sa ľudia chceli dočkať niečoho podobného pre Android. A to sa stalo – Selenoid bol vydaný s podporou Androidu. Z pohľadu koncového používateľa je princíp fungovania podobný webovej automatizácii. Jediný rozdiel spočíva v tom, že namiesto kontajnerov s prehliadačmi Selenoid spúšťa kontajnery s Android emulátormi. Podľa môjho názoru je to v súčasnosti najsilnejší bezplatný nástroj na spúšťanie Android testov paralelne.
Veľmi by som sa vyhol rozprávaniu o negatívnych stránkach tohto nástroja, pretože sa mi naozaj veľmi páči. Napriek tomu sa tu nachádzajú rovnaké nevýhody, ktoré sa týkajú aj webovej automatizácie, spojené so škálovaním. Okrem toho musím spomenúť ešte jedno obmedzenie, ktoré môže byť prekvapením, ak nástroj nastavujeme prvýkrát. Na spúšťanie Android obrazov potrebujeme fyzický stroj alebo VM s podporou 'nested virtualization'. V praktickej príručke demonštrujem, ako to aktivovať na Linux VM. Avšak, ak ste používateľom macOS a chcete nasadiť Selenoid lokálne, bude to na spúšťanie Android testov nemožné. Ale vždy môžete spustiť Linux VM lokálne s nastavenou 'nested virtualization' a nasadiť Selenoid vo vnútri.
Ilustrácia aktuálneho stavu infraštruktúry
V kontexte tohto článku pridáme 2 nástroje na ilustráciu infraštruktúry. To sú Selenium grid pre webové testy a Selenoid pre Android testy. V príručke na GitHub tiež ukážem, ako použiť Selenoid na spúšťanie webových testov.
Odkazy na štúdium
Podobné nástroje
- Existujú aj iné nástroje na kontajnerizáciu, ale Docker je najpopulárnejší. Ak chcete vyskúšať niečo iné, vezmite do úvahy, že tie nástroje, ktoré sme preskúmali pre paralelné spúšťanie Selenium testov, nebudú fungovať priamo z krabice.
- Ako už bolo spomenuté, existuje mnoho modifikácií Selenium grid, napríklad,.
4. CI / CD
Stručné zhrnutie technológie
Praktika kontinuálnej integrácie je veľmi populárna v oblasti vývoja a stojí na rovnakej úrovni ako systémy správy verzií. Napriek tomu cítim, že existuje zmätok v terminológii. V tomto odseku by som chcel opísať 3 modifikácie tejto technológie podľa môjho názoru. Na internete nájdete veľa článkov s rôznymi interpretáciami, a je úplne normálne, ak sa váš názor líši. Najdôležitejšie je, aby ste boli na jednej vlne so svojimi kolegami.
Takže existujú 3 pojmy: CI — Continuous Integration (kontinuálna integrácia), CD — Continuous Delivery (kontinuálna dodávka) a znova CD — Continuous Deployment (kontinuálne nasadzovanie). (Ďalej budem tieto pojmy používať v anglickom jazyku). Každá modifikácia pridáva niekoľko ďalších krokov do vášho vývojového potrubia. Ale slovo continuous (kontinuálny) je najdôležitejšie. V tomto kontexte подразумевame niečo, čo prebieha od začiatku do konca, bez prerušenia alebo manuálneho zásahu. Pozrime sa na CI & CD a CD v tomto kontexte.
- Continuous Integration – je počiatočný krok evolúcie. Po odoslaní nového kódu na server očakávame rýchlu spätnú väzbu, že s našimi zmenami je všetko v poriadku. Zvyčajne CI zahŕňa spustenie nástrojov statickej analýzy kódu a modulárne/ interné API testy. To nám umožňuje získať informácie o našom kóde už po niekoľkých sekundách/minútach.
- Kontinuálne dodávanie je pokročilejší krok, na ktorom spúšťame integračné/UI testy. Avšak v tomto štádiu nedostávame výsledky tak rýchlo ako v prípade CI. Po prvé, tieto typy testov si vyžadujú viac času na absolvovanie. Po druhé, pred spustením musíme nasadiť naše zmeny na testovaciu/ staging - prostredie. Navyše, ak hovoríme o mobilnom vývoji, existuje ďalší krok na vytvorenie zostavy našej aplikácie.
- Continuous Deployment predpokladá, že automaticky uvoľňujeme (release) naše zmeny na production, ak boli všetky akceptačné testy úspešne vykonané v predchádzajúcich fázach. Okrem toho po fáze uvoľnenia môžeme nastaviť rôzne fázy, ako je spustenie smoke testov na production a zber zaujímavých metrík. Continuous Deployment je možné iba pri dobrom pokrytí automatizovanými testami. Ak sú potrebné nejaké manuálne zásahy, vrátane testovania, nie je to už viac Continuous (nepretržité). Potom môžeme hovoriť, že náš pipeline zodpovedá len praxi Continuous Delivery.
Hodnota pre automatizačnú infraštruktúru
V tejto časti musím objasniť, že keď hovoríme o end-to-end UI testoch, to znamená, že musíme nasadiť naše zmeny a súvisiace služby na testovacie prostredia. Continuous Integration — proces nie je aplikovateľný pre túto úlohu a musíme zabezpečiť zavedenie aspoň praktík Continuous Delivery. Continuous Deployment má tiež zmysel v kontexte UI testov, ak plánujeme ich spúšťať na production.
A predtým, než sa pozrieme na ilustráciu zmien architektúry, chcem povedať niekoľko slov o GitLab CI. Na rozdiel od iných CI/CD nástrojov, GitLab poskytuje vzdialený repozitár a mnoho ďalších dodatočných funkcií. Takže GitLab je viac než len CI. Obsahuje hneď riadenie zdrojového kódu, Agile riadenie, CI/CD pipelines, nástroje na logovanie a zbieranie metrík. Architektúra GitLab pozostáva z GitLab CI/CD a GitLab Runner. Uvádzam stručný popis z oficiálnej stránky:
GitLab CI/CD je webová aplikácia s API, ktorá ukladá svoj stav v databáze, spravuje projekty/kompilácie a poskytuje používateľské rozhranie. GitLab Runner je aplikácia, ktorá spracováva kompilácie. Môže byť nasadená samostatne a funguje s GitLab CI/CD prostredníctvom API. Na spúšťanie testov potrebujete obidve GitLab inštancie a Runner.
Ilustrácia aktuálneho stavu infraštruktúry
Odkazy na štúdium
Podobné nástroje
- A mnoho ďalších
5. Cloudové platformy
Stručné zhrnutie technológie
V tejto sekcii sa budeme zaoberať populárnym trendom, ktorý sa nazýva ‘verejné cloudové služby’. Napriek obrovskému prínosu technológií virtualizácie a kontajnerizácie, ktoré sme už spomenuli, stále potrebujeme výpočtové zdroje. Spoločnosti kupujú drahé servery alebo si prenajímajú dátové centrá, avšak v takom prípade je potrebné vykonať výpočty (niekedy nerealistické) o tom, koľko zdrojov budeme potrebovať, či ich budeme používať 24/7 a na aké účely. Napríklad, pre produkciu je potrebný server, ktorý beží nonstop, ale potrebujeme rovnaké zdroje pre testovanie po pracovnej dobe? To tiež závisí od typu vykonaného testovania. Príkladom môžu byť záťažové/stresové testy, ktoré plánujeme vykonávať mimo pracovnej doby, aby sme získali výsledky na nasledujúci deň. Avšak určite nie je potrebná celodenná dostupnosť serverov pre end-to-end automatizované testy a najmä pre prostredia manuálneho testovania. Pre takéto situácie by bolo dobré mať k dispozícii presne také množstvo zdrojov, aké potrebujeme, využiť ich a prestať platiť, keď ich už nepotrebujeme. Navyše, bolo by skvelé dostať ich okamžite, s niekoľkými kliknutiami myšou alebo spustením niekoľkých skriptov. Na tento účel sa používajú verejné cloudové služby. Pozrime sa na definíciu:
„Verejný cloud je definovaný ako výpočtové služby ponúkané tretími stranami cez verejný internet, sprístupňujúce ich každému, kto ich chce používať alebo zakúpiť. Môžu byť zadarmo alebo predávané na požiadanie, umožňujúce zákazníkom platiť iba za spotrebované CPU cykly, úložisko alebo šírku pásma.“
Existuje názor, že verejné cloudové služby sú drahé. Ale ich kľúčovou myšlienkou je zníženie výdavkov spoločnosti. Ako sme už spomenuli, verejné cloudové služby umožňujú získať zdroje na požiadanie a platiť len za čas ich používania. Tiež niekedy zabúdame, že zamestnanci dostávajú plat a odborníci sú tiež drahým zdrojom. Je potrebné zohľadniť, že verejné cloudové služby značne 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 pre end-to-end UI testovanie? V zásade ide o virtuálne stroje alebo klastry (o Kubernetes sa budeme rozprávať v nasledujúcej sekcii), ktoré slúžia na spúšťanie prehliadačov a emulátorov. Čím viac prehliadačov a emulátorov chceme spustiť súčasne, tým viac CPU a pamäte potrebujeme a tým viac peňazí za to budeme musieť zaplatiť. Týmto spôsobom verejné cloudové služby v kontexte automatizácie testovania umožňujú spustiť veľký počet (100, 200, 1000 …) prehliadačov/emulátorov na požiadanie, rýchlo získať výsledky testovania a prestať platiť za také šialene náročné zdroje.
Najpopulárnejšími cloudovými poskytovateľmi sú Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). V praxi sú uvedené príklady použitia GCP, ale vo všeobecnosti nie je dôležité, čo presne budete používať na automatizačné úlohy. Všetci poskytovatelia ponúkajú približne rovnaké funkcie. Zvyčajne sa pri výbere poskytovateľa hlavné zameranie sústredí na celú infraštruktúru spoločnosti a obchodné požiadavky, čo presahuje rámec tohto článku. Pre automatizačných inžinierov bude zaujímavejšie porovnať použitie cloudových poskytovateľov s používaním cloudových platforiem špecificky na účely testovania, ako sú Sauce Labs, BrowserStack, BitBar a podobne. Tak poďme na to! Podľa môjho názoru je Sauce Labs najznámejšia cloudová testovacia platforma, preto som si ju vybral na porovnanie.
GCP vs Sauce Labs pre automatizáciu:
Predpokladajme, že potrebujeme spustiť súčasne 8 webových testov a 8 Android testov. Na to použijeme GCP a spustíme 2 virtuálne stroje so Selenoidom. Na prvom spustíme 8 kontajnerov s prehliadačmi. Na druhom – 8 kontajnerov s emulátormi. Pozrime sa na ceny:
Na spustenie jedného kontajnera s Chrome potrebujeme n1-standard-1 stroj. V prípade Androidu to bude n1-standard-4 pre jeden emulátor. V skutočnosti je flexibilnejší a lacnejší spôsob zadať konkrétne používateľské hodnoty pre CPU/Pamäť, ale v tejto chvíli to nie je podstatné pre porovnanie so Sauce Labs.
Tu sú tarify na používanie Sauce Labs:
Predpokladám, že ste si už všimli rozdiel, ale aj tak uvádzam tabuľku s výpočtami pre našu úlohu:
Potrebné zdroje
Mesačne
Pracovné hodiny(8:00 — 20:00)
Pracovné hodiny+ Preemptible
GCP pre Web
n1-standard-1 x 8 = n1-standard-8
$194.18
23 dni * 12h * 0.38 = 104.88$
23 dni * 12h * 0.08 = 22.08$
Sauce Labs pre web
Virtuálny Cloud8 paralelné testy
$1.559
—
—
GCP pre Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 dni * 12h * 1.52 = 419.52$
23 dni * 12h * 0.32 = 88.32$
Sauce Labs pre Android
Reálny zariadení Cloud 8 paralelné testy
$1.999
—
—
Ako vidno, rozdiel v nákladoch je obrovský, najmä ak spúšťate testy len v pracovnom dvanásťhodinovom intervale. Ale ešte viac môžete ušetriť, ak použijete preemptible stroje. Čo to vlastne je?
Preemptible VM je inštancia, ktorú môžete vytvoriť a spustiť za oveľa nižšiu cenu ako normálne inštancie. Avšak, Compute Engine môže tieto inštancie ukončiť (preempt), ak potrebuje prístup k týmto zdrojom pre iné úlohy. Preemptible inštancie sú nadbytočná kapacita Compute Engine, takže ich dostupnosť sa líši v závislosti od použitia.
Ak sú vaše aplikácie odolné voči chybám a môžu vydržať možné preemptions inštancií, potom preemptible inštancie môžu výrazne znížiť vaše náklady na Compute Engine. Napríklad, dávkové spracovacie úlohy môžu bežať na preemptible inštanciách. Ak niektoré z týchto inštancií ukončia počas spracovania, úloha sa spomalí, ale úplne nezastaví. Preemptible inštancie dokončia vaše dávkové spracovacie úlohy bez pridávania ďalšej záťaže na vaše existujúce inštancie a bez potreby platiť plnú cenu za ďalšie normálne inštancie.
A to stále nie je koniec! V skutočnosti som si istý, že nikto nespúšťa testy 12 hodín bez prestávky. A ak je to tak, môžete automaticky spúšťať a zastavovať virtuálne stroje, keď ich nepotrebujete. Reálne využitie môže klesnúť na 6 hodín denne. Potom platba v kontexte našej úlohy klesne až na 11$ mesačne za 8 prehliadačov. Naozaj to nie je nádherné? Ale s preemptible strojmi musíme byť opatrní a pripravení na prerušenia a nestabilný výkon, aj keď tieto situácie môžu byť naprogramované a spracované. Stojí to za to!
Ale v žiadnom prípade nehovorím, že „nikdy nepoužívajte cloudové testovacie farmy“. Majú množstvo výhod. Predovšetkým to nie je len virtuálny stroj, ale kompletné riešenie pre automatizáciu testovania s radom funkcií „out of the box“: vzdialený prístup, logy, snímky obrazovky, videozáznam, rôzne prehliadače a fyzické mobilné zariadenia. V mnohých situáciách to môže byť nenahraditeľná luxusná alternatíva. Obzvlášť testovacie platformy sú užitočné pri automatizácii IOS, keď verejné cloudy môžu ponúknuť iba Linuxové/Windows systémy. Ale o IOS budeme hovoriť v nasledujúcich článkoch. Odporúčam vždy posudzovať situáciu a odvíjať sa od úloh: v niektorých prípadoch je lacnejšie a efektívnejšie používať verejné cloudy, zatiaľ čo v iných sú testovacie platformy určite stojí za vynaložené peniaze.
Ilustrácia aktuálneho stavu infraštruktúry
Odkazy na štúdium
Podobné nástroje:
6. Orchestrácia
Stručné zhrnutie technológie
Mám dobré správy – takmer sme na konci článku! Naša automatizačná infraštruktúra momentálne pozostáva z webových a Android testov, ktoré spúšťame cez GitLab CI paralelne, využívajúc nástroje s podporou Docker: Selenium grid a Selenoid. Navyše používame virtuálne stroje vytvorené cez GCP na spúšťanie kontajnerov s prehliadačmi a emulátormi. Aby sme znížili náklady, spúšťame tieto virtuálne stroje iba na požiadanie a zastavujeme ich, keď sa netestuje. Existuje niečo ďalšie, čo by mohlo zlepšiť našu infraštruktúru? Odpoveď znie – áno! Vítame Kubernetes (K8s)!
Najprv sa pozrime, ako sú slová orchestrácia, klaster a Kubernetes navzájom prepojené. Na vysokej úrovni je orchestrácia systém, ktorý nasadzuje a spravuje aplikácie. Pre automatizáciu testovania sú takéto kontajnerizované aplikácie Selenium grid a Selenoid. Docker a K8s sa navzájom dopĺňajú. Prvý sa používa na nasadenie aplikácií, druhý na orchestru. K8s je klaster. Úlohou klastru je využívať VMs ako uzly (Nodes), čo umožňuje inštaláciu rôzneho funkčného vybavenia, programov a služieb na jednom serveri (klastri). Ak niektorý uzol (Node) zlyhá, ostatné uzly sa prevezmú a zabezpečia bezproblémový chod našich aplikácií. Okrem toho K8s má dôležitú funkčnosť, ktorá súvisí s horizontálnym škálovaním (scaling), pričom automaticky získavame optimálne množstvo zdrojov na základe zaťaženia a nastavených obmedzení.
Na pravdu povediac, ručne nasadiť Kubernetes od základov je úplne netriviálna úloha. Nechám odkaz na známe praktické sprievodcu „Kubernetes The Hard Way“, a ak máte záujem, môžete si to vyskúšať. Ale, našťastie, existujú alternatívne metódy a nástroje. Najjednoduchšou z nich je využitie Google Kubernetes Engine (GKE) v GCP, čo umožní získať pripravený klaster po niekoľkých kliknutiach. Na začiatok štúdia odporúčam práve tento prístup, pretože vám umožní zamerať sa na to, ako používať K8s pre vaše úlohy, namiesto skúmania, ako by mali byť interné komponenty navzájom integrované.
Hodnota pre automatizačnú infraštruktúru
Pozrime sa na niekoľko významných funkcií, ktoré K8s poskytuje:
- nasadenie aplikácie: použitie multi-node klastrov namiesto VM;
- dynamické škálovanie: znižuje náklady na zdroje, ktoré sú využívané len na požiadanie;
- samoobnova (self-healing): automatické obnovenie pods (čím sa obnovujú aj kontajnery);
- nasadenie aktualizácií a revertovanie zmien bez prestojov: aktualizácia nástrojov, prehliadačov a emulátorov neprerušuje prácu aktuálnych používateľov.
Ale K8s stále nie je strieborná guľka. Na to, aby sme pochopili všetky výhody a obmedzenia v kontexte nástrojov, o ktorých hovoríme (Selenium grid, Selenoid), stručne preberieme štruktúru K8s. Klaster obsahuje dva typy uzlov: Master Nodes a Workers Nodes. Master Nodes sú zodpovedné za správu, nasadenie a rozhodovanie o plánovaní. Workers Nodes sú tie, na ktorých sú aplikácie spustené. Uzly tiež obsahujú prostredie na spúšťanie kontajnerov. V našom prípade je to Docker, ktorý je zodpovedný za operácie súvisiace s kontajnermi. Existujú však aj alternatívne riešenia, ako napríklad. Je dôležité pochopiť, že škálovanie alebo samoobnova sa priamo netýkajú kontajnerov. To sa realizuje prostredníctvom pridania/umenšenia počtu pods, ktoré v sebe obsahujú kontajnery (zvyčajne jeden kontajner na pod, ale v závislosti od úlohy to môže byť aj viac). Vysokoúrovňová hierarchia predstavuje worker nodes, v ktorých sa nachádzajú pods, v ktorých sú spustené kontajnery.
Funkcia škálovania je kľúčová a môže byť použitá ako pre uzly v rámci cluster node-pool, tak aj pre pods v rámci uzla. Existujú 2 typy škálovania, ktoré sa vzťahujú ako na uzly, tak aj na pods. Prvý typ – horizontálne – škálovanie prebieha zvýšením počtu uzlov/pods. Tento typ je preferovanejší. Druhý typ, zodpovedajúco, vertikálne. Škálovanie sa uskutočňuje zvýšením veľkosti uzlov/pods, a nie ich počtu.
Teraz sa pozrime na naše nástroje v kontexte vyššie uvedených pojmov.
Selenium grid
Ako bolo spomínané skôr, Selenium grid je veľmi populárny nástroj, a nie je prekvapením, že bol kontajnerizovaný. Preto nie je prekvapujúce, že Selenium grid možno nasadiť v K8s. Príklad toho, ako to urobiť, nájdete v oficiálnom K8s repozitári. Ako obvykle, prikladám odkazy na konci sekcie. Okrem toho v praktickej príručke je ukázané, ako to urobiť pomocou Terraformu. Rovnako existuje návod, ako škálovať počet pods, ktoré obsahujú kontajnery s prehliadačmi. Avšak funkcia automatického škálovania v kontexte K8s je stále nejasná úloha. Keď som začal štúdium, nenašiel som žiadne praktické príručky alebo odporúčania. Po niekoľkých prieskumoch a experimentoch s podporou tímu DevOps sme zvolili prístup zvyšovania kontajnerov s požadovanými prehliadačmi v rámci jedného podu, ktorý sa nachádza v rámci jedného worker uzla. Tento spôsob nám umožňuje aplikovať stratégiu horizontálneho škálovania uzlov zvýšením ich počtu. Dúfam, že v budúcnosti sa situácia zmení a uvidíme čoraz viac popisov najlepších prístupov a hotových riešení, najmä po vydaní Selenium grid 4 s upravenou vnútornou architektúrou.
Selenoid:
V súčasnosti je nasadenie Selenoid v K8s najväčším sklamaním. Nie sú kompatibilné. Teoreticky môžeme spustiť Selenoid kontajner v rámci podu, ale keď Selenoid začne spúšťať kontajnery s prehliadačmi, všetky budú stále v rámci tohto istého podu. To robí škálovanie nemožným a výsledkom je, že prevádzka Selenoid v rámci clusteru sa nebude líšiť od prevádzky v rámci virtuálnej mašiny. Koniec príbehu.
Moon:
S pozornosťou na toto úzke miesto pri práci s Selenoid, vývojári vydali silnejší nástroj, ktorý nazvali Moon. Tento nástroj bol pôvodne navrhnutý na prácu s Kubernetes a výsledkom je, že je možné a potrebné používať funkciu automatického škálovania. Napriek tomu by som povedal, že v súčasnosti je to jedinou nástroj v oblasti Selenium, ktorý má natívnu podporu pre K8s cluster priamo z krabice (už nie, pozri nasledujúci nástroj ). Kľúčovou vlastnosťou Moon, ktorá túto podporu zabezpečuje, je:
Úplne bezstavový. Selenoid uchováva v pamäti informácie o aktuálne prebiehajúcich reláciách prehliadača. Ak by z nejakého dôvodu jeho proces havaroval — všetky bežiace relácie by sa stratili. Moon naopak nemá interný stav a môže byť replikovaný naprieč dátovými centrami. Relácie prehliadača zostávajú aktívne, aj keď jedna alebo viac replík zlyhá.
Takže, Moon je skvelé riešenie, ale má jeden problém — nie je zadarmo. Cena závisí od počtu relácií. Bezplatne môžete spustiť iba 0-4 relácie, čo nie je veľmi užitočné. Avšak od piatej relácie budete musieť zaplatiť 5$ 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 bezvýznamné. Ako som už opísal, môžeme spustiť VMs so Selenium Grid na požiadanie alebo zvýšiť počet uzlov v klastri. Približne na jeden pipeline spúšťame 500 prehliadačov a zastavujeme všetky zdroje po dokončení testov. Keby sme používali Moon, museli by sme zaplatiť ďalších 500 x 5 = 2500 $ mesačne, a nezáleží na tom, ako často spúšťame testy. A znova, nehovorím "nepoužívajte Moon". Pre vaše úlohy to môže byť neoceniteľné riešenie, napríklad ak máte v organizácii veľa projektov/tímov a potrebujete obrovský spoločný klastra pre všetkých. Ako vždy, zanechávam odkaz na konci a odporúčam vykonať všetky potrebné výpočty v kontexte vašej úlohy.
Callisto: (Pozor! Toto nie je v originálnom článku a je obsiahnuté iba v ruskom preklade)
Ako som povedal, Selenium je veľmi populárny nástroj a oblasť IT sa rýchlo rozvíja. Kým som pracoval na preklade, na internete sa objavil nový sľubný nástroj Callisto (ahoj Cypress a ďalším zabijakom Selenium). Pracuje nativne s K8s a umožňuje spúšťať Selenoid kontajnery v pods, distribuovane po Nodes. Všetko funguje hneď po vybalení, vrátane automatického škálovania. Fantázia, ale treba to otestovať. Už som sa podaril nasadiť tento nástroj a vykonať niekoľko experimentov. Avšak, je ešte priskoro na závery, po získaní výsledkov na dlhú trať, možno urobím prehľad v nasledujúcich článkoch. Zatiaľ zanechávam len odkazy na samostatné výskumy.
Ilustrácia aktuálneho stavu infraštruktúry
Odkazy na štúdium
Odkazy na štúdium
Podobné nástroje
7. Infrastruktúra ako kód (IaC)
Stručné zhrnutie technológie
A tu sme sa dostali k poslednej sekcii. Zvyčajne táto technológia a s ňou súvisiace úlohy nepatria do zodpovednosti inžinierov pre automatizáciu. A na to sú svoje dôvody. Po prvé, v mnohých organizáciách sú infraštruktúrne otázky pod kontrolou oddelenia DevOps a tím vývoja sa veľmi nezaujíma o to, vďaka čomu funguje pipeline a akým spôsobom je potrebné udržiavať všetko, čo s tým súvisí. Po druhé, buďme úprimní, prax 'Infrastruktúra ako kód (IaC)' sa stále ešte v mnohých spoločnostiach nepoužíva. Ale rozhodne sa to stalo populárnym trendom a je dôležité snažiť sa byť zapojený do súvisiacich procesov, prístupov a nástrojov. Alebo, aspoň, byť informovaný o dianí.
Začneme motiváciou na využitie tohto prístupu. Už sme diskutovali o tom, že na spustenie testov v GitlabCI potrebujeme minimálne zdroje na spustenie Gitlab Runnera. A na spustenie kontajnerov s prehliadačmi/emulátormi musíme rezervovať VM alebo klaster. Okrem prostriedkov na testovanie potrebujeme značné množstvo výkonu na udržanie vývojového, staging a produkčného prostredia, čo zahŕňa aj databázy, automatické plánovanie, konfigurácie siete, vyvažovač záťaže, práva používateľov a tak ďalej. Kľúčovým problémom sú úsilie potrebné na podporu tohto 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 využiť UI konzolu v prehliadači a vykonávať všetky akcie kliknutím na tlačidlá. Alternatívnym spôsobom môže byť používanie API volaní na interakciu s cloudovými entitami alebo aplikácia nástroja príkazového riadku gcloud na vykonávanie potrebných manipulácií. Ale pri naozaj veľkom počte rôznych entít a infrastrukturných prvkov sa stáva ťažké alebo dokonca nemožné vykonávať všetky operácie manuálne. Navyše, všetky tieto manuálne úkony sú nekontrolovateľné. Nemôžeme ich poslať na revíziu pred vykonaním, používať systém správy verzií a rýchlo vrátiť zmeny, ktoré viedli k incidentu. Na riešenie takýchto problémov inžinieri vytvárali a vytvárajú automatické bash/shell skripty, čo nie je o veľa lepšie ako predchádzajúce metódy, pretože nie sú ľahko čitateľné, pochopiteľné, udržiavateľné a modifikovateľné v procedurálnom štýle.
V tomto článku a praktickej príručke používam 2 nástroje, ktoré sa týkajú praxe IaC. Tieto nástroje sú Terraform a Ansible. Niektorí sa domnievajú, že nemá zmysel ich používať súčasne, pretože ich funkcie sú podobné a sú zamieňateľné. Ale skutočnosť je taká, že pôvodne sú pred nimi kladené úplne iné úlohy. A fakt, že by sa tieto nástroje mali navzájom doplniť, bol potvrdený na spoločnej prezentácii vývojárov zastupujúcich spoločnosti HashiCorp a RedHat. Konceptuálny rozdiel spočíva v tom, že Terraform je provisioning nástroj na správu samotných serverov. Zatiaľ čo Ansible je nástroj na správu konfigurácií, ktorého úlohou je inštalácia, nastavenie a správa softvéru na týchto serveroch.
Ďalšou kľúčovou odlišovacou vlastnosťou týchto nástrojov je štýl písania kódu. Na rozdiel od bash a Ansible, Terraform používa deklaratívny štýl, založený na opise želaného konečného stavu, ktorý je potrebné dosiahnuť vykonaním. Napríklad, ak máme v pláne vytvoriť 10 VM a aplikovať zmeny cez Terraform, dostaneme 10 VM. Pri opakovaní skriptu sa nič nestane, pretože už máme 10 VM, a Terraform o tom vie, pretože uchováva aktuálny stav infraštruktúry v state súbore. Avšak Ansible používa procedurálny prístup a ak ho požiadame o vytvorenie 10 VM, pri prvom spustení dostaneme 10 VM, podobne ako v prípade Terraform. Ale pri opakovaní už budeme mať 20 VM. V tom je to dôležité odlíšenie. V procedurálnom štýle neuchovávame aktuálny stav a jednoducho popisujeme sekvenciu krokov, ktoré je potrebné vykonať. Samozrejme, môžeme spracovať rôzne situácie, pridať niekoľko kontrol na existenciu zdrojov a aktuálny stav, ale nemá zmysel tráviť náš čas a úsilie kontrolovaním tejto logiky. Okrem toho to zvyšuje riziko chýb.
Zhrnutím všetkého vyššie uvedeného môžeme dospieť k záveru, že pre provisioning serverov je vhodnejším nástrojom Terraform a deklaratívna notácia. Na prácu so správou konfigurácií je lepšie delegovať úlohu na Ansible. Po vyjasnení tohto, pozrime sa na príklady použitia v kontexte automatizácie.
Hodnota pre automatizačnú infraštruktúru
Tu je dôležité chápať, že infraštruktúra automatizácie testovania by sa mala považovať za súčasť celej infraštruktúry spoločnosti. To znamená, že všetky praktiky IaC by sa mali globálne aplikovať na zdroje celej organizácie. Kto za to zodpovedá, závisí od vašich procesov. DevOps tím má viac skúseností v týchto otázkach, vidí celkový obraz. Avšak QA inžinieri sú viac zapojení do procesu budovania automatizácie a štruktúry pipeline, čo im umožňuje lepšie vidieť všetky požadované zmeny a možnosti na zlepšenie. Najlepší variant je pracovať spoločne, zdieľať vedomosti a nápady na dosiahnutie očakávaného výsledku.
Uvediem niekoľko príkladov použitia Terraform a Ansible v kontexte automatizácie testovania a nástrojov, ktoré sme predtým diskutovali:
1. Opísať cez Terraform potrebné charakteristiky a parametre VM a klastrov.
2. Nainštalovať pomocou Ansible potrebné nástroje na testovanie: docker, Selenoid, Selenium Grid a stiahnuť potrebné verzie prehliadačov/emulátorov.
3. Opísať cez Terraform charakteristiky VM, v ktorej bude spustený GitLab Runner.
4. Nainštalovať pomocou Ansible GitLab Runner a potrebné sprievodné nástroje, nastaviť konfiguračné parametre a nastavenia.
Ilustrácia aktuálneho stavu infraštruktúry
Odkazy na štúdium:
Podobné nástroje
Zhrňme to!
Krok
Technológia
Nástroje
Hodnota pre automatizačnú infraštruktúru
1
Lokálne spúšťanie
Node.js, Selenium, Appium
- Najpopulárnejšie nástroje pre web a mobil
- Podpora mnohých jazykov a platforiem (vrátane Node.js)
2
Systémy správy verzií
Git
- Podobné výhody s vývojovým kódom
3
Kontajnerizácia
Docker, Selenium grid, Selenoid (Web, Android)
- Paralelné spúšťanie testov
- Izolované prostredia
- Jednoduché, flexibilné aktualizácie verzií
- Dynamické zastavenie nepoužívaných zdrojov
- Ľahko sa nastavuje
4
CI / CD
Gitlab CI
- Testy sú súčasťou konveja
- Rýchla spätná väzba
- Viditeľnosť pre celú spoločnosť/tím
5
Cloudové platformy
Google Cloud Platform
- Prostredky na požiadanie (platíme len vtedy, keď sú potrebné)
- Ľahko sa spravuje a aktualizuje
- Viditeľnosť a kontrola všetkých zdrojov
6
Orkestrácia
Kubernetes
V kontexte kontajnerov s prehliadačmi/emulátormi vo vnútri pods:
- Škálovanie / automatické škálovanie
- Samovzprávovanie
- Aktualizácie a vracania bez prerušenia
7
Infrastruktúra ako kód (IaC)
Terraform, Ansible
- Podobné výhody s vývojovou infraštruktúrou
- Všetky výhody verzovania kódu
- Ľahko prispôsobiteľné a udržiavateľné
- Úplne automatizované
Myšlienková mapa: evolúcia 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 ďalej?
Takže, toto je koniec článku. Na záver by som rád stanovil niektoré dohody s vami.
Z vašej strany
Ako som povedal na začiatku, chcem, aby článok mal praktickú hodnotu a pomohol vám aplikovať získané vedomosti v reálnom svete. Ešte raz posielam.
Ale ani potom sa nezastavujte, cvičte, preskúmajte relevantné odkazy a knihy, zistite, ako to funguje vo vašej spoločnosti, nájdite spôsoby, ako to zlepšiť, a zapojte sa do toho. Veľa šťastia!
Z mojej strany
Z nadpisu je jasné, že to bola iba prvá časť. Napriek tomu, že je pomerne rozsiahla, stále tu zostávajú dôležité témy, ktoré neboli vyjadrené. V druhej časti plánujem preskúmať infraštruktúru automatizácie v kontexte IOS. Kvôli obmedzeniam Apple týkajúcemu sa spúšťania IOS simulátorov iba na macOS systémov, sú naše riešenia obmedzené. Napríklad sme zbavení možnosti používať Docker na spustenie simulátora alebo verejných cloudov na spustenie virtuálnych strojov. Ale to neznamená, že neexistujú iné alternatívy. Snažím sa udržať vás informovaných o najnovších riešeniach a moderných nástrojoch!
Tiež som nespomenul celkom rozsiahle témy spojené s monitoringom. V tretej časti sa plánujem venovať najpopulárnejším nástrojom na monitoring infraštruktúry a aké dáta a metriky by sme mali zvážiť.
A napokon. V budúcnosti plánujem vydanie video kurzu o budovaní testovacej infraštruktúry a populárnych nástrojoch. V súčasnosti je vo svete veľa kurzov a prednášok o DevOps, ale všetky materiály sú zamerané na vývoj, nie na automatizáciu testovania. V tejto otázke veľmi potrebujem spätnú väzbu, či by taký kurz bol zaujímavý a cenný pre komunitu testerov a automatizátorov. Vopred ďakujem!
Zdroj: habr.com
