Deel 1: Web/Android
Let daarop: hierdie artikel is 'n vertaling in Russies van die oorspronklike artikel Alle illustrasies, skakels, aanhalings en terme word egter in die oorspronklike taal bewaar om verdraaiing van die betekenis te voorkom wanneer dit in Russies vertaal word. Ek wens jou gelukkige studie toe!
Tans is die DevOps-spesialiteit een van die mees in aanvraag in die IT-industrie. As jy gewilde werksoekwebwerwe oopmaak en volgens salaris filter, sal jy sien dat DevOps-verwante poste boaan die lys is. Dit is egter belangrik om te verstaan dat dit hoofsaaklik verwys na 'n 'Senior' posisie, wat impliseer dat die kandidaat 'n hoë vlak van vaardighede, kennis van tegnologie en gereedskap het. Dit kom ook met 'n hoë mate van verantwoordelikheid wat verband hou met die ononderbroke werking van produksie. Ons het egter begin vergeet wat DevOps is. Aanvanklik was dit nie enige spesifieke persoon of departement nie. As ons na definisies van hierdie term soek, sal ons baie mooi en korrekte selfstandige naamwoorde kry, soos metodologie, praktyke, kultuurfilosofie, groep konsepte, ensovoorts.
My spesialisasie is 'n toetsoutomatiseringsingenieur (QA outomatiseringsingenieur), maar ek glo dat dit nie net geassosieer moet word met die skryf van outotoetse of die ontwikkeling van toetsraamwerkargitektuur nie. In 2020 is kennis van outomatiseringsinfrastruktuur ook noodsaaklik. Dit laat jou toe om self die outomatiseringsproses te organiseer, van die uitvoer van toetse tot die verskaffing van resultate aan alle belanghebbendes in ooreenstemming met jou doelwitte. As gevolg hiervan is DevOps-vaardighede 'n moet om die werk gedoen te kry. En dit alles is goed, maar daar is ongelukkig 'n probleem (bederf: hierdie artikel poog om hierdie probleem te vereenvoudig). Die punt is dat DevOps moeilik is. En dit is voor die hand liggend, want maatskappye sal nie baie betaal vir iets wat maklik is om te doen nie... In die DevOps-wêreld is daar 'n groot aantal gereedskap, terme en praktyke wat bemeester moet word. Dit is veral moeilik aan die begin van 'n loopbaan en hang af van die opgehoopte tegniese ervaring.
Bron:
Hier sal ons waarskynlik eindig met die inleidende deel en fokus op die doel van hierdie artikel.
Waaroor gaan hierdie artikel?
In hierdie artikel gaan ek my ervaring van die bou van 'n toetsoutomatiseringsinfrastruktuur deel. Daar is baie bronne van inligting op die internet oor verskeie instrumente en hoe om dit te gebruik, maar ek wil suiwer daarna kyk in die konteks van outomatisering. Ek glo dat baie outomatiseringsingenieurs vertroud is met die situasie wanneer niemand behalwe jy die ontwikkelde toetse uitvoer of omgee om dit in stand te hou nie. Gevolglik raak toetse verouderd en jy moet tyd spandeer om dit op te dateer. Weereens, aan die begin van 'n loopbaan, kan dit nogal 'n moeilike taak wees: om verstandig te besluit watter instrumente moet help om 'n gegewe probleem uit te skakel, hoe om dit te kies, op te stel en in stand te hou. Sommige toetsers wend hulle tot DevOps (mense) vir hulp en, laat ons eerlik wees, hierdie benadering werk. In baie gevalle kan dit die enigste opsie wees aangesien ons nie sigbaarheid in alle afhanklikhede het nie. Maar soos ons weet, is DevOps baie besige ouens, want hulle moet dink aan die hele maatskappy se infrastruktuur, ontplooiing, monitering, mikrodienste en ander soortgelyke take, afhangende van die organisasie/span. Soos gewoonlik die geval is, is outomatisering nie 'n prioriteit nie. In so 'n geval moet ons van begin tot einde alles moontlik van ons kant af probeer doen. Dit sal afhanklikhede verminder, werkvloei versnel, ons vaardighede verbeter en ons in staat stel om die groter prentjie te sien van wat aan die gebeur is.
Die artikel bied die gewildste en gewildste instrumente aan en wys hoe om dit stap vir stap te gebruik om 'n outomatiseringsinfrastruktuur te bou. Elke groep word verteenwoordig deur gereedskap wat deur persoonlike ervaring getoets is. Maar dit beteken nie dat jy dieselfde ding moet gebruik nie. Die gereedskap self is nie belangrik nie, dit kom voor en raak verouderd. Ons ingenieurstaak is om die basiese beginsels te verstaan: hoekom ons hierdie groep gereedskap benodig en watter werkprobleme ons met hul hulp kan oplos. Daarom laat ek aan die einde van elke afdeling skakels na soortgelyke hulpmiddels wat in jou organisasie gebruik kan word.
Wat is nie in hierdie artikel
Ek herhaal weereens dat die artikel nie oor spesifieke gereedskap gaan nie, so daar sal geen invoegings van kode uit die dokumentasie en beskrywings van spesifieke opdragte wees nie. Maar aan die einde van elke afdeling laat ek skakels vir gedetailleerde studie.
Dit word gedoen omdat:
- hierdie materiaal is baie maklik om in verskeie bronne te vind (dokumentasie, boeke, videokursusse);
- as ons dieper begin gaan, sal ons 10, 20, 30 dele van hierdie artikel moet skryf (terwyl die planne 2-3 is);
- Ek wil net nie jou tyd mors nie, aangesien jy dalk ander gereedskap wil gebruik om dieselfde doelwitte te bereik.
Praktyk
Ek wil baie graag hê dat hierdie materiaal vir elke leser nuttig moet wees, en nie net gelees en vergeet word nie. In enige studie is oefening 'n baie belangrike komponent. Hiervoor het ek voorberei. Daar is ook huiswerk wat vir jou wag om seker te maak dat jy nie die reëls van die opdragte wat jy uitvoer, onbedagsaam kopieer nie.
plan
stap
Tegnologie
Gereedskap
1
Plaaslike loop (berei web- / Android-demo-toetse voor en voer dit plaaslik uit)
Node.js, Selenium, Appium
2
Weergawebeheerstelsels
gaan
3
Houerisering
Docker, Selenium rooster, Selenoid (Web, Android)
4
CI/CD
Gitlab CI
5
Wolkplatforms
Google Wolkplatform
6
orkestrasie
Kubernetes
7
Infrastruktuur as 'n kode (IAC)
Terraform, Ansible
Struktuur van elke afdeling
Om die verhaal duidelik te hou, word elke afdeling volgens die volgende uiteensetting beskryf:
- kort beskrywing van die tegnologie,
- waarde vir outomatiseringsinfrastruktuur,
- illustrasie van die huidige stand van die infrastruktuur,
- skakels na studie,
- soortgelyke gereedskap.
1. Doen toetse plaaslik
Kort beskrywing van die tegnologie
Dit is net 'n voorbereidende stap om die demo-toetse plaaslik uit te voer en te verifieer dat hulle slaag. In die praktiese deel word Node.js gebruik, maar die programmeertaal en platform is ook nie belangrik nie en jy kan dié gebruik wat in jou maatskappy gebruik word.
As outomatiseringsinstrumente beveel ek egter aan om onderskeidelik Selenium WebDriver vir webplatforms en Appium vir Android-platforms te gebruik, aangesien ons in die volgende stappe Docker-beelde sal gebruik wat aangepas is om spesifiek met hierdie instrumente te werk. Verder, met verwysing na die posvereistes, is hierdie gereedskap die meeste in die mark in aanvraag.
Soos jy dalk opgemerk het, oorweeg ons net web- en Android-toetse. Ongelukkig is iOS 'n heeltemal ander storie (dankie Apple). Ek beplan om IOS-verwante oplossings en praktyke in komende dele ten toon te stel.
Waarde vir outomatiseringsinfrastruktuur
Vanuit 'n infrastruktuurperspektief bied dit geen waarde om plaaslik te hardloop nie. Jy kyk net dat die toetse op die plaaslike masjien in plaaslike blaaiers en simulators loop. Maar dit is in elk geval 'n noodsaaklike beginpunt.
Illustrasie van die huidige stand van infrastruktuur
Skakels om te verken
Soortgelyke gereedskap
- enige programmeertaal waarvan jy hou in samewerking met Selenium/Appium-toetse;
- enige toetse;
- enige toetsloper.
2. Weergawebeheerstelsels (Git)
Kort beskrywing van die tegnologie
Dit sal vir niemand 'n groot openbaring wees as ek sê dat weergawebeheer 'n uiters belangrike deel van ontwikkeling is, beide in 'n span en individueel. Gebaseer op verskeie bronne, is dit veilig om te sê dat Git die gewildste verteenwoordiger is. 'n Weergawebeheerstelsel bied baie voordele, soos kodedeling, berging van weergawes, herstel na vorige takke, monitering van projekgeskiedenis en rugsteun. Ons sal nie elke punt in detail bespreek nie, aangesien ek seker is dat jy baie vertroud is daarmee en dit in jou daaglikse werk gebruik. Maar as dit skielik nie gebeur nie, beveel ek aan om hierdie artikel te onderbreek en hierdie gaping so gou as moontlik te vul.
Waarde vir outomatiseringsinfrastruktuur
En hier kan jy ’n redelike vraag vra: “Hoekom vertel hy ons van Git? Almal weet dit en gebruik dit beide vir ontwikkelingskode en vir outotoetskode.” Jy sal heeltemal reg wees, maar in hierdie artikel praat ons van infrastruktuur en hierdie afdeling dien as 'n voorskou vir afdeling 7: "Infrastruktuur as kode (IaC)". Vir ons beteken dit dat die hele infrastruktuur, insluitend toetsing, in die vorm van kode beskryf word, sodat ons ook weergawestelsels daarop kan toepas en soortgelyke voordele kry as vir ontwikkeling en outomatiseringskode.
Ons sal in meer detail na IaC kyk in Stap 7, maar selfs nou kan jy Git plaaslik begin gebruik deur 'n plaaslike bewaarplek te skep. Die groot prentjie sal uitgebrei word wanneer ons 'n afgeleë bewaarplek by die infrastruktuur voeg.
Illustrasie van die huidige stand van infrastruktuur
Skakels om te verken
Soortgelyke gereedskap
3. Containerization (Docker)
Kort beskrywing van die tegnologie
Om te demonstreer hoe containerisering die reëls van die spel verander het, kom ons gaan 'n paar dekades terug in tyd. Destyds het mense bedienermasjiene gekoop en gebruik om toepassings te laat loop. Maar in die meeste gevalle was die vereiste opstarthulpbronne nie vooraf bekend nie. Gevolglik het maatskappye geld bestee aan die aankoop van duur, kragtige bedieners, maar sommige van hierdie kapasiteit is nie heeltemal benut nie.
Die volgende fase van evolusie was virtuele masjiene (VM's), wat die probleem opgelos het om geld op ongebruikte hulpbronne te mors. Hierdie tegnologie het dit moontlik gemaak om toepassings onafhanklik van mekaar binne dieselfde bediener te laat loop, wat heeltemal geïsoleerde ruimte toewys. Maar ongelukkig het enige tegnologie sy nadele. Die bestuur van 'n VM vereis 'n volledige bedryfstelsel, wat SVE, RAM, berging verbruik en, afhangende van die bedryfstelsel, moet lisensiekoste in ag geneem word. Hierdie faktore beïnvloed laaispoed en maak draagbaarheid moeilik.
En nou kom ons by containerisering. Weereens los hierdie tegnologie die vorige probleem op, aangesien houers nie 'n volledige bedryfstelsel gebruik nie, wat 'n groot hoeveelheid hulpbronne vrystel en 'n vinnige en buigsame oplossing vir oordraagbaarheid bied.
Natuurlik is containeriseringstegnologie niks nuuts nie en is die eerste keer in die laat 70's bekendgestel. In daardie dae is baie navorsing, ontwikkelings en pogings uitgevoer. Maar dit was Docker wat hierdie tegnologie aangepas het en dit maklik toeganklik vir die massa gemaak het. Deesdae, as ons oor houers praat, bedoel ons in die meeste gevalle Docker. As ons oor Docker-houers praat, bedoel ons Linux-houers. Ons kan Windows- en macOS-stelsels gebruik om houers te laat loop, maar dit is belangrik om te verstaan dat in hierdie geval 'n bykomende laag verskyn. Byvoorbeeld, Docker op Mac laat houers stilweg binne 'n liggewig Linux VM hardloop. Ons sal na hierdie onderwerp terugkeer wanneer ons die bestuur van Android-emulators binne houers bespreek, so hier is 'n baie belangrike nuanse wat in meer besonderhede bespreek moet word.
Waarde vir outomatiseringsinfrastruktuur
Ons het uitgevind dat containerization en Docker cool is. Kom ons kyk hierna in die konteks van outomatisering, want elke instrument of tegnologie moet 'n probleem oplos. Kom ons skets die ooglopende probleme van toetsoutomatisering in die konteks van UI-toetse:
- 'n groot aantal afhanklikhede wanneer Selenium en veral Appium geïnstalleer word;
- verenigbaarheidsprobleme tussen weergawes van blaaiers, simulators en drywers;
- gebrek aan geïsoleerde spasie vir blaaiers/simulators, wat veral krities is vir parallel loop;
- moeilik om te bestuur en in stand te hou as jy 10, 50, 100 of selfs 1000 blaaiers op dieselfde tyd moet laat loop.
Maar aangesien Selenium die gewildste outomatiseringsinstrument is en Docker die gewildste containeriseringsinstrument is, behoort dit geen verrassing te wees dat iemand dit probeer kombineer het om 'n kragtige instrument te skep om bogenoemde probleme op te los nie. Kom ons kyk na sulke oplossings in meer detail.
Seleniumrooster in docker
Hierdie instrument is die gewildste in die Selenium-wêreld om verskeie blaaiers op verskeie masjiene te laat loop en dit vanaf 'n sentrale spilpunt te bestuur. Om te begin, moet jy ten minste 2 dele registreer: Hub en Node(s). Hub is 'n sentrale nodus wat alle versoeke van toetse ontvang en dit na die toepaslike nodusse versprei. Vir elke Node kan ons 'n spesifieke konfigurasie opstel, byvoorbeeld deur die verlangde blaaier en sy weergawe te spesifiseer. Ons moet egter steeds self sorg vir versoenbare blaaierbestuurders en dit op die gewenste nodusse installeer. Om hierdie rede word Selenium-rooster nie in sy suiwer vorm gebruik nie, behalwe wanneer ons met blaaiers moet werk wat nie op Linux OS geïnstalleer kan word nie. Vir alle ander gevalle sal 'n aansienlik buigsame en korrekte oplossing wees om Docker-beelde te gebruik om Selenium-roosterhub en -nodes te laat loop. Hierdie benadering vergemaklik knooppuntbestuur aansienlik, aangesien ons die prent wat ons benodig kan kies met versoenbare weergawes van blaaiers en drywers wat reeds geïnstalleer is.
Ten spyte van negatiewe resensies oor stabiliteit, veral wanneer 'n groot aantal nodusse parallel uitgevoer word, is Selenium-rooster steeds die gewildste instrument om Selenium-toetse parallel te laat loop. Dit is belangrik om daarop te let dat verskeie verbeterings en wysigings van hierdie instrument voortdurend in oopbron verskyn, wat verskeie knelpunte bekamp.
Selenoïed vir die web
Hierdie instrument is 'n deurbraak in die wêreld van Selenium, aangesien dit reg uit die boks werk en die lewe van baie outomatiseringsingenieurs baie makliker gemaak het. In die eerste plek, dit is nie nog 'n verandering van Selenium rooster. In plaas daarvan het die ontwikkelaars 'n heeltemal nuwe weergawe van Selenium Hub in Golang geskep, wat gekombineer met liggewig Docker-beelde vir verskeie blaaiers, stukrag gegee het aan die ontwikkeling van toetsoutomatisering. Verder, in die geval van Selenium Grid, moet ons vooraf al die vereiste blaaiers en hul weergawes bepaal, wat nie 'n probleem is as u met slegs een blaaier werk nie. Maar as dit by veelvuldige ondersteunde blaaiers kom, is Selenoid die nommer een oplossing danksy sy 'blaaier op aanvraag'-funksie. Al wat van ons vereis word, is om vooraf die nodige beelde met blaaiers af te laai en die konfigurasielêer waarmee Selenoid interaksie het, op te dateer. Nadat Selenoid 'n versoek van die toetse ontvang het, sal dit outomaties die verlangde houer met die verlangde blaaier begin. Wanneer die toets voltooi is, sal Selenoid die houer onttrek en sodoende hulpbronne vir toekomstige versoeke vrystel. Hierdie benadering elimineer heeltemal die bekende probleem van 'node-degradasie' wat ons dikwels in Selenium-rooster teëkom.
Maar, helaas, Selenoid is steeds nie 'n silwer koeël nie. Ons het die 'blaaier op aanvraag'-kenmerk gekry, maar die 'hulpbronne op aanvraag'-kenmerk is steeds nie beskikbaar nie. Om Selenoid te gebruik, moet ons dit op fisiese hardeware of op 'n VM ontplooi, wat beteken dat ons vooraf moet weet hoeveel hulpbronne toegewys moet word. Ek dink dit is nie 'n probleem vir klein projekte wat 10, 20 of selfs 30 blaaiers parallel loop nie. Maar wat as ons 100, 500, 1000 of meer nodig het? Dit maak geen sin om heeltyd soveel hulpbronne in stand te hou en daarvoor te betaal nie. In afdelings 5 en 6 van hierdie artikel sal ons oplossings bespreek wat jou toelaat om te skaal, en sodoende maatskappykoste aansienlik verminder.
Selenoid vir Android
Na die sukses van Selenoid as 'n weboutomatiseringsinstrument, wou mense iets soortgelyks vir Android hê. En dit het gebeur - Selenoid is vrygestel met Android-ondersteuning. Vanuit 'n hoëvlakgebruikersoogpunt is die werkingsbeginsel soortgelyk aan weboutomatisering. Die enigste verskil is dat Selenoid in plaas van blaaierhouers Android-emulatorhouers bestuur. Na my mening is dit tans die kragtigste gratis hulpmiddel om Android-toetse parallel te laat loop.
Ek wil regtig nie oor die negatiewe aspekte van hierdie instrument praat nie, aangesien ek regtig baie daarvan hou. Maar steeds is daar dieselfde nadele wat van toepassing is op weboutomatisering en wat met skaal geassosieer word. Benewens hierdie, moet ons praat oor nog 'n beperking wat as 'n verrassing kan wees as ons die instrument vir die eerste keer opstel. Om Android-beelde te laat loop, benodig ons 'n fisiese masjien of VM met geneste virtualisasie-ondersteuning. In die hoe-om-gids demonstreer ek hoe om dit op 'n Linux VM te aktiveer. As jy egter 'n macOS-gebruiker is en Selenoid plaaslik wil ontplooi, sal dit nie moontlik wees om Android-toetse uit te voer nie. Maar jy kan altyd 'n Linux VM plaaslik laat loop met 'geneste virtualisasie' opgestel en Selenoid binne ontplooi.
Illustrasie van die huidige stand van infrastruktuur
In die konteks van hierdie artikel sal ons 2 instrumente byvoeg om die infrastruktuur te illustreer. Dit is Selenium-rooster vir webtoetse en Selenoid vir Android-toetse. In die GitHub-tutoriaal sal ek jou ook wys hoe om Selenoid te gebruik om webtoetse uit te voer.
Skakels om te verken
Soortgelyke gereedskap
- Daar is ander containeriseringsinstrumente, maar Docker is die gewildste. As jy iets anders wil probeer, hou in gedagte dat die gereedskap wat ons gedek het om Selenium-toetse parallel te laat loop, nie uit die boks sal werk nie.
- Soos reeds gesê, is daar baie wysigings van Selenium-rooster, byvoorbeeld,.
4.CI/CD
Kort beskrywing van die tegnologie
Die praktyk van deurlopende integrasie is baie gewild in ontwikkeling en is op gelyke voet met weergawebeheerstelsels. Ten spyte hiervan voel ek dat daar verwarring in terminologie is. In hierdie paragraaf wil ek graag 3 wysigings van hierdie tegnologie uit my oogpunt beskryf. Op die internet sal jy baie artikels met verskillende interpretasies vind, en dit is absoluut normaal as jou mening verskil. Die belangrikste ding is dat jy op dieselfde bladsy is met jou kollegas.
Dus, daar is 3 terme: CI - Deurlopende integrasie, CD - Deurlopende aflewering en weer CD - Deurlopende Ontplooiing. (Hieronder sal ek hierdie terme in Engels gebruik). Elke wysiging voeg verskeie bykomende stappe by jou ontwikkelingspyplyn. Maar die woord deurlopende (deurlopend) is die belangrikste ding. In hierdie konteks bedoel ons iets wat van begin tot einde gebeur, sonder onderbreking of handmatige ingryping. Kom ons kyk na CI & CD en CD in hierdie konteks.
- Deurlopende integrasie dit is die eerste stap van evolusie. Nadat ons nuwe kode by die bediener ingedien het, verwag ons om vinnige terugvoer te ontvang dat ons veranderinge in orde is. Tipies sluit CI die loop van statiese kode-analise-nutsgoed en eenheid/interne API-toetse in. Dit stel ons in staat om inligting oor ons kode binne 'n paar sekondes/minute te bekom.
- deurlopende aflewering is 'n meer gevorderde stap waar ons integrasie-/UI-toetse uitvoer. Op hierdie stadium kry ons egter nie so vinnig resultate soos met CI nie. Eerstens neem hierdie tipe toetse langer om te voltooi. Tweedens, voor die bekendstelling, moet ons ons veranderinge aan die toets-/opvoeromgewing ontplooi. Verder, as ons praat oor mobiele ontwikkeling, dan blyk 'n bykomende stap om 'n bou van ons toepassing te skep.
- Deurlopende ontplooiing aanvaar dat ons outomaties ons veranderinge aan produksie vrystel as alle aanvaardingstoetse in die vorige stadiums geslaag is. Daarbenewens kan u na die vrystellingstadium verskeie stadiums opstel, soos om rooktoetse op produksie te laat uitvoer en metrieke van belang in te samel. Deurlopende ontplooiing is slegs moontlik met goeie dekking deur outomatiese toetse. As enige manuele intervensies vereis word, insluitend toetsing, dan is dit nie meer nie Deurlopende (deurlopend). Dan kan ons sê dat ons pyplyn slegs voldoen aan die praktyk van Deurlopende aflewering.
Waarde vir outomatiseringsinfrastruktuur
In hierdie afdeling moet ek dit duidelik maak dat wanneer ons praat oor eind-tot-einde UI-toetse, dit beteken dat ons ons veranderinge en gepaardgaande dienste moet ontplooi om omgewings te toets. Deurlopende integrasie - die proses is nie van toepassing vir hierdie taak nie en ons moet sorg vir die implementering van ten minste Deurlopende Afleweringspraktyke. Deurlopende ontplooiing maak ook sin in die konteks van UI-toetse as ons dit in produksie gaan laat loop.
En voordat ons na die illustrasie van die argitektuurverandering kyk, wil ek 'n paar woorde oor GitLab CI sê. Anders as ander CI/CD-instrumente, bied GitLab 'n afgeleë bewaarplek en baie ander bykomende funksies. Dus, GitLab is meer as CI. Dit sluit bronkodebestuur, ratse bestuur, CI/CD-pyplyne, aantekengereedskap en statistiekversameling uit die boks in. Die GitLab-argitektuur bestaan uit Gitlab CI/CD en GitLab Runner. Hier is 'n kort beskrywing van die amptelike webwerf:
Gitlab CI/CD is 'n webtoepassing met 'n API wat sy toestand in 'n databasis stoor, projekte/geboue bestuur en 'n gebruikerskoppelvlak verskaf. GitLab Runner is 'n toepassing wat bouwerk verwerk. Dit kan afsonderlik ontplooi word en werk met GitLab CI/CD deur 'n API. Vir toetse wat loop, benodig jy beide Gitlab-instansie en Runner.
Illustrasie van die huidige stand van infrastruktuur
Skakels om te verken
Soortgelyke gereedskap
- En baie ander
5. Wolkplatforms
Kort beskrywing van die tegnologie
In hierdie afdeling sal ons praat oor 'n gewilde neiging genaamd 'openbare wolke'. Ten spyte van die enorme voordele wat die virtualisasie- en houerstegnologieë wat hierbo beskryf word bied, het ons steeds rekenaarhulpbronne nodig. Maatskappye koop duur bedieners of huur datasentrums, maar in hierdie geval is dit nodig om berekeninge (soms onrealisties) te maak van hoeveel hulpbronne ons gaan benodig, of ons dit 24/7 gaan gebruik en vir watter doeleindes. Produksie vereis byvoorbeeld 'n bediener wat XNUMX/XNUMX werk, maar het ons soortgelyke hulpbronne nodig om buite werksure te toets? Dit hang ook af van die tipe toets wat uitgevoer word. 'n Voorbeeld is las-/strestoetse wat ons beplan om gedurende nie-werksure uit te voer om die volgende dag resultate te kry. Maar XNUMX/XNUMX-bedienerbeskikbaarheid is beslis nie nodig vir end-tot-end outomatiese toetse nie en veral nie vir handmatige toetsomgewings nie. Vir sulke situasies sal dit goed wees om soveel hulpbronne as wat nodig is op aanvraag te bekom, dit te gebruik en op te hou betaal wanneer dit nie meer nodig is nie. Boonop sal dit wonderlik wees om dit onmiddellik te ontvang deur 'n paar muisklikke te maak of 'n paar skrifte uit te voer. Dit is waarvoor publieke wolke gebruik word. Kom ons kyk na die definisie:
“Die publieke wolk word gedefinieer as rekenaardienste wat deur derdeparty-verskaffers oor die openbare internet aangebied word, wat dit beskikbaar stel aan enigiemand wat dit wil gebruik of koop. Hulle kan gratis wees of op aanvraag verkoop word, wat kliënte toelaat om slegs per gebruik te betaal vir die SVE-siklusse, berging of bandwydte wat hulle verbruik."
Daar is 'n mening dat openbare wolke duur is. Maar hul sleutelgedagte is om maatskappykoste te verminder. Soos vroeër genoem, laat publieke wolke jou toe om hulpbronne op aanvraag te kry en net te betaal vir die tyd wat jy dit gebruik. Ook vergeet ons soms dat werknemers salarisse ontvang, en spesialiste is ook 'n duur hulpbron. Daar moet in ag geneem word dat openbare wolke infrastruktuurondersteuning baie makliker maak, wat ingenieurs in staat stel om op belangriker take te fokus.
Waarde vir outomatiseringsinfrastruktuur
Watter spesifieke hulpbronne het ons nodig vir end-tot-end UI-toetse? Basies is dit virtuele masjiene of groepe (ons sal in die volgende afdeling oor Kubernetes praat) om blaaiers en emulators te laat loop. Hoe meer blaaiers en emulators ons gelyktydig wil laat loop, hoe meer SVE en geheue word benodig en hoe meer geld moet ons daarvoor betaal. Dus, publieke wolke in die konteks van toetsoutomatisering stel ons in staat om 'n groot aantal (100, 200, 1000 ...) blaaiers/emulators op aanvraag te laat loop, toetsresultate so vinnig as moontlik te kry en op te hou om vir sulke ongelooflik hulpbron-intensiewe te betaal. krag.
Die gewildste wolkverskaffers is Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Die hoe-om-gids verskaf voorbeelde van hoe om GCP te gebruik, maar oor die algemeen maak dit nie saak wat jy vir outomatiseringstake gebruik nie. Hulle bied almal ongeveer dieselfde funksionaliteit. Tipies, om 'n verskaffer te kies, fokus bestuur op die maatskappy se algehele infrastruktuur en besigheidsvereistes, wat buite die bestek van hierdie artikel is. Vir outomatiseringsingenieurs sal dit interessanter wees om die gebruik van wolkverskaffers te vergelyk met die gebruik van wolkplatforms spesifiek vir toetsdoeleindes, soos Sauce Labs, BrowserStack, BitBar, ensovoorts. So kom ons doen dit ook! Na my mening is Sauce Labs die bekendste wolktoetsplaas, en daarom het ek dit vir vergelyking gebruik.
GCP vs Sous Labs vir outomatiseringsdoeleindes:
Kom ons stel ons voor dat ons 8 webtoetse en 8 Android-toetse gelyktydig moet uitvoer. Hiervoor sal ons GCP gebruik en 2 virtuele masjiene met Selenoid laat loop. Op die eerste een sal ons 8 houers met blaaiers verhoog. Op die tweede is daar 8 houers met emulators. Kom ons kyk na die pryse:
Om een houer met Chrome te laat loop, benodig ons n1-standaard-1 voertuig. In die geval van Android sal dit wees n1-standaard-4 vir een emulator. Trouens, 'n meer buigsame en goedkoper manier is om spesifieke gebruikerwaardes vir SVE/Geheue in te stel, maar op die oomblik is dit nie belangrik vir vergelyking met Sauce Labs nie.
En hier is die tariewe vir die gebruik van Sauce Labs:
Ek glo jy het reeds die verskil opgemerk, maar ek sal steeds 'n tabel verskaf met berekeninge vir ons taak:
Vereiste hulpbronne
Maandeliks
Werksure(8:8 - XNUMX:XNUMX)
Werksure+ Verwyderbaar
GCP vir web
n1-standaard-1 x 8 = n1-standaard-8
$194.18
23 dae * 12h * 0.38 = $104.88
23 dae * 12h * 0.08 = $22.08
Sous Labs vir Web
Virtuele Cloud8 parallelle toetse
$1.559
-
-
GCP vir Android
n1-standaard-4 x 8: n1-standaard-16
$776.72
23 dae * 12h * 1.52 = $419.52
23 dae * 12h * 0.32 = $88.32
Sous Labs vir Android
Real Device Cloud 8 parallelle toetse
$1.999
-
-
Soos u kan sien, is die verskil in koste groot, veral as u slegs toetse gedurende 'n twaalf uur lange werkperiode uitvoer. Maar jy kan koste selfs verder besnoei as jy uittrekbare masjiene gebruik. Wat is dit?
'n Verwyderbare VM is 'n instansie wat jy teen 'n veel laer prys as normale instansies kan skep en laat loop. Compute Engine kan egter hierdie gevalle beëindig (voorkom) as dit toegang tot daardie hulpbronne vir ander take vereis. Verwyderbare gevalle is oortollige Compute Engine-kapasiteit, dus hul beskikbaarheid wissel met gebruik.
As jou programme foutverdraagsaam is en moontlike instansievoorkeure kan weerstaan, kan uitwisbare instansies jou Compute Engine-koste aansienlik verminder. Byvoorbeeld, bondelverwerkingstake kan op wegneembare gevalle loop. As sommige van daardie gevalle tydens verwerking beëindig word, vertraag die werk, maar stop nie heeltemal nie. Verwyderbare gevalle voltooi u bondelverwerkingstake sonder om bykomende werklading op u bestaande gevalle te plaas en sonder dat u die volle prys moet betaal vir bykomende normale gevalle.
En dit is steeds nie verby nie! In werklikheid is ek seker niemand hardloop toetse vir 12 uur sonder 'n pouse nie. En indien wel, dan kan u virtuele masjiene outomaties begin en stop wanneer dit nie nodig is nie. Werklike gebruikstyd kan tot 6 uur per dag verminder word. Dan sal die betaling in die konteks van ons taak verminder tot $11 per maand vir 8 blaaiers. Is dit nie wonderlik nie? Maar met uittrekbare masjiene moet ons versigtig en voorbereid wees vir onderbrekings en onstabiliteit, alhoewel hierdie situasies in sagteware voorsien en hanteer kan word. Dit is die moeite werd!
Maar ek sê geensins 'moet nooit wolktoetsplase gebruik nie'. Hulle het 'n aantal voordele. Eerstens is dit nie net 'n virtuele masjien nie, maar 'n volwaardige toetsoutomatiseringsoplossing met 'n stel funksies uit die boks: afstandtoegang, logboeke, skermkiekies, video-opname, verskeie blaaiers en fisiese mobiele toestelle. In baie situasies kan dit 'n noodsaaklike sjiek alternatief wees. Toetsplatforms is veral nuttig vir IOS-outomatisering, wanneer publieke wolke slegs Linux/Windows-stelsels kan bied. Maar ons sal praat oor iOS in die volgende artikels. Ek beveel aan om altyd na die situasie te kyk en by die take te begin: in sommige gevalle is dit goedkoper en doeltreffender om openbare wolke te gebruik, en in ander is die toetsplatforms beslis die geld werd wat spandeer word.
Illustrasie van die huidige stand van infrastruktuur
Skakels om te verken
Soortgelyke gereedskap:
6. Orkestrasie
Kort beskrywing van die tegnologie
Ek het goeie nuus – ons is amper aan die einde van die artikel! Op die oomblik bestaan ons outomatiseringsinfrastruktuur uit web- en Android-toetse, wat ons parallel deur GitLab CI hardloop, met Docker-geaktiveerde gereedskap: Selenium-rooster en Selenoid. Boonop gebruik ons virtuele masjiene wat via GCP geskep is om houers met blaaiers en emulators te huisves. Om koste te verminder, begin ons hierdie virtuele masjiene slegs op aanvraag en stop dit wanneer toetsing nie uitgevoer word nie. Is daar enigiets anders wat ons infrastruktuur kan verbeter? Die antwoord is ja! Ontmoet Kubernetes (K8's)!
Kom ons kyk eers hoe die woorde orkestrasie, groepering en Kubernetes met mekaar verband hou. Op 'n hoë vlak is orkestrasie die stelsel wat toepassings ontplooi en bestuur. Vir toetsoutomatisering is sulke houertoepassings Selenium-rooster en Selenoid. Docker en K8's vul mekaar aan. Die eerste word gebruik vir toepassing-ontplooiing, die tweede vir orkestrasie. Op sy beurt is K8s 'n cluster. Die taak van die kluster is om VM's as nodes te gebruik, wat jou toelaat om verskeie funksionaliteit, programme en dienste binne een bediener (cluster) te installeer. As enige van die nodusse misluk, sal ander nodusse optel, wat ononderbroke werking van ons toepassing verseker. Daarbenewens het K8s belangrike funksionaliteit wat verband hou met skaal, waardeur ons outomaties die optimale hoeveelheid hulpbronne verkry op grond van die vrag en stel limiete.
Om die waarheid te sê, die handmatige implementering van Kubernetes van nuuts af is glad nie 'n onbenullige taak nie. Ek sal 'n skakel na die bekende hoe-om-gids "Kubernetes The Hard Way" los en as jy belangstel, kan jy dit oefen. Maar gelukkig is daar alternatiewe metodes en gereedskap. Die maklikste manier is om Google Kubernetes Engine (GKE) in GCP te gebruik, wat jou in staat sal stel om 'n klaargemaakte groepering in 'n paar klikke te kry. Ek beveel aan om hierdie benadering te gebruik om te begin leer, aangesien dit jou sal toelaat om te fokus om te leer hoe om die K8's vir jou take te gebruik in plaas daarvan om te leer hoe die interne komponente met mekaar geïntegreer moet word.
Waarde vir outomatiseringsinfrastruktuur
Kom ons kyk na 'n paar belangrike kenmerke wat die K8's bied:
- toepassing ontplooiing: die gebruik van 'n multi-nodes cluster in plaas van VM's;
- dinamiese skaal: verminder die koste van hulpbronne wat slegs op aanvraag gebruik word;
- selfgenesing: outomatiese herwinning van peule (as gevolg waarvan houers ook herstel word);
- ontplooiing van opdaterings en terugdraai van veranderinge sonder stilstand: opdatering van gereedskap, blaaiers en emulators onderbreek nie die werk van huidige gebruikers nie
Maar die K8's is steeds nie 'n silwer koeël nie. Om al die voordele en beperkings in die konteks van die gereedskap wat ons oorweeg (Selenium-rooster, Selenoid) te verstaan, sal ons die struktuur van K8's kortliks bespreek. Kluster bevat twee tipes nodusse: Meesternodes en Werkersnodes. Meester nodes is verantwoordelik vir bestuur, ontplooiing en skedulering besluite. Werkersnodusse is waar toepassings geloods word. Nodusse bevat ook 'n houer-looptyd-omgewing. In ons geval is dit Docker, wat verantwoordelik is vir houerverwante bedrywighede. Maar daar is ook alternatiewe oplossings, byvoorbeeld. Dit is belangrik om te verstaan dat skaalvorming of selfgenesing nie direk op houers van toepassing is nie. Dit word geïmplementeer deur die aantal peule by te voeg/te verminder, wat weer houers bevat (gewoonlik een houer per peul, maar afhangend van die taak kan daar meer wees). Die hoëvlakhiërargie bestaan uit werkernodusse, binne-in waarin daar peule is, binne-in waarvan houers opgelig is.
Die skaalkenmerk is die sleutel en kan toegepas word op beide nodusse binne 'n cluster nodepoel en peule binne 'n nodus. Daar is 2 tipes skaal wat van toepassing is op beide nodusse en peule. Die eerste tipe is horisontaal - skaal vind plaas deur die aantal nodusse/peule te verhoog. Hierdie tipe is meer verkieslik. Die tweede tipe is dus vertikaal. Skaal word uitgevoer deur die grootte van nodusse/peule te vergroot, en nie hul aantal nie.
Kom ons kyk nou na ons gereedskap in die konteks van bogenoemde terme.
Selenium rooster
Soos vroeër genoem, is seleniumrooster 'n baie gewilde instrument, en dit is geen verrassing dat dit in 'n houer geplaas is nie. Daarom is dit geen verrassing dat Selenium-rooster in K8's ontplooi kan word nie. 'n Voorbeeld van hoe om dit te doen, kan gevind word in die amptelike K8s-bewaarplek. Soos gewoonlik heg ek skakels aan die einde van die afdeling. Daarbenewens wys die hoe-om-gids hoe om dit in Terraform te doen. Daar is ook instruksies oor hoe om die aantal peule wat blaaierhouers bevat, te skaal. Maar die outomatiese skaalfunksie in die konteks van K8's is steeds nie 'n heeltemal ooglopende taak nie. Toe ek begin studeer het, het ek geen praktiese leiding of aanbevelings gekry nie. Na verskeie studies en eksperimente met die ondersteuning van die DevOps-span, het ons die benadering gekies om houers te verhoog met die nodige blaaiers binne een peul, wat binne een werkernodus geleë is. Hierdie metode stel ons in staat om die strategie van horisontale skaal van nodusse toe te pas deur hul aantal te verhoog. Ek hoop dat dit in die toekoms sal verander en ons sal meer en meer beskrywings van beter benaderings en klaargemaakte oplossings sien, veral na die vrystelling van Selenium rooster 4 met 'n veranderde interne argitektuur.
Selenoïed:
Selenoïed-ontplooiing in K8's is tans die grootste teleurstelling. Hulle is nie versoenbaar nie. In teorie kan ons 'n Selenoid-houer in 'n peul grootmaak, maar wanneer Selenoid houers met blaaiers begin bekendstel, sal hulle steeds in dieselfde peul wees. Dit maak skaal onmoontlik en gevolglik sal die werk van Selenoid binne 'n groepie nie verskil van werk binne 'n virtuele masjien nie. Einde van die storie.
maan:
Met die kennis van hierdie bottelnek wanneer hulle met Selenoid gewerk het, het die ontwikkelaars 'n kragtiger instrument genaamd Moon vrygestel. Hierdie instrument is oorspronklik ontwerp om met Kubernetes te werk en gevolglik kan en moet die outoskaal-funksie gebruik word. Boonop sou ek sê dat dit op die oomblik is die enigste 'n instrument in die Selenium-wêreld, wat inheemse K8s-groepondersteuning uit die boks het (nie meer beskikbaar nie, sien volgende hulpmiddel ). Die sleutelkenmerke van Moon wat hierdie ondersteuning bied, is:
Heeltemal staatloos. Selenoid stoor inligting oor blaaiersessies wat tans loop in die geheue. As die proses om een of ander rede ineenstort - dan is alle lopende sessies verlore. Moon het daarenteen geen interne toestand nie en kan oor datasentrums herhaal word. Blaaiersessies bly lewendig selfs al gaan een of meer replikas af.
Maan is dus 'n goeie oplossing, maar daar is een probleem: dit is nie gratis nie. Die prys hang af van die aantal sessies. Jy kan net 0-4 sessies gratis hardloop, wat nie besonder nuttig is nie. Maar vanaf die vyfde sessie sal jy $5 vir elkeen moet betaal. Die situasie kan van maatskappy tot maatskappy verskil, maar in ons geval is dit sinloos om Moon te gebruik. Soos ek hierbo beskryf het, kan ons VM's met Selenium Grid op aanvraag laat loop of die aantal nodusse in die cluster verhoog. Vir ongeveer een pyplyn begin ons 500 blaaiers en stop alle hulpbronne nadat die toetse voltooi is. As ons Moon gebruik het, sou ons 'n bykomende 500 x 5 = $2500 per maand moes betaal, maak nie saak hoe gereeld ons toetse uitvoer nie. Weereens, ek sê nie moenie Moon gebruik nie. Vir jou take kan dit 'n onontbeerlike oplossing wees, byvoorbeeld as jy baie projekte/spanne in jou organisasie het en jy 'n groot gemeenskaplike groepering vir almal nodig het. Soos altyd laat ek 'n skakel aan die einde en beveel aan om al die nodige berekeninge in die konteks van jou taak te doen.
Callisto: (Aandag! Dit is nie in die oorspronklike artikel nie en is slegs in die Russiese vertaling vervat)
Soos ek gesê het, is Selenium 'n baie gewilde hulpmiddel, en die IT-veld ontwikkel baie vinnig. Terwyl ek aan die vertaling gewerk het, het 'n nuwe belowende hulpmiddel genaamd Callisto op die web verskyn (hallo Cypress en ander Selenium-moordenaars). Dit werk inheems met K8's en laat jou toe om Selenoid-houers in peule te laat loop, versprei oor nodes. Alles werk reg uit die boks, insluitend outoskaal. Fantasties, maar moet getoets word. Ek het reeds daarin geslaag om hierdie instrument te ontplooi en verskeie eksperimente uit te voer. Maar dit is te vroeg om gevolgtrekkings te maak, nadat ek resultate oor 'n lang afstand ontvang het, sal ek miskien 'n resensie in toekomstige artikels doen. Vir nou laat ek net skakels vir onafhanklike navorsing.
Illustrasie van die huidige stand van infrastruktuur
Skakels om te verken
Soortgelyke gereedskap
7. Infrastruktuur as Kode (IaC)
Kort beskrywing van die tegnologie
En nou kom ons by die laaste afdeling. Tipies is hierdie tegnologie en verwante take nie die verantwoordelikheid van outomatiseringsingenieurs nie. En daar is redes hiervoor. Eerstens, in baie organisasies is infrastruktuurkwessies onder die beheer van die DevOps-afdeling en die ontwikkelingspanne gee nie regtig om oor wat die pyplyn laat werk en hoe alles wat daarmee verband hou, ondersteun moet word nie. Tweedens, laat ons eerlik wees, die praktyk van Infrastruktuur as Kode (IaC) word steeds nie in baie maatskappye aanvaar nie. Maar dit het beslis 'n gewilde neiging geword en dit is belangrik om te probeer betrokke wees by die prosesse, benaderings en hulpmiddels wat daarmee gepaard gaan. Of bly ten minste op hoogte.
Kom ons begin met die motivering vir die gebruik van hierdie benadering. Ons het reeds bespreek dat om toetse in GitlabCI uit te voer, ons ten minste die hulpbronne sal benodig om Gitlab Runner te laat loop. En om houers met blaaiers/emulators te laat loop, moet ons 'n VM of groepering bespreek. Benewens die toets van hulpbronne, benodig ons 'n aansienlike hoeveelheid kapasiteit om ontwikkeling, opstel, produksie-omgewings te ondersteun, wat ook databasisse, outomatiese skedules, netwerkkonfigurasies, lasbalanseerders, gebruikersregte, ensovoorts insluit. Die sleutelkwessie is die moeite wat nodig is om dit alles te ondersteun. Daar is verskeie maniere waarop ons veranderinge kan maak en opdaterings kan ontplooi. Byvoorbeeld, in die konteks van GCP, kan ons die UI-konsole in die blaaier gebruik en alle aksies uitvoer deur knoppies te klik. 'n Alternatief sou wees om API-oproepe te gebruik om met wolkentiteite te kommunikeer, of die gcloud-opdragreël-nutsding te gebruik om die verlangde manipulasies uit te voer. Maar met 'n baie groot aantal verskillende entiteite en infrastruktuurelemente, word dit moeilik of selfs onmoontlik om alle bewerkings met die hand uit te voer. Boonop is al hierdie handhandelinge onbeheerbaar. Ons kan dit nie vir hersiening indien voor uitvoering, 'n weergawebeheerstelsel gebruik en die veranderinge wat tot die voorval gelei het, vinnig terugrol nie. Om sulke probleme op te los, het ingenieurs outomatiese bash/shell-skrifte geskep en geskep, wat nie veel beter is as vorige metodes nie, aangesien dit nie so maklik is om vinnig te lees, te verstaan, in stand te hou en in 'n prosedurele styl te verander nie.
In hierdie artikel en hoe-om-gids, gebruik ek 2 gereedskap wat verband hou met IaC praktyk. Dit is Terraform en Ansible. Sommige mense glo dat dit nie sin maak om hulle op dieselfde tyd te gebruik nie, aangesien hul funksionaliteit soortgelyk is en hulle uitruilbaar is. Maar die feit is dat hulle aanvanklik heeltemal verskillende take gegee word. En die feit dat hierdie instrumente mekaar moet aanvul, is bevestig by 'n gesamentlike aanbieding deur ontwikkelaars wat HashiCorp en RedHat verteenwoordig. Die konseptuele verskil is dat Terraform 'n voorsieningsinstrument is om die bedieners self te bestuur. Terwyl Ansible 'n konfigurasiebestuurhulpmiddel is wie se taak is om sagteware op hierdie bedieners te installeer, op te stel en te bestuur.
Nog 'n belangrike onderskeidende kenmerk van hierdie instrumente is die koderingstyl. Anders as bash en Ansible, gebruik Terraform 'n verklarende styl gebaseer op 'n beskrywing van die gewenste eindtoestand wat as gevolg van uitvoering bereik moet word. Byvoorbeeld, as ons 10 VM's gaan skep en die veranderinge deur Terraform gaan toepas, sal ons 10 VM's kry. As ons die skrip weer laat loop, sal niks gebeur nie aangesien ons reeds 10 VM's het, en Terraform weet hiervan omdat dit die huidige toestand van die infrastruktuur in 'n toestandlêer stoor. Maar Ansible gebruik 'n prosedurele benadering en as jy dit vra om 10 VM's te skep, sal ons met die eerste bekendstelling 10 VM's kry, soortgelyk aan Terraform. Maar nadat ons herbegin het, sal ons reeds 20 VM's hê. Dit is die belangrike verskil. In prosedurele styl stoor ons nie die huidige toestand nie en beskryf bloot 'n reeks stappe wat uitgevoer moet word. Natuurlik kan ons verskeie situasies hanteer, verskeie kontroles vir die bestaan van hulpbronne en die huidige toestand byvoeg, maar dit is geen sin om ons tyd te mors en moeite te doen om hierdie logika te beheer nie. Boonop verhoog dit die risiko om foute te maak.
As ons al die bogenoemde opsom, kan ons tot die gevolgtrekking kom dat Terraform en verklarende notasie 'n meer geskikte hulpmiddel is om bedieners te voorsien. Maar dit is beter om die werk van konfigurasiebestuur aan Ansible te delegeer. Met dit uit die pad, kom ons kyk na gebruiksgevalle in die konteks van outomatisering.
Waarde vir outomatiseringsinfrastruktuur
Die enigste belangrike ding om hier te verstaan, is dat die toetsoutomatiseringsinfrastruktuur as deel van die hele maatskappy-infrastruktuur beskou moet word. Dit beteken dat alle IaC-praktyke wêreldwyd toegepas moet word op die hulpbronne van die hele organisasie. Wie hiervoor verantwoordelik is, hang af van jou prosesse. Die DevOps-span is meer ervare in hierdie kwessies, hulle sien die geheelbeeld van wat aan die gebeur is. QA-ingenieurs is egter meer betrokke by die proses van bou-outomatisering en die struktuur van die pyplyn, wat hulle in staat stel om al die vereiste veranderinge en geleenthede vir verbetering beter te sien. Die beste opsie is om saam te werk, kennis en idees uit te ruil om die verwagte resultaat te bereik.
Hier is 'n paar voorbeelde van die gebruik van Terraform en Ansible in die konteks van toetsoutomatisering en die gereedskap wat ons voorheen bespreek het:
1. Beskryf die nodige kenmerke en parameters van VM'e en clusters met behulp van Terraform.
2. Gebruik Ansible, installeer die gereedskap wat nodig is om te toets: docker, Selenoid, Selenium Grid en laai die vereiste weergawes van blaaiers/emulators af.
3. Gebruik Terraform en beskryf die kenmerke van die VM waarin GitLab Runner geloods sal word.
4. Installeer GitLab Runner en die nodige gepaardgaande gereedskap deur Ansible te gebruik, stel instellings en konfigurasies in.
Illustrasie van die huidige stand van infrastruktuur
Skakels om te verken:
Soortgelyke gereedskap
Kom ons som dit op!
stap
Tegnologie
Gereedskap
Waarde vir outomatiseringsinfrastruktuur
1
Plaaslike hardloop
Node.js, Selenium, Appium
- Die gewildste gereedskap vir web en selfoon
- Ondersteun baie tale en platforms (insluitend Node.js)
2
Weergawebeheerstelsels
gaan
- Soortgelyke voordele met ontwikkelingskode
3
Houerisering
Docker, Selenium rooster, Selenoid (Web, Android)
- Doen toetse parallel
- Geïsoleerde omgewings
- Eenvoudige, buigsame weergawe-opgraderings
- Stop ongebruikte hulpbronne dinamies
- Maklik om op te stel
4
CI/CD
Gitlab CI
- Toets deel van die pyplyn
- Vinnige terugvoer
- Sigbaarheid vir die hele maatskappy/span
5
Wolkplatforms
Google Wolkplatform
- Hulpbronne op aanvraag (ons betaal slegs wanneer nodig)
- Maklik om te bestuur en op te dateer
- Sigbaarheid en beheer van alle hulpbronne
6
orkestrasie
Kubernetes
In die konteks van houers met blaaiers/emulators in peule:
- Skaal/outomatiese skaal
- Selfgenesing
- Opdaterings en terugskrywings sonder onderbreking
7
Infrastruktuur as 'n kode (IAC)
Terraform, Ansible
- Soortgelyke voordele met ontwikkelingsinfrastruktuur
- Al die voordele van kodeweergawe
- Maklik om veranderinge aan te bring en in stand te hou
- Ten volle outomaties
Breinkaartdiagramme: evolusie van infrastruktuur
stap 1: Plaaslik
stap 2: VCS
stap 3: Containerization
stap 4: CI/CD
stap 5: Wolkplatforms
stap 6: Orkestrasie
stap 7: IAC
Wat is volgende?
So, dit is die einde van die artikel. Maar ten slotte wil ek graag 'n paar ooreenkomste met jou aangaan.
Van jou kant af
Soos ek aan die begin gesê het, wil ek graag hê dat die artikel van praktiese nut moet wees en jou help om die kennis wat opgedoen is in werklike werk toe te pas. Ek voeg weer by.
Maar selfs daarna, moenie stop nie, oefen, bestudeer relevante skakels en boeke, vind uit hoe dit in jou maatskappy werk, vind plekke wat verbeter kan word en neem daaraan deel. Sterkte!
Van my kant af
Uit die titel kan jy sien dat dit slegs die eerste deel was. Ten spyte van die feit dat dit redelik groot blyk te wees, word belangrike onderwerpe steeds nie hier gedek nie. In die tweede deel beplan ek om te kyk na outomatiseringsinfrastruktuur in die konteks van IOS. As gevolg van Apple se beperkings om iOS-simulators slegs op macOS-stelsels te laat loop, is ons reeks oplossings vernou. Ons kan byvoorbeeld nie Docker gebruik om die simulator of openbare wolke te laat loop om virtuele masjiene te laat loop nie. Maar dit beteken nie dat daar geen ander alternatiewe is nie. Ek sal probeer om jou op hoogte te hou met gevorderde oplossings en moderne gereedskap!
Ek het ook nie nogal groot onderwerpe genoem wat met monitering verband hou nie. In Deel 3 gaan ek kyk na die gewildste infrastruktuurmoniteringsinstrumente en watter data en maatstawwe om te oorweeg.
En uiteindelik. In die toekoms beplan ek om 'n videokursus oor die bou van toetsinfrastruktuur en gewilde gereedskap vry te stel. Tans is daar heelwat kursusse en lesings oor DevOps op die internet, maar alle materiaal word aangebied in die konteks van ontwikkeling, nie toetsoutomatisering nie. Oor hierdie kwessie het ek regtig terugvoer nodig of so 'n kursus interessant en waardevol sal wees vir die gemeenskap van toetsers en outomatiseringsingenieurs. Byvoorbaat dankie!
Bron: will.com