1. del: Splet/Android
Obvestilo: ta članek je prevod originalnega članka v ruščino Vendar pa so vse ilustracije, povezave, citati in izrazi ohranjeni v izvirnem jeziku, da bi se izognili izkrivljanju pomena pri prevodu v ruščino. Želim ti vesel študij!
Trenutno je posebnost DevOps ena najbolj iskanih v industriji IT. Če odprete priljubljena spletna mesta za iskanje zaposlitve in filtrirate glede na plačo, boste videli, da so delovna mesta, povezana z DevOps, na vrhu seznama. Vendar je pomembno razumeti, da se to v glavnem nanaša na 'Senior' položaj, kar pomeni, da ima kandidat visoko raven spretnosti, znanja o tehnologiji in orodjih. S tem je povezana tudi visoka mera odgovornosti, povezana z nemotenim delovanjem proizvodnje. Vendar smo začeli pozabljati, kaj je DevOps. Sprva ni šlo za določeno osebo ali oddelek. Če iščemo definicije tega izraza, bomo našli veliko lepih in pravilnih samostalnikov, kot so metodologija, prakse, kulturna filozofija, skupina konceptov itd.
Moja specializacija je inženir za avtomatizacijo testov (QA automation engineer), vendar menim, da ne bi smela biti povezana samo s pisanjem samodejnih testov ali razvojem arhitekture testnega ogrodja. V letu 2020 je nujno tudi poznavanje avtomatizacijske infrastrukture. To vam omogoča, da sami organizirate proces avtomatizacije, od izvajanja testov do zagotavljanja rezultatov vsem deležnikom v skladu z vašimi cilji. Posledično so veščine DevOps obvezne za opravljanje dela. In vse to je dobro, a na žalost obstaja težava (spojler: ta članek poskuša poenostaviti to težavo). Bistvo je, da je DevOps težak. In to je očitno, saj podjetja ne bodo plačala veliko za nekaj, kar je lahko narediti ... V svetu DevOps obstaja veliko število orodij, izrazov in praks, ki jih je treba osvojiti. To je še posebej težko na začetku kariere in je odvisno od nabranih tehničnih izkušenj.
Vir:
Tukaj bomo verjetno zaključili z uvodnim delom in se posvetili namenu tega članka.
O čem govori ta članek?
V tem članku bom delil svoje izkušnje z gradnjo infrastrukture za avtomatizacijo testiranja. Na spletu je veliko virov informacij o različnih orodjih in kako jih uporabljati, vendar bi jih rad pogledal zgolj v kontekstu avtomatizacije. Verjamem, da mnogi inženirji avtomatizacije poznajo situacijo, ko nihče razen vas ne izvaja razvitih testov ali skrbi za njihovo vzdrževanje. Posledično testi postanejo zastareli in morate porabiti čas za njihovo posodabljanje. Še enkrat, na začetku kariere je to lahko precej težka naloga: pametno se odločiti, katera orodja naj pomagajo odpraviti dano težavo, kako jih izbrati, konfigurirati in vzdrževati. Nekateri preizkuševalci se za pomoč obrnejo na DevOps (ljudje) in, bodimo iskreni, ta pristop deluje. V mnogih primerih je to lahko edina možnost, saj nimamo vpogleda v vse odvisnosti. A kot vemo, so DevOps zelo zaposleni, saj morajo razmišljati o infrastrukturi celotnega podjetja, uvajanju, spremljanju, mikrostoritvah in drugih podobnih nalogah, odvisno od organizacije/ekipe. Kot je običajno, avtomatizacija ni prioriteta. V takem primeru moramo skušati narediti vse, kar je v naši moči, od začetka do konca. To bo zmanjšalo odvisnosti, pospešilo potek dela, izboljšalo naše sposobnosti in nam omogočilo, da vidimo širšo sliko dogajanja.
Članek predstavlja najbolj priljubljena in priljubljena orodja ter prikazuje, kako jih uporabiti za gradnjo avtomatizacijske infrastrukture korak za korakom. Vsako skupino predstavljajo orodja, ki so bila preizkušena na osebnih izkušnjah. Vendar to ne pomeni, da morate uporabljati isto stvar. Orodja sama po sebi niso pomembna, pojavljajo se in zastarajo. Naša inženirska naloga je razumeti osnovna načela: zakaj potrebujemo to skupino orodij in katere delovne težave lahko rešimo z njihovo pomočjo. Zato na koncu vsakega razdelka puščam povezave do podobnih orodij, ki jih lahko uporabljate v vaši organizaciji.
Česa ni v tem članku
Še enkrat ponavljam, da članek ne govori o posebnih orodjih, zato ne bo vstavkov kode iz dokumentacije in opisov določenih ukazov. Toda na koncu vsakega razdelka pustim povezave za podrobno študijo.
To se naredi, ker:
- to gradivo je zelo enostavno najti v različnih virih (dokumentacija, knjige, video tečaji);
- če se začnemo poglabljati, bomo morali napisati 10, 20, 30 delov tega članka (medtem ko so načrti 2-3);
- Nočem le izgubljati vašega časa, saj boste morda želeli uporabiti druga orodja za doseganje istih ciljev.
Practice
Res bi rad, da bi bilo to gradivo koristno za vsakega bralca, ne pa samo prebrano in pozabljeno. Pri vsakem študiju je praksa zelo pomembna komponenta. Za to sem pripravljen. Čaka vas tudi domača naloga, da se prepričate, da ne boste brezglavo kopirali vrstic ukazov, ki jih izvajate.
načrt
Korak
Tehnologija
Orodja
1
Lokalno izvajanje (pripravite spletne / androidne demo teste in jih zaženite lokalno)
Node.js, Selenium, Appium
2
Sistemi za nadzor različic
git
3
Kontejnerizacija
Docker, mreža Selenium, Selenoid (splet, Android)
4
CI/CD
Gitlab CI
5
Oblačne platforme
Google Cloud Platform
6
Orkestracija
Kubernetes
7
Infrastruktura kot koda (IaC)
Terraform, Ansible
Struktura vsakega odseka
Da bi bila pripoved jasna, je vsak razdelek opisan v skladu z naslednjim orisom:
- kratek opis tehnologije,
- vrednost za infrastrukturo avtomatizacije,
- prikaz trenutnega stanja infrastrukture,
- povezave do študija,
- podobna orodja.
1. Lokalno zaženite teste
Kratek opis tehnologije
To je le pripravljalni korak za lokalno izvajanje demo testov in preverjanje njihove uspešnosti. V praktičnem delu se uporablja Node.js, vendar programski jezik in platforma tudi nista pomembna in lahko uporabite tiste, ki jih uporabljate v vašem podjetju.
Vendar kot orodja za avtomatizacijo priporočam uporabo Selenium WebDriver za spletne platforme oziroma Appium za platformo Android, saj bomo v naslednjih korakih uporabili slike Docker, ki so prilagojene posebej za delo s temi orodji. Poleg tega so glede na zahteve delovnih mest ta orodja najbolj iskana na trgu.
Kot ste morda opazili, upoštevamo samo spletne in Android teste. Na žalost je iOS povsem druga zgodba (hvala Apple). V prihajajočih delih nameravam predstaviti rešitve in prakse, povezane z IOS.
Vrednost za infrastrukturo avtomatizacije
Z vidika infrastrukture lokalno delovanje ne zagotavlja nobene vrednosti. Preverite samo, ali se testi izvajajo na lokalnem računalniku v lokalnih brskalnikih in simulatorjih. A v vsakem primeru je to nujno izhodišče.
Prikaz trenutnega stanja infrastrukture
Povezave za raziskovanje
Podobna orodja
- poljuben programski jezik, ki vam je všeč v povezavi s testi Selenium/Appium;
- kakršni koli testi;
- kateri koli testni tekač.
2. Sistemi za nadzor različic (Git)
Kratek opis tehnologije
Za nikogar ne bo veliko odkritje, če rečem, da je nadzor različic izjemno pomemben del razvoja, tako v ekipi kot posamezniku. Na podlagi različnih virov lahko z gotovostjo trdimo, da je Git najbolj priljubljen predstavnik. Sistem za nadzor različic ponuja številne prednosti, kot so deljenje kode, shranjevanje različic, obnovitev na prejšnje veje, spremljanje zgodovine projekta in varnostne kopije. Ne bomo podrobno razpravljali o vsaki točki, saj sem prepričan, da jo dobro poznate in jo uporabljate pri vsakodnevnem delu. Če pa nenadoma ne, priporočam, da prekinete branje tega članka in čim prej zapolnite to vrzel.
Vrednost za infrastrukturo avtomatizacije
In tukaj lahko postavite razumno vprašanje: »Zakaj nam govori o Gitu? Vsi to vedo in uporabljajo tako za razvojno kodo kot za kodo za samodejno testiranje.« Imeli boste popolnoma prav, vendar v tem članku govorimo o infrastrukturi in ta razdelek deluje kot predogled za razdelek 7: "Infrastruktura kot koda (IaC)". Za nas to pomeni, da je celotna infrastruktura, vključno s testiranjem, opisana v obliki kode, tako da lahko tudi na njej apliciramo sisteme za verzioniranje in pridobimo podobne ugodnosti kot pri razvojni in avtomatizacijski kodi.
IaC si bomo podrobneje ogledali v 7. koraku, vendar že zdaj lahko začnete uporabljati Git lokalno z ustvarjanjem lokalnega repozitorija. Velika slika se bo razširila, ko bomo infrastrukturi dodali oddaljeni repozitorij.
Prikaz trenutnega stanja infrastrukture
Povezave za raziskovanje
Podobna orodja
3. Kontejnerizacija (Docker)
Kratek opis tehnologije
Da pokažemo, kako je kontejnerizacija spremenila pravila igre, se vrnimo nekaj desetletij nazaj. Takrat so ljudje kupovali in uporabljali strežniške stroje za izvajanje aplikacij. Toda v večini primerov potrebni zagonski viri niso bili vnaprej znani. Posledično so podjetja porabila denar za nakupe dragih in zmogljivih strežnikov, vendar nekatere od teh zmogljivosti niso bile popolnoma izkoriščene.
Naslednja stopnja evolucije so bili virtualni stroji (VM), ki so rešili problem zapravljanja denarja za neporabljene vire. Ta tehnologija je omogočila izvajanje aplikacij neodvisno druga od druge znotraj istega strežnika, pri čemer je dodelil popolnoma izoliran prostor. Toda na žalost ima vsaka tehnologija svoje pomanjkljivosti. Zagon VM zahteva popoln operacijski sistem, ki porabi CPE, RAM, prostor za shranjevanje in, odvisno od operacijskega sistema, je treba upoštevati stroške licence. Ti dejavniki vplivajo na hitrost nalaganja in otežujejo prenosljivost.
In zdaj smo pri kontejnerizaciji. Ponovno ta tehnologija rešuje prejšnji problem, saj vsebniki ne uporabljajo polnega operacijskega sistema, kar sprosti veliko količino virov in zagotavlja hitro in prilagodljivo rešitev za prenosljivost.
Tehnologija kontejnerizacije seveda ni nič novega in je bila prvič predstavljena v poznih 70. letih. V tistih časih je bilo izvedenih veliko raziskav, razvoja in poskusov. Toda Docker je prilagodil to tehnologijo in jo naredil zlahka dostopno množicam. Dandanes, ko govorimo o kontejnerjih, v večini primerov mislimo na Docker. Ko govorimo o vsebnikih Docker, mislimo na vsebnike Linux. Za izvajanje kontejnerjev lahko uporabljamo sisteme Windows in macOS, vendar je pomembno razumeti, da se v tem primeru pojavi dodatna plast. Na primer, Docker na Macu tiho izvaja vsebnike znotraj lahkega virtualnega stroja Linux. K tej temi se bomo vrnili, ko bomo razpravljali o izvajanju emulatorjev Android znotraj vsebnikov, zato je tukaj zelo pomemben odtenek, o katerem je treba podrobneje razpravljati.
Vrednost za infrastrukturo avtomatizacije
Ugotovili smo, da sta kontejnerizacija in Docker kul. Oglejmo si to v kontekstu avtomatizacije, saj mora vsako orodje ali tehnologija rešiti problem. Naj opišemo očitne težave avtomatizacije testiranja v kontekstu testov uporabniškega vmesnika:
- ogromno odvisnosti pri namestitvi Seleniuma in še posebej Appiuma;
- težave z združljivostjo med različicami brskalnikov, simulatorjev in gonilnikov;
- pomanjkanje izoliranega prostora za brskalnike/simulatorje, kar je še posebej kritično za vzporedno delovanje;
- težko upravljati in vzdrževati, če morate zagnati 10, 50, 100 ali celo 1000 brskalnikov hkrati.
Ker pa je Selenium najbolj priljubljeno orodje za avtomatizacijo in Docker najbolj priljubljeno orodje za kontejnerizacijo, ne bi smelo biti presenečenje, da ju je nekdo poskušal združiti, da bi ustvaril zmogljivo orodje za reševanje zgoraj omenjenih težav. Oglejmo si takšne rešitve podrobneje.
Selenova mreža v dockerju
To orodje je najbolj priljubljeno v svetu Selenium za zagon več brskalnikov na več napravah in njihovo upravljanje iz osrednjega vozlišča. Za začetek morate registrirati vsaj 2 dela: vozlišče in vozlišče. Hub je osrednje vozlišče, ki sprejema vse zahteve iz testov in jih distribuira do ustreznih vozlišč. Za vsako vozlišče lahko konfiguriramo specifično konfiguracijo, na primer tako, da določimo želeni brskalnik in njegovo različico. Še vedno pa moramo sami poskrbeti za združljive gonilnike brskalnika in jih namestiti na želena vozlišča. Zaradi tega se Selenium grid ne uporablja v čisti obliki, razen ko moramo delati z brskalniki, ki jih ni mogoče namestiti na Linux OS. Za vse druge primere bi bila precej prilagodljiva in pravilna rešitev uporaba slik Docker za zagon Selenium grid Hub in vozlišč. Ta pristop močno poenostavi upravljanje vozlišča, saj lahko izberemo sliko, ki jo potrebujemo, z že nameščenimi združljivimi različicami brskalnikov in gonilnikov.
Kljub negativnim ocenam stabilnosti, zlasti pri vzporednem izvajanju velikega števila vozlišč, je mreža Selenium še vedno najbolj priljubljeno orodje za vzporedno izvajanje testov Selenium. Pomembno je omeniti, da se v odprtokodnem sistemu nenehno pojavljajo različne izboljšave in modifikacije tega orodja, ki se borijo proti različnim ozkim grlom.
Selenoid za splet
To orodje je preboj v svetu Selenium, saj deluje takoj po izdelavi in je olajšalo življenje številnim inženirjem avtomatizacije. Prvič, to ni še ena sprememba mreže Selenium. Namesto tega so razvijalci ustvarili popolnoma novo različico Selenium Hub v Golangu, ki je v kombinaciji z lahkimi slikami Docker za različne brskalnike dala zagon razvoju avtomatizacije testiranja. Poleg tega moramo v primeru Selenium Grid vnaprej določiti vse zahtevane brskalnike in njihove različice, kar pri delu z enim brskalnikom ni problem. Ko pa gre za več podprtih brskalnikov, je Selenoid rešitev številka ena zahvaljujoč funkciji »brskalnik na zahtevo«. Vse, kar se od nas zahteva, je, da vnaprej prenesemo potrebne slike z brskalniki in posodobimo konfiguracijsko datoteko, s katero sodeluje Selenoid. Ko Selenoid prejme zahtevo od testov, bo samodejno zagnal želeni vsebnik z želenim brskalnikom. Ko bo preizkus končan, bo Selenoid umaknil vsebnik in s tem sprostil sredstva za prihodnje zahteve. Ta pristop popolnoma odpravi dobro znano težavo 'degradacije vozlišča', s katero se pogosto srečujemo v mreži Selenium.
Ampak, žal, Selenoid še vedno ni srebrna krogla. Dobili smo funkcijo »brskalnik na zahtevo«, vendar funkcija »viri na zahtevo« še vedno ni na voljo. Če želimo uporabljati Selenoid, ga moramo namestiti na fizično strojno opremo ali na VM, kar pomeni, da moramo vnaprej vedeti, koliko virov je treba dodeliti. Predvidevam, da to ni problem za majhne projekte, ki vzporedno izvajajo 10, 20 ali celo 30 brskalnikov. Kaj pa, če jih potrebujemo 100, 500, 1000 ali več? Nima smisla ves čas vzdrževati in plačevati toliko virov. V 5. in 6. razdelku tega članka bomo razpravljali o rešitvah, ki vam omogočajo povečanje in s tem občutno zmanjšanje stroškov podjetja.
Selenoid za Android
Po uspehu Selenoida kot orodja za spletno avtomatizacijo so ljudje želeli nekaj podobnega za Android. In zgodilo se je - Selenoid je bil izdan s podporo za Android. Z vidika uporabnika na visoki ravni je princip delovanja podoben spletni avtomatizaciji. Edina razlika je v tem, da Selenoid namesto vsebnikov brskalnika izvaja vsebnike emulatorja Android. Po mojem mnenju je to trenutno najmočnejše brezplačno orodje za vzporedno izvajanje Android testov.
Resnično ne bi želel govoriti o negativnih vidikih tega orodja, saj mi je zelo všeč. Še vedno pa obstajajo enake pomanjkljivosti, ki veljajo za spletno avtomatizacijo in so povezane s skaliranjem. Poleg tega je treba omeniti še eno omejitev, ki nas lahko preseneti, če orodje nastavljamo prvič. Za izvajanje slik Android potrebujemo fizični stroj ali VM s podporo za ugnezdeno virtualizacijo. V vodniku z navodili prikazujem, kako to omogočiti na navideznem računalniku Linux. Vendar, če ste uporabnik macOS in želite lokalno namestiti Selenoid, potem to ne bo mogoče zagnati testov Android. Vedno pa lahko lokalno zaženete Linux VM s konfigurirano "ugnezdeno virtualizacijo" in v njem namestite Selenoid.
Prikaz trenutnega stanja infrastrukture
V okviru tega članka bomo dodali 2 orodji za ponazoritev infrastrukture. To sta Selenium grid za spletne teste in Selenoid za Android teste. V vadnici GitHub vam bom pokazal tudi, kako uporabljati Selenoid za izvajanje spletnih testov.
Povezave za raziskovanje
Podobna orodja
- Obstajajo tudi druga orodja za kontejnerizacijo, vendar je Docker najbolj priljubljen. Če želite poskusiti kaj drugega, ne pozabite, da orodja, ki smo jih opisali za vzporedno izvajanje testov Selenium, ne bodo delovala takoj.
- Kot že rečeno, obstaja veliko modifikacij mreže Selenium, npr..
4.CI/CD
Kratek opis tehnologije
Praksa nenehne integracije je v razvoju precej priljubljena in je enaka sistemom za nadzor različic. Kljub temu se mi zdi, da prihaja do zmede v terminologiji. V tem odstavku bi rad opisal 3 modifikacije te tehnologije z mojega vidika. Na internetu boste našli veliko člankov z različnimi interpretacijami in povsem normalno je, da se vaša mnenja razlikujejo. Najpomembneje je, da si s sodelavci na istem.
Torej, obstajajo 3 izrazi: CI - neprekinjena integracija, CD - neprekinjena dostava in spet CD - neprekinjena uvedba. (Spodaj bom uporabil te izraze v angleščini). Vsaka sprememba doda več dodatnih korakov v vaš razvojni tok. Toda beseda neprekinjeno (neprekinjeno) je najpomembnejša stvar. V tem kontekstu mislimo na nekaj, kar se zgodi od začetka do konca, brez prekinitve ali ročnega posredovanja. Poglejmo CI & CD in CD v tem kontekstu.
- Neprekinjena integracija to je začetni korak evolucije. Po predložitvi nove kode strežniku pričakujemo hitro povratno informacijo, da so naše spremembe v redu. Običajno CI vključuje izvajanje orodij za analizo statične kode in teste enot/internih API-jev. To nam omogoča, da pridobimo informacije o naši kodi v nekaj sekundah/ minutah.
- Nenehna dostava je naprednejši korak, kjer izvajamo teste integracije/UI. Vendar na tej stopnji ne dobimo rezultatov tako hitro kot pri CI. Prvič, te vrste testov trajajo dlje. Drugič, pred zagonom moramo uvesti naše spremembe v testno/uprizoritveno okolje. Poleg tega, če govorimo o mobilnem razvoju, se pojavi dodaten korak za ustvarjanje gradnje naše aplikacije.
- Neprekinjeno uvajanje predvideva, da naše spremembe samodejno izdamo v produkcijo, če so bili v prejšnjih fazah opravljeni vsi sprejemljivi testi. Poleg tega lahko po stopnji izdaje konfigurirate različne stopnje, kot je izvajanje preskusov dima v proizvodnji in zbiranje zanimivih meritev. Neprekinjeno uvajanje je možno le z dobro pokritostjo s samodejnimi testi. Če so potrebni kakršni koli ročni posegi, tudi testiranja, potem tega ni več Neprekinjeno (neprekinjeno). Potem lahko rečemo, da je naš cevovod v skladu samo s prakso neprekinjene dostave.
Vrednost za infrastrukturo avtomatizacije
V tem razdelku bi moral pojasniti, da ko govorimo o preskusih uporabniškega vmesnika od konca do konca, to pomeni, da bi morali svoje spremembe in povezane storitve uvesti v testna okolja. Nenehna integracija - postopek ni uporaben za to nalogo in poskrbeti moramo za izvajanje vsaj praks Nenehne dostave. Neprekinjeno uvajanje je smiselno tudi v kontekstu testov uporabniškega vmesnika, če jih bomo izvajali v produkciji.
In preden pogledamo ilustracijo spremembe arhitekture, želim povedati nekaj besed o GitLab CI. Za razliko od drugih orodij CI/CD GitLab ponuja oddaljeni repozitorij in številne druge dodatne funkcije. Tako je GitLab več kot CI. Vključuje upravljanje izvorne kode, agilno upravljanje, cevovode CI/CD, orodja za beleženje in zbiranje meritev takoj po namestitvi. Arhitekturo GitLab sestavljata Gitlab CI/CD in GitLab Runner. Tukaj je kratek opis z uradne spletne strani:
Gitlab CI/CD je spletna aplikacija z API-jem, ki shranjuje svoje stanje v bazo podatkov, upravlja projekte/gradnje in zagotavlja uporabniški vmesnik. GitLab Runner je aplikacija, ki obdeluje gradnje. Razmestiti ga je mogoče ločeno in deluje z GitLab CI/CD prek API-ja. Za izvajanje testov potrebujete instanco Gitlab in Runner.
Prikaz trenutnega stanja infrastrukture
Povezave za raziskovanje
Podobna orodja
- In mnogi drugi
5. Oblačne platforme
Kratek opis tehnologije
V tem razdelku bomo govorili o priljubljenem trendu, imenovanem 'javni oblaki'. Kljub ogromnim prednostim, ki jih nudita zgoraj opisani tehnologiji virtualizacije in kontejnerizacije, še vedno potrebujemo računalniške vire. Podjetja kupujejo drage strežnike ali najemajo podatkovne centre, vendar je v tem primeru treba narediti izračune (včasih nerealne), koliko virov bomo potrebovali, ali jih bomo uporabljali 24/7 in za kakšne namene. Produkcija na primer zahteva strežnik, ki deluje XNUMX/XNUMX, toda ali potrebujemo podobne vire za testiranje izven delovnega časa? Odvisno je tudi od vrste testiranja, ki se izvaja. Primer bi bili testi obremenitve/obremenitve, ki jih nameravamo izvajati v prostem času, da bi dobili rezultate naslednji dan. Vsekakor pa XNUMX-urna razpoložljivost strežnika ni potrebna za avtomatizirane teste od konca do konca in še posebej ne za okolja ročnega testiranja. Za takšne situacije bi bilo dobro na zahtevo pridobiti toliko sredstev, kot jih potrebujete, jih uporabiti in prenehati plačevati, ko jih ne potrebujete več. Poleg tega bi bilo super, če bi jih prejeli takoj z nekaj kliki miške ali zagonom nekaj skriptov. Za to se uporabljajo javni oblaki. Poglejmo si definicijo:
»Javni oblak je opredeljen kot računalniške storitve, ki jih ponujajo tretji ponudniki prek javnega interneta in jih dajejo na voljo vsem, ki jih želijo uporabljati ali kupiti. Lahko so brezplačni ali pa se prodajajo na zahtevo, kar strankam omogoča, da plačajo samo na uporabo za cikle procesorja, shranjevanje ali pasovno širino, ki jo porabijo."
Obstaja mnenje, da so javni oblaki dragi. Toda njihova ključna ideja je znižanje stroškov podjetja. Kot smo že omenili, vam javni oblaki omogočajo pridobivanje virov na zahtevo in plačilo samo za čas, ko jih uporabljate. Včasih tudi pozabljamo, da zaposleni prejemajo plače, pa tudi strokovnjaki so drag vir. Upoštevati je treba, da javni oblaki močno olajšajo infrastrukturno podporo, kar omogoča inženirjem, da se osredotočijo na pomembnejše naloge.
Vrednost za infrastrukturo avtomatizacije
Katere specifične vire potrebujemo za celovite teste uporabniškega vmesnika? V bistvu so to virtualni stroji ali gruče (o Kubernetesu bomo govorili v naslednjem razdelku) za poganjanje brskalnikov in emulatorjev. Več brskalnikov in emulatorjev želimo zagnati hkrati, več procesorja in pomnilnika potrebujemo in več denarja moramo plačati za to. Tako nam javni oblaki v kontekstu avtomatizacije testiranja omogočajo, da poženemo veliko (100, 200, 1000...) brskalnikov/emulatorjev na zahtevo, čim hitreje dobimo rezultate testov in prenehamo plačevati za tako noro zahtevne vire. moč.
Najbolj priljubljeni ponudniki oblakov so Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Vodnik z navodili ponuja primere uporabe GCP, vendar na splošno ni pomembno, kaj uporabljate za naloge avtomatizacije. Vsi zagotavljajo približno enako funkcionalnost. Običajno se vodstvo pri izbiri ponudnika osredotoči na splošno infrastrukturo in poslovne zahteve podjetja, kar presega obseg tega članka. Za inženirje avtomatizacije bo bolj zanimiva primerjava uporabe ponudnikov v oblaku z uporabo platform v oblaku posebej za namene testiranja, kot so Sauce Labs, BrowserStack, BitBar itd. Torej naredimo to tudi mi! Po mojem mnenju je Sauce Labs najbolj znana farma za testiranje v oblaku, zato sem jo uporabil za primerjavo.
GCP proti Sauce Labs za namene avtomatizacije:
Predstavljajmo si, da moramo zagnati 8 spletnih testov in 8 Android testov hkrati. Za to bomo uporabili GCP in zagnali 2 virtualna stroja s Selenoidom. Na prvem bomo postavili 8 kontejnerjev z brskalniki. Na drugem je 8 vsebnikov z emulatorji. Pa si poglejmo cene:
Za zagon enega vsebnika s Chromom potrebujemo n1-standard-1 avto. V primeru Androida bo tako n1-standard-4 za en emulator. Pravzaprav je bolj prilagodljiv in cenejši način nastavitev specifičnih uporabniških vrednosti za CPU/pomnilnik, vendar to trenutno ni pomembno za primerjavo s Sauce Labs.
In tukaj so tarife za uporabo Sauce Labs:
Verjamem, da ste že opazili razliko, vendar bom vseeno posredoval tabelo z izračuni za našo nalogo:
Zahtevana sredstva
Mesečno
Delovni čas(8 - 8)
Delovni čas+ Prevzemljivo
GCP za splet
n1-standard-1 x 8 = n1-standard-8
$194.18
23 dni * 12 ur * 0.38 = 104.88 USD
23 dni * 12 ur * 0.08 = 22.08 USD
Sauce Labs za splet
Vzporedni testi Virtual Cloud8
$1.559
-
-
GCP za Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 dni * 12 ur * 1.52 = 419.52 USD
23 dni * 12 ur * 0.32 = 88.32 USD
Sauce Labs za Android
Vzporedni testi Real Device Cloud 8
$1.999
-
-
Kot lahko vidite, je razlika v stroških ogromna, še posebej, če izvajate teste samo v dvanajsturnem delovnem obdobju. Stroške pa lahko še dodatno zmanjšate, če uporabljate stroje s preprečevanjem. Kaj je to?
VM s prednostjo je primerek, ki ga lahko ustvarite in zaženete po veliko nižji ceni kot običajni primerki. Vendar lahko Compute Engine prekine (prevzame) te primerke, če zahteva dostop do teh virov za druga opravila. Primerki, ki jih je mogoče prevzeti, so presežne zmogljivosti Compute Engine, zato se njihova razpoložljivost razlikuje glede na uporabo.
Če so vaše aplikacije tolerantne na napake in lahko prenesejo morebitne prednostne instance, potem lahko prednostne instance znatno zmanjšajo vaše stroške Compute Engine. Na primer, opravila paketne obdelave se lahko izvajajo na primerkih, ki jih je mogoče prevzeti. Če se nekateri od teh primerkov prekinejo med obdelavo, se opravilo upočasni, vendar se ne ustavi popolnoma. Preprečljivi primerki dokončajo vaše naloge paketne obdelave, ne da bi dodatno obremenili vaše obstoječe primerke in ne da bi morali plačati polno ceno za dodatne običajne primerke.
In še vedno ni konec! V resnici sem prepričan, da nihče ne izvaja testov 12 ur brez premora. In če je tako, potem lahko samodejno zaženete in zaustavite virtualne stroje, ko jih ne potrebujete. Dejanski čas uporabe se lahko skrajša na 6 ur na dan. Potem se bo plačilo v okviru naše naloge zmanjšalo na 11 USD na mesec za 8 brskalnikov. Ali ni to čudovito? Vendar moramo biti pri strojih, ki jih je mogoče prevzeti, previdni in pripravljeni na prekinitve in nestabilnosti, čeprav je te situacije mogoče predvideti in obravnavati v programski opremi. Je vredno!
Nikakor pa ne trdim, da nikoli ne uporabljajte testnih farm v oblaku. Imajo številne prednosti. Prvič, to ni le navidezni stroj, ampak popolna rešitev za avtomatizacijo testiranja z naborom funkcij takoj po namestitvi: oddaljeni dostop, dnevniki, posnetki zaslona, snemanje videa, različni brskalniki in fizične mobilne naprave. V mnogih situacijah je to lahko bistvena elegantna alternativa. Testne platforme so še posebej uporabne za avtomatizacijo IOS, ko lahko javni oblaki ponujajo le sisteme Linux/Windows. Toda o iOS-u bomo govorili v naslednjih člankih. Priporočam, da vedno pogledate situacijo in začnete pri nalogah: v nekaterih primerih je ceneje in učinkoviteje uporabljati javne oblake, v drugih pa so testne platforme vsekakor vredne porabljenega denarja.
Prikaz trenutnega stanja infrastrukture
Povezave za raziskovanje
Podobna orodja:
6. Orkestracija
Kratek opis tehnologije
Imam dobro novico – skoraj smo pri koncu članka! Trenutno je naša avtomatizacijska infrastruktura sestavljena iz spletnih in Android testov, ki jih vzporedno izvajamo prek GitLab CI z orodji, ki podpirajo Docker: Selenium grid in Selenoid. Poleg tega uporabljamo virtualne stroje, ustvarjene prek GCP, za gostovanje vsebnikov z brskalniki in emulatorji. Za zmanjšanje stroškov te virtualne stroje zaženemo samo na zahtevo in jih zaustavimo, ko se testiranje ne izvaja. Ali lahko še kaj izboljša našo infrastrukturo? Odgovor je da! Spoznajte Kubernetes (K8s)!
Najprej si poglejmo, kako so besede orkestracija, grozd in Kubernetes med seboj povezane. Na visoki ravni je orkestracija sistem, ki namešča in upravlja aplikacije. Za avtomatizacijo testiranja sta taki kontejnerski aplikaciji Selenium grid in Selenoid. Docker in K8 se dopolnjujeta. Prvi se uporablja za uvajanje aplikacij, drugi za orkestracijo. V zameno je K8s grozd. Naloga gruče je uporaba VM kot Nodes, kar omogoča namestitev različnih funkcionalnosti, programov in storitev znotraj enega strežnika (gruče). Če katero od vozlišč odpove, se bodo pobrala druga vozlišča, kar zagotavlja nemoteno delovanje naše aplikacije. Poleg tega ima K8s pomembno funkcionalnost, povezano s skaliranjem, zahvaljujoč kateri samodejno pridobimo optimalno količino virov glede na obremenitev in nastavljene omejitve.
V resnici ročna namestitev Kubernetesa iz nič sploh ni nepomembna naloga. Pustil bom povezavo do znanega vodnika z navodili »Kubernetes The Hard Way« in če vas zanima, ga lahko vadite. Toda na srečo obstajajo alternativne metode in orodja. Najlažji način je uporaba Google Kubernetes Engine (GKE) v GCP, ki vam bo omogočil, da dobite pripravljeno gručo v nekaj klikih. Priporočam uporabo tega pristopa za začetek učenja, saj vam bo omogočil, da se osredotočite na učenje, kako uporabljati K8s za svoje naloge, namesto da se učite, kako je treba notranje komponente integrirati skupaj.
Vrednost za infrastrukturo avtomatizacije
Oglejmo si nekaj pomembnih funkcij, ki jih ponuja K8s:
- uvedba aplikacije: uporaba gruče z več vozlišči namesto navideznih strojev;
- dinamično skaliranje: zmanjša stroške virov, ki se uporabljajo samo na zahtevo;
- samozdravljenje: samodejno pridobivanje strokov (zaradi česar se obnovijo tudi posode);
- uvedba posodobitev in povrnitve sprememb brez izpadov: posodabljanje orodij, brskalnikov in emulatorjev ne prekine dela trenutnih uporabnikov
Toda K8s še vedno ni srebrna krogla. Da bi razumeli vse prednosti in omejitve v kontekstu orodij, ki jih obravnavamo (Selenium grid, Selenoid), bomo na kratko obravnavali strukturo K8s. Grozd vsebuje dve vrsti vozlišč: glavna vozlišča in delovna vozlišča. Glavna vozlišča so odgovorna za odločitve o upravljanju, uvajanju in načrtovanju. Delovna vozlišča so tam, kjer se izvajajo aplikacije. Vozlišča vsebujejo tudi izvajalno okolje vsebnika. V našem primeru je to Docker, ki je odgovoren za operacije, povezane z vsebniki. Obstajajo pa tudi alternativne rešitve, npr. Pomembno je razumeti, da se luščenje ali samozdravljenje ne nanaša neposredno na posode. To se izvede z dodajanjem/zmanjšanjem števila podov, ki nato vsebujejo vsebnike (običajno en vsebnik na pod, odvisno od naloge pa jih je lahko več). Hierarhija na visoki ravni je sestavljena iz delovnih vozlišč, znotraj katerih so podi, znotraj katerih so dvignjeni vsebniki.
Funkcija skaliranja je ključna in jo je mogoče uporabiti tako za vozlišča znotraj skupine vozlišč gruče kot za pode znotraj vozlišča. Obstajata dve vrsti skaliranja, ki veljata za vozlišča in pode. Prva vrsta je horizontalna - skaliranje se pojavi s povečanjem števila vozlišč/podov. Ta vrsta je bolj zaželena. Druga vrsta je torej navpična. Skaliranje se izvaja s povečanjem velikosti vozlišč/podov in ne njihovega števila.
Zdaj pa si poglejmo naša orodja v kontekstu zgornjih izrazov.
Selenska mreža
Kot smo že omenili, je mreža Selenium zelo priljubljeno orodje in ni presenetljivo, da je bilo posodobljeno. Zato ne preseneča, da je omrežje Selenium mogoče namestiti v K8. Primer, kako to storiti, je na voljo v uradnem repozitoriju K8s. Kot ponavadi na koncu razdelka prilagam povezave. Poleg tega vodnik z navodili prikazuje, kako to storiti v Terraformu. Obstajajo tudi navodila, kako povečati število podov, ki vsebujejo vsebnike brskalnika. Toda funkcija samodejnega skaliranja v kontekstu K8s še vedno ni povsem očitna naloga. Ko sem začel študirati, nisem našel nobenih praktičnih napotkov ali priporočil. Po več študijah in poskusih s podporo ekipe DevOps smo izbrali pristop dviga vsebnikov s potrebnimi brskalniki znotraj enega poda, ki se nahaja znotraj enega delovnega vozlišča. Ta metoda nam omogoča uporabo strategije horizontalnega skaliranja vozlišč s povečanjem njihovega števila. Upam, da se bo to v prihodnosti spremenilo in bomo videli vedno več opisov boljših pristopov in že pripravljenih rešitev, še posebej po izidu Selenium grid 4 s spremenjeno notranjo arhitekturo.
Selenoid:
Namestitev selenoida v K8s je trenutno največje razočaranje. Niso kompatibilni. Teoretično lahko dvignemo vsebnik Selenoid znotraj sklopa, toda ko Selenoid začne zaganjati vsebnike z brskalniki, bodo še vedno znotraj istega sklopa. To onemogoči skaliranje in posledično se delo Selenoida znotraj gruče ne bo razlikovalo od dela znotraj virtualnega stroja. Konec zgodbe.
Luna:
Ker poznajo to ozko grlo pri delu s Selenoidom, so razvijalci izdali močnejše orodje, imenovano Moon. To orodje je bilo prvotno zasnovano za delo s Kubernetes in posledično se lahko in mora uporabljati funkcija samodejnega skaliranja. Še več, rekel bi, da trenutno je edini orodje v svetu Selenium, ki ima prvotno podporo za gruče K8s (ni več na voljo, glejte naslednje orodje ). Ključne funkcije Moon, ki zagotavljajo to podporo, so:
Popolnoma brez državljanstva. Selenoid shrani v pomnilnik informacije o trenutno delujočih sejah brskalnika. Če se iz nekega razloga njegov proces zruši — potem so vse tekoče seje izgubljene. Nasprotno pa Moon nima notranjega stanja in se lahko replicira v podatkovnih centrih. Seje brskalnika ostanejo žive, tudi če ena ali več replik ne deluje.
Torej, Moon je odlična rešitev, vendar obstaja ena težava: ni zastonj. Cena je odvisna od števila srečanj. Brezplačno lahko izvajate samo 0-4 seje, kar ni posebej uporabno. Toda od pete seje naprej boste morali plačati 5 $ za vsako. Situacija se lahko razlikuje od podjetja do podjetja, vendar je v našem primeru uporaba Moon nesmiselna. Kot sem opisal zgoraj, lahko na zahtevo izvajamo VM s Selenium Grid ali povečamo število vozlišč v gruči. Za približno en cevovod zaženemo 500 brskalnikov in ustavimo vse vire, ko so testi končani. Če bi uporabljali Moon, bi morali plačati dodatnih 500 x 5 = 2500 USD na mesec, ne glede na to, kako pogosto izvajamo teste. Še enkrat, ne pravim, da ne uporabljajte Moon. Za vaše naloge je to lahko nepogrešljiva rešitev, na primer, če imate v organizaciji veliko projektov/ekip in potrebujete ogromen skupni grozd za vse. Kot vedno pustim povezavo na koncu in priporočam, da opravite vse potrebne izračune v okviru vaše naloge.
Callisto: (Pozor! Tega ni v izvirnem članku in je le v ruskem prevodu)
Kot sem rekel, je Selenium zelo priljubljeno orodje, področje IT pa se zelo hitro razvija. Medtem ko sem delal na prevodu, se je na spletu pojavilo novo obetavno orodje Callisto (pozdravljeni Cypress in drugi ubijalci selena). Deluje izvorno s K8 in vam omogoča zagon Selenoidnih vsebnikov v sklopih, porazdeljenih po vozliščih. Vse deluje takoj po izdelavi, vključno s samodejnim skaliranjem. Fantastično, vendar ga je treba preizkusiti. To orodje mi je že uspelo namestiti in izvesti več poskusov. Vendar je še prezgodaj za sklepanje, potem ko bom prejel rezultate na dolgi razdalji, bom morda naredil pregled v prihodnjih člankih. Zaenkrat puščam samo povezave za samostojno raziskovanje.
Prikaz trenutnega stanja infrastrukture
Povezave za raziskovanje
Podobna orodja
7. Infrastruktura kot koda (IaC)
Kratek opis tehnologije
In zdaj smo prišli do zadnjega dela. Običajno ta tehnologija in sorodne naloge niso odgovornost inženirjev za avtomatizacijo. In za to obstajajo razlogi. Prvič, v mnogih organizacijah so vprašanja infrastrukture pod nadzorom oddelka DevOps in razvojne skupine pravzaprav ne skrbijo, kaj omogoča delovanje cevovoda in kako je treba podpirati vse, kar je z njim povezano. Drugič, bodimo iskreni, praksa infrastrukture kot kodeksa (IaC) še vedno ni sprejeta v mnogih podjetjih. Vsekakor pa je postal priljubljen trend in pomembno je, da se poskušamo vključiti v procese, pristope in orodja, ki so z njim povezani. Ali pa vsaj ostanite na tekočem.
Začnimo z motivacijo za uporabo tega pristopa. Razpravljali smo že o tem, da bomo za izvajanje testov v GitlabCI potrebovali najmanj sredstva za izvajanje Gitlab Runnerja. Za zagon vsebnikov z brskalniki/emulatorji moramo rezervirati VM ali gručo. Poleg virov za testiranje potrebujemo precejšnjo količino zmogljivosti za podporo razvojnih, uprizoritvenih, produkcijskih okolij, kar vključuje tudi baze podatkov, samodejne urnike, omrežne konfiguracije, izravnalnike obremenitve, uporabniške pravice itd. Ključno vprašanje je napor, potreben za podporo vsemu. Obstaja več načinov, kako lahko spremenimo in uvedemo posodobitve. Na primer, v kontekstu GCP lahko uporabimo konzolo uporabniškega vmesnika v brskalniku in izvajamo vsa dejanja s klikanjem gumbov. Druga možnost bi bila uporaba klicev API za interakcijo z entitetami v oblaku ali uporaba pripomočka ukazne vrstice gcloud za izvajanje želenih manipulacij. Toda z res velikim številom različnih entitet in infrastrukturnih elementov postane težko ali celo nemogoče vse operacije izvajati ročno. Poleg tega so vsa ta ročna dejanja neobvladljiva. Ne moremo jih predložiti v pregled pred izvedbo, uporabiti sistem za nadzor različic in hitro vrniti sprememb, ki so privedle do incidenta. Za rešitev takšnih težav so inženirji ustvarili in izdelali samodejne skripte bash/shell, ki niso veliko boljši od prejšnjih metod, saj jih ni tako enostavno hitro prebrati, razumeti, vzdrževati in spreminjati v proceduralnem slogu.
V tem članku in navodilih za uporabo uporabljam 2 orodji, povezani s prakso IAC. To sta Terraform in Ansible. Nekateri menijo, da jih nima smisla uporabljati hkrati, saj je njihova funkcionalnost podobna in so zamenljivi. A dejstvo je, da so na začetku dobili povsem drugačne naloge. In da se morajo ta orodja dopolnjevati, so na skupni predstavitvi potrdili razvijalci, ki predstavljata HashiCorp in RedHat. Konceptualna razlika je v tem, da je Terraform orodje za zagotavljanje storitev za upravljanje samih strežnikov. Medtem ko je Ansible orodje za upravljanje konfiguracije, katerega naloga je namestitev, konfiguracija in upravljanje programske opreme na teh strežnikih.
Druga ključna značilnost teh orodij je slog kodiranja. Za razliko od bash in Ansible uporablja Terraform deklarativni slog, ki temelji na opisu želenega končnega stanja, ki ga je treba doseči kot rezultat izvajanja. Na primer, če bomo ustvarili 10 VM-jev in uporabili spremembe prek Terraforma, bomo dobili 10 VM-jev. Če znova zaženemo skripto, se ne bo zgodilo nič, saj že imamo 10 VM-jev, Terraform pa to ve, ker hrani trenutno stanje infrastrukture v datoteki stanja. Toda Ansible uporablja proceduralni pristop in če od njega zahtevate, da ustvari 10 VM-jev, bomo ob prvem zagonu dobili 10 VM-jev, podobno kot Terraform. Toda po ponovnem zagonu bomo že imeli 20 VM. To je pomembna razlika. V proceduralnem slogu ne shranjujemo trenutnega stanja in preprosto opišemo zaporedje korakov, ki jih je treba izvesti. Seveda lahko obvladamo različne situacije, dodamo več preverjanj obstoja virov in trenutnega stanja, vendar nima smisla izgubljati časa in se truditi nadzirati to logiko. Poleg tega se s tem poveča tveganje za napake.
Če povzamemo vse zgoraj navedeno, lahko zaključimo, da sta Terraform in deklarativni zapis primernejše orodje za zagotavljanje strežnikov. Vendar je bolje, da delo upravljanja konfiguracije prenesete na Ansible. Če tega ne naredimo, si poglejmo primere uporabe v kontekstu avtomatizacije.
Vrednost za infrastrukturo avtomatizacije
Edina pomembna stvar, ki jo morate razumeti, je, da je treba infrastrukturo za avtomatizacijo testiranja obravnavati kot del celotne infrastrukture podjetja. To pomeni, da je treba vse prakse IAC uporabljati globalno za vire celotne organizacije. Kdo je za to odgovoren, je odvisno od vaših procesov. Ekipa DevOps je bolj izkušena v teh vprašanjih, vidijo celotno sliko dogajanja. Vendar pa so QA inženirji bolj vključeni v proces avtomatizacije zgradbe in strukturo cevovoda, kar jim omogoča, da bolje vidijo vse potrebne spremembe in priložnosti za izboljšave. Najboljša možnost je sodelovanje, izmenjava znanja in idej za dosego pričakovanega rezultata.
Tukaj je nekaj primerov uporabe Terraform in Ansible v kontekstu avtomatizacije testiranja in orodij, o katerih smo razpravljali prej:
1. Opišite potrebne značilnosti in parametre VM-jev in gruč z uporabo Terraforma.
2. Z uporabo Ansible namestite orodja, potrebna za testiranje: docker, Selenoid, Selenium Grid in prenesite zahtevane različice brskalnikov/emulatorjev.
3. S pomočjo Terraforma opišite značilnosti VM, v katerem se bo zagnal GitLab Runner.
4. Namestite GitLab Runner in potrebna spremljajoča orodja z uporabo Ansible, nastavite nastavitve in konfiguracije.
Prikaz trenutnega stanja infrastrukture
Povezave za raziskovanje:
Podobna orodja
Naj povzamemo!
Korak
Tehnologija
Orodja
Vrednost za infrastrukturo avtomatizacije
1
Lokalni tek
Node.js, Selenium, Appium
- Najbolj priljubljena orodja za splet in mobilne naprave
- Podpira veliko jezikov in platform (vključno z Node.js)
2
Sistemi za nadzor različic
git
- Podobne ugodnosti z razvojno kodo
3
Kontejnerizacija
Docker, mreža Selenium, Selenoid (splet, Android)
- Vzporedno izvajanje testov
- Izolirana okolja
- Preproste, prilagodljive nadgradnje različic
- Dinamično zaustavitev neuporabljenih virov
- Enostavna nastavitev
4
CI/CD
Gitlab CI
- Preizkuša del cevovoda
- Hitra povratna informacija
- Prepoznavnost za celotno podjetje/ekipo
5
Oblačne platforme
Google Cloud Platform
- Sredstva na zahtevo (plačamo le, ko je potrebno)
- Enostaven za upravljanje in posodabljanje
- Preglednost in nadzor nad vsemi viri
6
Orkestracija
Kubernetes
V kontekstu vsebnikov z brskalniki/emulatorji znotraj sklopov:
- Skaliranje/samodejno skaliranje
- Samozdravljenje
- Posodobitve in povrnitve brez prekinitve
7
Infrastruktura kot koda (IaC)
Terraform, Ansible
- Podobne koristi z razvojno infrastrukturo
- Vse prednosti različic kode
- Enostaven za spreminjanje in vzdrževanje
- Popolnoma avtomatizirano
Diagrami miselnih zemljevidov: razvoj infrastrukture
1. korak: lokalno
2. korak: VCS
3. korak: Kontejnerizacija
4. korak: CI/CD
5. korak: Platforme v oblaku
6. korak: Orkestracija
7. korak: IaC
Kaj sledi?
Torej, to je konec članka. Za zaključek pa bi rad z vami sklenil nekaj dogovorov.
S tvoje strani
Kot sem rekel na začetku, bi rad, da bi bil članek praktično uporaben in vam pomagal uporabiti pridobljeno znanje v resničnem delu. še enkrat dodajam.
Toda tudi po tem se ne ustavite, vadite, preučite ustrezne povezave in knjige, ugotovite, kako deluje v vašem podjetju, poiščite mesta, ki jih je mogoče izboljšati, in sodelujte pri tem. Vso srečo!
Z moje strani
Že iz naslova je razvidno, da je bil to le prvi del. Kljub temu, da se je izkazalo za precej veliko, pomembne teme še vedno niso zajete. V drugem delu nameravam pogledati infrastrukturo avtomatizacije v kontekstu IOS. Zaradi Applovih omejitev izvajanja iOS simulatorjev samo v sistemih macOS je naš nabor rešitev zožen. Na primer, ne moremo uporabiti Dockerja za zagon simulatorja ali javnih oblakov za zagon virtualnih strojev. Vendar to ne pomeni, da ni drugih alternativ. Poskušal vas bom obveščati z naprednimi rešitvami in sodobnimi orodji!
Prav tako nisem omenil precej velikih tem, povezanih z nadzorom. V 3. delu si bom ogledal najbolj priljubljena orodja za spremljanje infrastrukture ter katere podatke in meritve je treba upoštevati.
In končno. V prihodnosti nameravam izdati video tečaj o izgradnji testne infrastrukture in priljubljenih orodij. Trenutno je na spletu kar nekaj tečajev in predavanj o DevOps, vendar so vsa gradiva predstavljena v kontekstu razvoja, ne avtomatizacije testiranja. V zvezi s tem vprašanjem resnično potrebujem povratne informacije o tem, ali bo tak tečaj zanimiv in dragocen za skupnost preizkuševalcev in inženirjev avtomatizacije. Hvala v naprej!
Vir: www.habr.com