1. osa: Veeb/Android
Märkus: see artikkel on originaalartikli tõlge vene keelde Kõik illustratsioonid, lingid, tsitaadid ja terminid säilitatakse siiski originaalkeeles, et vältida vene keelde tõlkimisel tähenduse moonutusi. Soovin teile head õppimist!
Praegu on DevOpsi eriala IT-tööstuses üks nõutumaid. Kui avate populaarsed tööotsingu saidid ja filtreerite palga järgi, näete, et DevOpsiga seotud töökohad on loendi tipus. Siiski on oluline mõista, et see viitab peamiselt kõrgemale ametikohale, mis tähendab, et kandidaadil on kõrgetasemelised oskused, teadmised tehnoloogiast ja tööriistadest. Sellega kaasneb ka suur vastutus, mis on seotud tootmise katkematu toimimisega. Kuid me hakkasime unustama, mis DevOps on. Algselt ei olnud see mingi konkreetne isik või osakond. Kui otsida selle mõiste definitsioone, siis leiame palju ilusaid ja õigeid nimisõnu, nagu metoodika, praktikad, kultuurifilosoofia, mõistete rühm jne.
Minu erialaks on testimise automatiseerimise insener (QA automation engineer), kuid usun, et seda ei tohiks seostada ainult autotestide kirjutamise või testraamistiku arhitektuuri arendamisega. Aastal 2020 on hädavajalikud ka teadmised automatiseerimise infrastruktuurist. See võimaldab teil automatiseerimisprotsessi ise korraldada alates testide läbiviimisest kuni kõikidele huvigruppidele vastavalt oma eesmärkidele tulemuste pakkumiseni. Selle tulemusena on DevOpsi oskused töö tegemiseks hädavajalikud. Ja see kõik on hea, kuid kahjuks on probleem (spoiler: see artikkel püüab seda probleemi lihtsustada). Asi on selles, et DevOps on raske. Ja see on ilmselge, sest ettevõtted ei maksa palju selle eest, mida on lihtne teha... DevOpsi maailmas on suur hulk tööriistu, termineid ja tavasid, mida tuleb omandada. See on eriti raske karjääri alguses ja sõltub kogunenud tehnilisest kogemusest.
Allikas:
Tõenäoliselt lõpetame siin sissejuhatava osaga ja keskendume selle artikli eesmärgile.
Millest see artikkel räägib?
Selles artiklis jagan oma kogemusi testimise automatiseerimise infrastruktuuri loomisel. Internetis on palju infoallikaid erinevate tööriistade ja nende kasutamise kohta, kuid vaatleksin neid puhtalt automatiseerimise kontekstis. Usun, et paljud automaatikainsenerid on tuttavad olukorraga, kui keegi peale sinu ei tee väljatöötatud teste ega hooli nende hooldamisest. Selle tulemusena muutuvad testid aegunud ja nende värskendamiseks peate kulutama aega. Jällegi, karjääri alguses võib see olla üsna keeruline ülesanne: targalt otsustada, millised tööriistad peaksid aitama antud probleemi kõrvaldada, kuidas neid valida, konfigureerida ja hooldada. Mõned testijad pöörduvad abi saamiseks DevOpsi (inimesed) poole ja olgem ausad, see lähenemine töötab. Paljudel juhtudel võib see olla ainus võimalus, kuna meil pole kõigi sõltuvuste kohta ülevaadet. Aga nagu me teame, on DevOps väga hõivatud tüübid, sest nad peavad olenevalt organisatsioonist/meeskonnast mõtlema kogu ettevõtte infrastruktuuri, juurutamise, jälgimise, mikroteenuste ja muude sarnaste ülesannete peale. Nagu tavaliselt, ei ole automatiseerimine prioriteet. Sellisel juhul peame püüdma algusest lõpuni teha kõik endast oleneva. See vähendab sõltuvusi, kiirendab töövoogu, parandab meie oskusi ja võimaldab näha toimuvast suuremat pilti.
Artiklis tutvustatakse kõige populaarsemaid ja populaarsemaid tööriistu ning näidatakse, kuidas neid samm-sammult automatiseerimistaristu ülesehitamiseks kasutada. Iga grupp on esindatud tööriistadega, mis on läbi isikliku kogemuse testitud. Kuid see ei tähenda, et peate kasutama sama asja. Tööriistad ise pole olulised, need ilmuvad ja vananevad. Meie inseneriülesanne on mõista põhiprintsiipe: miks me seda tööriistade rühma vajame ja milliseid tööprobleeme saame nende abiga lahendada. Seetõttu jätan iga jaotise lõppu lingid sarnastele tööriistadele, mida võidakse teie organisatsioonis kasutada.
Mida selles artiklis ei ole
Kordan veel kord, et artikkel ei puuduta konkreetseid tööriistu, seega ei lisata dokumentatsiooni koodi ega konkreetsete käskude kirjeldusi. Kuid iga jaotise lõppu jätan lingid üksikasjalikuks uurimiseks.
Seda tehakse, kuna:
- seda materjali on väga lihtne leida erinevatest allikatest (dokumentatsioon, raamatud, videokursused);
- kui hakkame süvenema, peame sellest artiklist kirjutama 10, 20, 30 osa (samal ajal kui plaanid on 2-3);
- Ma lihtsalt ei taha teie aega raisata, kuna võiksite samade eesmärkide saavutamiseks kasutada muid tööriistu.
Tava
Tahaksin väga, et see materjal oleks kasulik igale lugejale, mitte ei jääks lihtsalt loetuks ja unustusse. Igas uuringus on praktika väga oluline komponent. Selleks olen valmistunud. Samuti ootab teid kodutöö, et veenduda, et te ei kopeeri arutult täidetavate käskude ridu.
kava
Samm
Tehnoloogia
TÖÖRIISTAD
1
Kohalik töötamine (valmistage veebi / Androidi demotestid ja käivitage see kohapeal)
Node.js, seleen, Appium
2
Versioonikontrollisüsteemid
Git
3
Konteinerimine
Docker, Selenium Grid, Selenoid (veeb, Android)
4
CI/CD
Gitlab CI
5
Pilveplatvormid
Google Cloud Platform
6
Orkestreerimine
Kubernetes
7
Infrastruktuur kui kood (IaC)
Terraform, Ansible
Iga sektsiooni struktuur
Narratiivi selgena hoidmiseks kirjeldatakse iga jaotist järgmiselt:
- tehnoloogia lühikirjeldus,
- väärtus automatiseerimise infrastruktuuri jaoks,
- illustreerib infrastruktuuri hetkeseisu,
- lingid õppetööle,
- sarnased tööriistad.
1. Käivitage testid kohapeal
Tehnoloogia lühikirjeldus
See on vaid ettevalmistav samm demotestide kohapeal käitamiseks ja nende läbimise kontrollimiseks. Praktilises osas on kasutusel Node.js, kuid programmeerimiskeel ja platvorm pole samuti olulised ning kasutada saab neid, mis on kasutusel sinu ettevõttes.
Automatiseerimisvahenditena soovitan aga kasutada veebiplatvormidele vastavalt Selenium WebDriveri ja Androidi platvormile Appiumit, kuna järgmistes sammudes kasutame Dockeri pilte, mis on kohandatud just nende tööriistadega töötama. Veelgi enam, viidates töönõuetele, on need tööriistad turul kõige nõutumad.
Nagu olete ehk märganud, võtame arvesse ainult veebi- ja Androidi teste. Kahjuks on iOS-iga täiesti erinev lugu (aitäh Apple'ile). Kavatsen esitleda IOS-iga seotud lahendusi ja tavasid tulevastes osades.
Automatiseerimise infrastruktuuri väärtus
Infrastruktuuri vaatenurgast ei anna kohapeal töötamine mingit väärtust. Kontrollite ainult seda, et testid jooksevad kohalikus masinas kohalikes brauserites ja simulaatorites. Kuid igal juhul on see vajalik lähtepunkt.
Illustratsioon infrastruktuuri hetkeseisust
Lingid uurimiseks
Sarnased tööriistad
- mis tahes programmeerimiskeel, mis teile meeldib koos Seleeni/Appiumi testidega;
- mis tahes testid;
- ükskõik milline proovijooksja.
2. Versioonikontrollisüsteemid (Git)
Tehnoloogia lühikirjeldus
See ei jää kellelegi suureks ilmutuseks, kui ütlen, et versioonikontroll on nii meeskonnas kui ka individuaalselt äärmiselt oluline osa arendusest. Erinevate allikate põhjal võib kindlalt väita, et Git on kõige populaarsem esindaja. Versioonihaldussüsteem pakub palju eeliseid, nagu koodi jagamine, versioonide salvestamine, varasemate harude taastamine, projekti ajaloo jälgimine ja varukoopiad. Me ei käsitle iga punkti üksikasjalikult, kuna olen kindel, et olete sellega väga kursis ja kasutate seda oma igapäevatöös. Kui aga järsku mitte, siis soovitan selle artikli lugemise peatada ja see lünk esimesel võimalusel täita.
Automatiseerimise infrastruktuuri väärtus
Ja siin saate esitada mõistliku küsimuse: "Miks ta meile Gitist räägib? Kõik teavad seda ja kasutavad seda nii arenduskoodi kui ka automaatse testimise koodi jaoks. Teil on täiesti õigus, kuid selles artiklis räägime infrastruktuurist ja see jaotis toimib jaotise 7: "Infrastruktuur kui kood (IaC)" eelvaade. Meie jaoks tähendab see, et kogu infrastruktuur, sealhulgas testimine, on kirjeldatud koodi kujul, nii et saame sellele rakendada ka versioonisüsteeme ja saada sarnaseid eeliseid nagu arendus- ja automatiseerimiskoodi puhul.
Vaatleme IaC-d üksikasjalikumalt 7. sammus, kuid isegi nüüd saate alustada Giti kohaliku hoidla kasutamist, luues kohaliku hoidla. Suur pilt laieneb, kui lisame infrastruktuuri kaughoidla.
Illustratsioon infrastruktuuri hetkeseisust
Lingid uurimiseks
Sarnased tööriistad
3. Konteinerimine (Docker)
Tehnoloogia lühikirjeldus
Et näidata, kuidas konteineriseerimine on mängureegleid muutnud, läheme ajas paar aastakümmet tagasi. Sel ajal ostsid inimesed ja kasutasid rakenduste käitamiseks servermasinaid. Kuid enamikul juhtudel polnud vajaminevaid käivitusressursse ette teada. Selle tulemusena kulutasid ettevõtted raha kallite võimsate serverite ostmiseks, kuid osa sellest võimsusest jäi täielikult kasutamata.
Evolutsiooni järgmine etapp oli virtuaalsed masinad (VM), mis lahendasid raha raiskamise probleemi kasutamata ressurssidele. See tehnoloogia võimaldas käivitada rakendusi üksteisest sõltumatult samas serveris, eraldades täiesti isoleeritud ruumi. Kuid kahjuks on igal tehnoloogial oma puudused. VM-i käitamiseks on vaja täielikku operatsioonisüsteemi, mis kulutab CPU-d, RAM-i, salvestusruumi ja olenevalt OS-ist tuleb arvestada ka litsentsikuludega. Need tegurid mõjutavad laadimiskiirust ja raskendavad teisaldamist.
Ja nüüd jõuame konteineriseerimiseni. Taaskord lahendab see tehnoloogia eelmise probleemi, kuna konteinerid ei kasuta täis OS-i, mis vabastab suure hulga ressursse ning annab kiire ja paindliku lahenduse teisaldamiseks.
Muidugi pole konteineritehnoloogia midagi uut ja seda võeti esmakordselt kasutusele 70ndate lõpus. Neil päevil viidi läbi palju uuringuid, arendusi ja katseid. Kuid just Docker kohandas seda tehnoloogiat ja muutis selle massidele hõlpsasti kättesaadavaks. Tänapäeval, kui me räägime konteineritest, peame enamasti silmas Dockerit. Kui me räägime Dockeri konteineritest, peame silmas Linuxi konteinereid. Konteinerite käitamiseks saame kasutada Windowsi ja macOS-i süsteeme, kuid on oluline mõista, et sel juhul ilmub täiendav kiht. Näiteks Maci Docker käivitab vaikselt konteinereid kerges Linuxi VM-is. Naaseme selle teema juurde, kui arutame Androidi emulaatorite kasutamist konteinerites, seega on siin üks väga oluline nüanss, mida tuleb üksikasjalikumalt käsitleda.
Automatiseerimise infrastruktuuri väärtus
Saime teada, et konteineriseerimine ja Docker on lahedad. Vaatame seda automatiseerimise kontekstis, sest iga tööriist või tehnoloogia vajab probleemi lahendamist. Toome välja testimise automatiseerimise ilmsed probleemid kasutajaliidese testide kontekstis:
- tohutu hulk sõltuvusi seleeni ja eriti Appiumi installimisel;
- ühilduvusprobleemid brauserite, simulaatorite ja draiverite versioonide vahel;
- brauserite/simulaatorite jaoks eraldatud ruumi puudumine, mis on eriti oluline paralleelsel töötamisel;
- raske hallata ja hooldada, kui teil on vaja samaaegselt käivitada 10, 50, 100 või isegi 1000 brauserit.
Kuid kuna Selenium on kõige populaarsem automatiseerimistööriist ja Docker on kõige populaarsem konteinerite tööriist, ei tohiks olla üllatav, et keegi on püüdnud neid kombineerida, et luua võimas tööriist ülalmainitud probleemide lahendamiseks. Vaatleme selliseid lahendusi üksikasjalikumalt.
Seleenivõre dokis
See tööriist on Seleniumi maailmas kõige populaarsem mitme brauseri käitamiseks mitmel masinal ja nende haldamiseks kesksest jaoturist. Alustamiseks peate registreerima vähemalt 2 osa: jaotur ja sõlme(d). Jaotur on keskne sõlm, mis võtab vastu kõik testide päringud ja jagab need vastavatele sõlmedele. Iga sõlme jaoks saame konfigureerida konkreetse konfiguratsiooni, näiteks määrates soovitud brauseri ja selle versiooni. Ühilduvate brauseridraiverite eest peame siiski ise hoolitsema ja need soovitud sõlmedesse installima. Sel põhjusel ei kasutata Seleniumi võrku puhtal kujul, välja arvatud juhul, kui peame töötama brauseritega, mida ei saa Linux OS-i installida. Kõigil muudel juhtudel oleks märkimisväärselt paindlik ja õige lahendus kasutada Selenium grid Hubi ja sõlmede käitamiseks Dockeri pilte. See lähenemine lihtsustab oluliselt sõlmede haldamist, kuna saame valida vajaliku pildi juba installitud brauserite ja draiverite ühilduvate versioonidega.
Hoolimata negatiivsetest hinnangutest stabiilsuse kohta, eriti suure hulga sõlmede paralleelsel käitamisel, on Selenium grid endiselt kõige populaarsem tööriist seleenitestide paralleelseks käitamiseks. Oluline on märkida, et avatud lähtekoodiga versioonis ilmuvad pidevalt selle tööriista täiustused ja muudatused, mis võitlevad erinevate kitsaskohtadega.
Selenoid veebi jaoks
See tööriist on läbimurre seleeni maailmas, kuna see töötab kohe karbist välja võttes ja on teinud paljude automaatikainseneride elu palju lihtsamaks. Esiteks ei ole see järjekordne seleenivõrgu modifikatsioon. Selle asemel lõid arendajad Golangis Selenium Hubi täiesti uue versiooni, mis kombineerituna erinevatele brauseritele mõeldud kergete Dockeri piltidega andis tõuke testimise automatiseerimise arendamisele. Veelgi enam, Selenium Gridi puhul peame eelnevalt kindlaks määrama kõik vajalikud brauserid ja nende versioonid, mis ainult ühe brauseriga töötades pole probleem. Kuid kui tegemist on mitme toetatud brauseriga, on Selenoid lahendus number üks tänu selle funktsioonile "nõudmisel brauser". Meilt ei nõuta muud, kui eelnevalt brauserite abil alla laadida vajalikud pildid ja värskendada konfiguratsioonifaili, millega Selenoid suhtleb. Pärast seda, kui Selenoid saab testidelt päringu, käivitab see soovitud brauseriga soovitud konteineri automaatselt. Kui test on lõppenud, eemaldab Selenoid konteineri, vabastades seeläbi ressursse tulevaste päringute jaoks. See lähenemisviis kõrvaldab täielikult tuntud sõlmede lagunemise probleemi, mida me seleenivõrgus sageli kohtame.
Kuid paraku pole selenoid ikkagi hõbekuul. Meil on funktsioon „nõudmisel brauser”, kuid funktsioon „nõudmisel ressursid” pole endiselt saadaval. Selenoidi kasutamiseks peame selle juurutama füüsilises riistvaras või virtuaalses masinas, mis tähendab, et peame eelnevalt teadma, kui palju ressursse tuleb eraldada. Ma arvan, et see pole probleem väikeste projektide puhul, mis töötavad paralleelselt 10, 20 või isegi 30 brauseriga. Aga mis siis, kui meil on vaja 100, 500, 1000 või rohkem? Pole mõtet kogu aeg nii palju ressursse ülal pidada ja nende eest maksta. Selle artikli jaotistes 5 ja 6 käsitleme lahendusi, mis võimaldavad teil skaleerida, vähendades seeläbi oluliselt ettevõtte kulusid.
Selenoid Androidile
Pärast Selenoidi edu veebiautomaatika tööriistana soovisid inimesed midagi sarnast Androidi jaoks. Ja see juhtus - Selenoid ilmus Androidi toega. Kõrgetasemelise kasutaja seisukohast on tööpõhimõte sarnane veebiautomaatikaga. Ainus erinevus on see, et brauseri konteinerite asemel käitab Selenoid Androidi emulaatori konteinereid. Minu arvates on see hetkel kõige võimsam tasuta tööriist Androidi testide paralleelseks jooksmiseks.
Ma tõesti ei tahaks rääkida selle tööriista negatiivsetest külgedest, kuna see mulle väga meeldib. Kuid siiski on samad puudused, mis kehtivad veebiautomaatika puhul ja on seotud skaleerimisega. Lisaks sellele peame rääkima veel ühest piirangust, mis võib olla üllatusena, kui seadistame tööriista esimest korda. Androidi piltide käitamiseks vajame pesastatud virtualiseerimise toega füüsilist masinat või VM-i. Juhendis näitan, kuidas seda Linuxi virtuaalses masinas lubada. Kui aga olete macOS-i kasutaja ja soovite Selenoidi kohapeal juurutada, pole Androidi testide käivitamine võimalik. Kuid saate alati käitada Linuxi VM-i kohapeal, kui pesastatud virtualiseerimine on konfigureeritud, ja juurutada Selenoidi sees.
Illustratsioon infrastruktuuri hetkeseisust
Selle artikli kontekstis lisame infrastruktuuri illustreerimiseks 2 tööriista. Need on Selenium grid veebitestide jaoks ja Selenoid Androidi testide jaoks. GitHubi õpetuses näitan teile ka, kuidas kasutada Selenoidi veebitestide käitamiseks.
Lingid uurimiseks
Sarnased tööriistad
- On ka teisi konteineristamise tööriistu, kuid Docker on kõige populaarsem. Kui soovite midagi muud proovida, pidage meeles, et tööriistad, mida oleme seleeni testide paralleelseks läbiviimiseks käsitlenud, ei tööta karbist välja.
- Nagu juba öeldud, on seleenivõrgul palju modifikatsioone, näiteks.
4.CI/CD
Tehnoloogia lühikirjeldus
Pideva integreerimise praktika on arenduses üsna populaarne ja on samaväärne versioonikontrollisüsteemidega. Sellest hoolimata tunnen, et terminoloogias valitseb segadus. Selles lõigus tahaksin kirjeldada selle tehnoloogia kolme modifikatsiooni minu vaatenurgast. Internetist leiate palju erineva tõlgendusega artikleid ja on täiesti normaalne, kui teie arvamus erineb. Kõige tähtsam on see, et oled kolleegidega ühel lainel.
Seega on 3 terminit: CI – pidev integreerimine, CD – pidev kohaletoimetamine ja jällegi CD – pidev juurutamine. (Allpool kasutan neid termineid inglise keeles). Iga muudatus lisab teie arenduskonveierile mitu täiendavat sammu. Aga sõna pidev (pidev) on kõige tähtsam. Selles kontekstis peame silmas midagi, mis toimub algusest lõpuni ilma katkestusteta või käsitsi sekkumiseta. Vaatame selles kontekstis CI & CD-d ja CD-sid.
- Pidev integreerimine see on evolutsiooni esimene samm. Pärast uue koodi serverisse saatmist ootame kiiret tagasisidet, et meie muudatused on korras. Tavaliselt sisaldab CI staatilise koodianalüüsi tööriistade ja üksuse/sisemiste API testide käitamist. See võimaldab meil hankida teavet oma koodi kohta mõne sekundi/minuti jooksul.
- Pidev kohaletoimetamine on täiustatud samm, kus käitame integratsiooni/kasutajaliidese teste. Kuid praeguses etapis ei saavuta me tulemusi nii kiiresti kui CI puhul. Esiteks võtab seda tüüpi testide sooritamine kauem aega. Teiseks peame enne käivitamist oma muudatused juurutama testimis-/lavastamiskeskkonda. Veelgi enam, kui me räägime mobiiliarendusest, siis ilmub täiendav samm meie rakenduse järgu loomiseks.
- Pidev kasutuselevõtt eeldab, et vabastame oma muudatused automaatselt tootmises, kui eelmistes etappides on kõik vastuvõtutestid läbitud. Peale selle saate pärast väljalaskeetappi konfigureerida erinevaid etappe, näiteks käitada tootmisel suitsuteste ja koguda huvipakkuvaid mõõdikuid. Pidev juurutamine on võimalik ainult automaattestide hea katvuse korral. Kui on vaja käsitsi sekkumist, sealhulgas testimist, siis seda enam pole Pidev (pidev). Siis võime öelda, et meie torujuhe vastab ainult pideva kohaletoimetamise praktikale.
Automatiseerimise infrastruktuuri väärtus
Selles jaotises peaksin selgitama, et kui me räägime kasutajaliidese täielikest testidest, siis see tähendab, et peaksime juurutama oma muudatused ja seotud teenused testkeskkondade testimiseks. Pidev integreerimine – protsess ei ole selle ülesande jaoks rakendatav ja me peame hoolitsema vähemalt pideva edastamise tavade rakendamise eest. Pidev juurutamine on mõttekas ka kasutajaliidese testide kontekstis, kui kavatseme neid tootmises käitada.
Ja enne kui vaatame arhitektuurimuudatuse illustratsiooni, tahan öelda paar sõna GitLab CI kohta. Erinevalt teistest CI/CD tööriistadest pakub GitLab kaughoidlat ja palju muid lisafunktsioone. Seega on GitLab rohkem kui CI. See sisaldab lähtekoodi haldust, paindlikku haldust, CI/CD torujuhtmeid, logitööriistu ja mõõdikute kogumist. GitLabi arhitektuur koosneb Gitlab CI/CD-st ja GitLab Runnerist. Siin on lühike kirjeldus ametlikult veebisaidilt:
Gitlab CI/CD on API-ga veebirakendus, mis salvestab oma oleku andmebaasi, haldab projekte/ehinguid ja pakub kasutajaliidest. GitLab Runner on rakendus, mis töötleb järge. Seda saab juurutada eraldi ja see töötab API kaudu GitLabi CI/CD-ga. Testide käitamiseks vajate nii Gitlabi eksemplari kui ka Runnerit.
Illustratsioon infrastruktuuri hetkeseisust
Lingid uurimiseks
Sarnased tööriistad
- Ja paljud teised
5. Pilveplatvormid
Tehnoloogia lühikirjeldus
Selles jaotises räägime populaarsest trendist, mida nimetatakse avalikuks pilveks. Vaatamata tohututele eelistele, mida ülalkirjeldatud virtualiseerimis- ja konteinertehnoloogiad pakuvad, vajame siiski arvutusressursse. Ettevõtted ostavad kalleid servereid või rendivad andmekeskusi, kuid sellisel juhul tuleb teha arvutused (mõnikord ebareaalsed), kui palju ressursse meil vaja läheb, kas kasutame neid 24/7 ja mis eesmärgil. Näiteks tootmiseks on vaja XNUMX/XNUMX töötavat serverit, aga kas vajame sarnaseid ressursse ka väljaspool tööaega testimiseks? See sõltub ka läbiviidava testi tüübist. Näiteks võiks tuua koormus-/stressitestid, mida plaanime läbi viia töövälisel ajal, et järgmisel päeval tulemusi saada. Kuid kindlasti ei nõuta XNUMX/XNUMX serveri kättesaadavust täielike automatiseeritud testide ja eriti mitte käsitsi testimise keskkondade jaoks. Selliste olukordade jaoks oleks hea hankida nõudmisel nii palju ressursse, kui vaja, need ära kasutada ja lõpetada maksmine, kui neid enam ei vajata. Veelgi enam, oleks tore saada need kohe kätte, tehes mõne hiireklõpsu või käivitades paar skripti. Selleks kasutatakse avalikke pilvi. Vaatame definitsiooni:
„Avalikku pilve määratletakse kui andmetöötlusteenuseid, mida pakuvad kolmandatest osapooltest pakkujad avaliku Interneti kaudu, muutes need kättesaadavaks kõigile, kes soovivad neid kasutada või osta. Need võivad olla tasuta või tellimisel müüdavad, võimaldades klientidel maksta kulutatud protsessori tsüklite, salvestusruumi või ribalaiuse eest ainult kasutuse eest.
On arvamus, et avalikud pilved on kallid. Kuid nende põhiidee on ettevõtte kulude vähendamine. Nagu varem mainitud, võimaldavad avalikud pilved hankida ressursse nõudmisel ja maksta ainult nende kasutusaja eest. Samuti unustame vahel ära, et töötajad saavad palka ja ka spetsialistid on kallis ressurss. Arvestada tuleb sellega, et avalikud pilved muudavad infrastruktuuri toe oluliselt lihtsamaks, mis võimaldab inseneridel keskenduda olulisematele ülesannetele.
Automatiseerimise infrastruktuuri väärtus
Milliseid konkreetseid ressursse vajame kasutajaliidese täielikuks testimiseks? Põhimõtteliselt on need virtuaalsed masinad või klastrid (Kubernetesest räägime järgmises jaotises) brauserite ja emulaatorite käitamiseks. Mida rohkem brausereid ja emulaatoreid soovime samaaegselt käivitada, seda rohkem on vaja protsessorit ja mälu ning seda rohkem raha peame selle eest maksma. Seega võimaldavad avalikud pilved testimise automatiseerimise kontekstis meil nõudmisel käivitada suurel hulgal (100, 200, 1000...) brausereid/emulaatoreid, saada võimalikult kiiresti testitulemused ja lõpetada sellise meeletult ressursimahuka eest maksmise. võimsus.
Kõige populaarsemad pilveteenuse pakkujad on Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Juhend sisaldab näiteid GCP kasutamise kohta, kuid üldiselt pole vahet, mida automatiseerimistoimingute jaoks kasutate. Kõik need pakuvad ligikaudu sama funktsiooni. Tavaliselt keskendub juhtkond teenusepakkuja valimiseks kogu ettevõtte infrastruktuurile ja ärinõuetele, mis ei kuulu käesoleva artikli reguleerimisalasse. Automatiseerimisinseneride jaoks on huvitavam võrrelda pilvepakkujate kasutamist spetsiaalselt testimise eesmärgil pilveplatvormide kasutamisega, nagu Sauce Labs, BrowserStack, BitBar jne. Nii et teeme ka seda! Minu arvates on Sauce Labs kõige kuulsam pilvetestimise farm, mistõttu kasutasin seda võrdluseks.
GCP vs Sauce Labs automatiseerimise eesmärgil:
Kujutagem ette, et peame üheaegselt käivitama 8 veebitesti ja 8 Androidi testi. Selleks kasutame GCP-d ja käitame selenoidiga kahte virtuaalmasinat. Esimesel tõstame üles 2 konteinerit brauseriga. Teisel on 8 emulaatoritega konteinerit. Vaatame hindu:
Chrome'iga ühe konteineri käitamiseks vajame n1-standard-1 auto. Androidi puhul on see nii n1-standard-4 ühe emulaatori jaoks. Tegelikult on paindlikum ja odavam viis määrata CPU/Memory jaoks konkreetsed kasutajaväärtused, kuid hetkel pole see Sauce Labsiga võrdlemiseks oluline.
Ja siin on Sauce Labsi kasutamise tariifid:
Usun, et olete erinevust juba märganud, kuid esitan siiski tabeli meie ülesande arvutustega:
Vajalikud ressursid
Igakuine
Tööaeg(8–8)
Tööaeg+ Ennetav
GCP veebi jaoks
n1-standard-1 x 8 = n1-standard-8
$194.18
23 päeva * 12 tundi * 0.38 = 104.88 dollarit
23 päeva * 12 tundi * 0.08 = 22.08 dollarit
Kastmete laborid veebi jaoks
Virtual Cloud8 paralleeltestid
$1.559
-
-
GCP Androidile
n1-standard-4 x 8: n1-standard-16
$776.72
23 päeva * 12 tundi * 1.52 = 419.52 dollarit
23 päeva * 12 tundi * 0.32 = 88.32 dollarit
Sauce Labs Androidile
Real Device Cloud 8 paralleeltestid
$1.999
-
-
Nagu näete, on kulude erinevus tohutu, eriti kui teete teste ainult XNUMX-tunnise tööperioodi jooksul. Kuid saate kulusid veelgi vähendada, kui kasutate ennetavaid masinaid. Mis see on?
Ennetav VM on eksemplar, mille saate luua ja käitada tavalistest eksemplaridest palju madalama hinnaga. Kuid Compute Engine võib need juhtumid lõpetada (ennestada), kui see nõuab muude ülesannete jaoks juurdepääsu nendele ressurssidele. Ennetavad eksemplarid on Compute Engine'i liigne võimsus, mistõttu nende saadavus sõltub kasutusest.
Kui teie rakendused on tõrketaluvusega ja taluvad võimalikke eksemplaride ennetusi, võivad ennetavad eksemplarid teie Compute Engine'i kulusid märkimisväärselt vähendada. Näiteks saab paketttöötluse töid käivitada ennetatavatel eksemplaridel. Kui mõned neist juhtudest töötlemise ajal lõpetatakse, töö aeglustub, kuid ei peatu täielikult. Ennetavad eksemplarid viivad teie paketttöötluse ülesanded lõpule ilma olemasolevatele eksemplaridele täiendavat töökoormust panemata ja ilma, et peaksite täiendavate tavaliste eksemplaride eest täishinda maksma.
Ja see pole ikka veel läbi! Tegelikkuses olen kindel, et keegi ei tee teste 12 tundi ilma vaheajata. Ja kui nii, siis saate virtuaalseid masinaid automaatselt käivitada ja peatada, kui neid pole vaja. Tegelikku kasutusaega võib vähendada 6 tunnini päevas. Siis väheneb makse meie ülesande kontekstis 11 dollarini kuus 8 brauseri eest. Kas pole mitte imeline? Kuid ennetatavate masinate puhul peame olema ettevaatlikud ja valmis katkestusteks ja ebastabiilsuseks, kuigi neid olukordi saab tarkvaras ette näha ja käsitleda. See on seda väärt!
Kuid ma ei ütle mingil juhul „ära kunagi kasuta pilve testfarme”. Neil on mitmeid eeliseid. Esiteks pole see pelgalt virtuaalmasin, vaid täisväärtuslik testimise automatiseerimise lahendus, millel on karbist välja võetud funktsionaalsus: kaugjuurdepääs, logid, ekraanipildid, videosalvestus, erinevad brauserid ja füüsilised mobiilseadmed. Paljudes olukordades võib see olla oluline šikk alternatiiv. Testimisplatvormid on eriti kasulikud IOS-i automatiseerimiseks, kui avalikud pilved suudavad pakkuda ainult Linuxi/Windowsi süsteeme. Kuid iOS-ist räägime järgmistes artiklites. Soovitan alati vaadata olukorda ja lähtuda ülesannetest: mõnel juhul on odavam ja efektiivsem kasutada avalikke pilvi ning mõnel juhul on testplatvormid kulutatud raha kindlasti väärt.
Illustratsioon infrastruktuuri hetkeseisust
Lingid uurimiseks
Sarnased tööriistad:
6. Orkestreerimine
Tehnoloogia lühikirjeldus
Mul on häid uudiseid – oleme peaaegu artikli lõpus! Hetkel koosneb meie automatiseerimise infrastruktuur veebi- ja Androidi testidest, mida jookseme paralleelselt läbi GitLab CI, kasutades selleks Dockeri toega tööriistu: Selenium grid ja Selenoid. Lisaks kasutame brauserite ja emulaatoritega konteinerite majutamiseks GCP kaudu loodud virtuaalmasinaid. Kulude vähendamiseks käivitame need virtuaalsed masinad ainult nõudmisel ja peatame need siis, kui testimist ei toimu. Kas on veel midagi, mis saaks meie infrastruktuuri parandada? Vastus on jah! Saage tuttavaks Kubernetesega (K8s)!
Kõigepealt vaatame, kuidas on omavahel seotud sõnad orkestratsioon, klaster ja Kubernetes. Kõrgel tasemel on orkestreerimine süsteem, mis juurutab ja haldab rakendusi. Testimise automatiseerimiseks on sellised konteinerrakendused Selenium grid ja Selenoid. Docker ja K8 täiendavad üksteist. Esimest kasutatakse rakenduse juurutamiseks, teist orkestreerimiseks. K8s on omakorda klaster. Klastri ülesandeks on VM-ide kasutamine sõlmedena, mis võimaldab installida ühe serveri (klastri) sees erinevaid funktsioone, programme ja teenuseid. Kui mõni sõlmedest ebaõnnestub, hakkavad teised sõlmed tööle, mis tagab meie rakenduse katkematu töö. Lisaks sellele on K8s-l oluline skaleerimisega seotud funktsionaalsus, tänu millele saame automaatselt optimaalse hulga ressursse lähtuvalt koormusest ja seatud limiitidest.
Tegelikult pole Kubernetese käsitsi nullist juurutamine sugugi triviaalne ülesanne. Ma jätan lingi kuulsale juhendile "Kubernetes The Hard Way" ja kui olete huvitatud, võite seda harjutada. Kuid õnneks on alternatiivseid meetodeid ja vahendeid. Lihtsaim viis on kasutada GCP-s Google Kubernetes Engine’i (GKE), mis võimaldab saada mõne klikiga valmis klastri. Soovitan seda lähenemisviisi kasutada õppimise alustamiseks, kuna see võimaldab teil keskenduda K8-de kasutamise õppimisele oma ülesannete täitmisel, selle asemel, et õppida, kuidas tuleks sisemisi komponente omavahel integreerida.
Automatiseerimise infrastruktuuri väärtus
Vaatame mõnda olulist funktsiooni, mida K8s pakub:
- rakenduse juurutamine: VM-i asemel mitme sõlmega klastri kasutamine;
- dünaamiline skaleerimine: vähendab ressursside maksumust, mida kasutatakse ainult nõudmisel;
- iseparanemine: kaunade automaatne taastamine (mille tulemusena taastatakse ka konteinerid);
- värskenduste levitamine ja muudatuste tagasivõtmine ilma seisakuta: tööriistade, brauserite ja emulaatorite värskendamine ei katkesta praeguste kasutajate tööd
Kuid K8s pole ikkagi hõbekuul. Et mõista kõiki kaalutavate tööriistade (Selenium grid, Selenoid) eeliseid ja piiranguid, käsitleme lühidalt K8-de struktuuri. Klaster sisaldab kahte tüüpi sõlme: põhisõlmed ja töösõlmed. Juhtsõlmed vastutavad haldus-, juurutamis- ja ajakavastamisotsuste eest. Töötajate sõlmed on koht, kus rakendusi käitatakse. Sõlmed sisaldavad ka konteineri käituskeskkonda. Meie puhul on selleks Docker, mis vastutab konteineritega seotud toimingute eest. Aga on ka näiteks alternatiivseid lahendusi. Oluline on mõista, et katlakivi eemaldamine või iseparanemine ei kehti otse konteinerite kohta. Seda rakendatakse kaunade arvu lisamise/vähendamise teel, mis omakorda sisaldavad konteinereid (tavaliselt üks konteiner kauna kohta, kuid olenevalt ülesandest võib neid olla rohkem). Kõrgetasemeline hierarhia koosneb töötajate sõlmedest, mille sees on kaunad, mille sees on tõstetud konteinerid.
Skaleerimise funktsioon on võtmetähtsusega ja seda saab rakendada nii klastri sõlmede kogumi sõlmedele kui ka sõlme kuuluvatele sõlmedele. Skaleerimist on kahte tüüpi, mis kehtivad nii sõlmede kui ka kaunade puhul. Esimene tüüp on horisontaalne – skaleerimine toimub sõlmede/kaunade arvu suurendamise teel. See tüüp on eelistatavam. Teine tüüp on vastavalt vertikaalne. Skaleerimine toimub sõlmede/kaunade suuruse, mitte nende arvu suurendamise teel.
Vaatame nüüd oma tööriistu ülaltoodud terminite kontekstis.
Seleeni võre
Nagu varem mainitud, on seleenivõrk väga populaarne tööriist ja pole üllatav, et see on konteinerisse paigutatud. Seetõttu pole üllatav, et Seleniumi võrku saab K8-des kasutusele võtta. Näite selle kohta, kuidas seda teha, leiate ametlikust K8s hoidlast. Nagu tavaliselt, lisan lingid jaotise lõppu. Lisaks näitab juhend, kuidas seda Terraformis teha. Samuti on juhised brauseri konteinereid sisaldavate kaustade arvu skaleerimiseks. Kuid automaatne skaleerimise funktsioon K8-de kontekstis pole ikka veel täiesti ilmne ülesanne. Õppima asudes ei leidnud ma praktilisi juhiseid ega soovitusi. Pärast mitmeid uuringuid ja eksperimente DevOpsi meeskonna toel valisime lähenemisviisi, mille kohaselt tõstame konteinerid koos vajalike brauseritega ühte taskusse, mis asub ühe töötaja sõlme sees. See meetod võimaldab meil rakendada sõlmede horisontaalse skaleerimise strateegiat, suurendades nende arvu. Loodan, et see tulevikus muutub ja näeme järjest rohkem kirjeldusi parematest lähenemistest ja valmislahendustest, eriti pärast muudetud sisearhitektuuriga Selenium grid 4 väljaandmist.
Selenoid:
Selenoidide kasutuselevõtt K8-des on praegu suurim pettumus. Need ei ühildu. Teoreetiliselt saame Selenoidi konteineri kauna sees tõsta, kuid kui Selenoid hakkab brauserite abil konteinereid käivitama, jäävad need ikkagi samasse kasti. See muudab skaleerimise võimatuks ja selle tulemusena ei erine selenoidi töö klastris tööst virtuaalmasinas. Loo lõpp.
Moon:
Teades seda kitsaskohta Selenoidiga töötamisel, andsid arendajad välja võimsama tööriista nimega Moon. See tööriist loodi algselt Kubernetesiga töötamiseks ja selle tulemusena saab ja tuleks kasutada automaatse skaleerimise funktsiooni. Veelgi enam, ma ütleks, et hetkel on üksi tööriist Seleniumi maailmas, millel on juba karbist väljas K8-de klastri tugi (pole enam saadaval, vaadake järgmist tööriista ). Moon'i põhifunktsioonid, mis seda tuge pakuvad, on järgmised:
Täiesti kodakondsuseta. Selenoid salvestab mällu teavet jooksvate brauseri seansside kohta. Kui selle protsess mingil põhjusel jookseb kokku - kõik töötavad seansid lähevad kaotsi. Kuu seevastu puudub sisemine olek ja seda saab kopeerida andmekeskustes. Brauseri seansid jäävad ellu ka siis, kui üks või mitu koopiat katkevad.
Niisiis, Moon on suurepärane lahendus, kuid on üks probleem: see pole tasuta. Hind sõltub seansside arvust. Tasuta saate käivitada ainult 0–4 seanssi, mis pole eriti kasulik. Kuid alates viiendast seansist peate iga eest maksma 5 dollarit. Olukord võib ettevõtteti erineda, kuid meie puhul on Mooni kasutamine mõttetu. Nagu ma eespool kirjeldasin, saame nõudmisel käivitada Selenium Gridiga VM-e või suurendada sõlmede arvu klastris. Ligikaudu ühe konveieri jaoks käivitame 500 brauserit ja peatame pärast testide lõppu kõik ressursid. Kui kasutaksime Mooni, peaksime maksma lisaks 500 x 5 = 2500 dollarit kuus, olenemata sellest, kui sageli teste teeme. Jällegi, ma ei ütle, et ärge kasutage Mooni. Teie ülesannete täitmisel võib see olla asendamatu lahendus näiteks juhul, kui teie organisatsioonis on palju projekte/meeskondi ja vajate kõigi jaoks tohutut ühist klastrit. Nagu alati, jätan lõppu lingi ja soovitan teha kõik vajalikud arvutused teie ülesande kontekstis.
Callisto: (Tähelepanu! Seda ei ole originaalartiklis ja see sisaldub ainult venekeelses tõlkes)
Nagu ütlesin, on Seleen väga populaarne tööriist ja IT valdkond areneb väga kiiresti. Sel ajal kui ma tõlkimisega tegelesin, ilmus veebi uus paljulubav tööriist Callisto (tere Cypress ja teised seleenitapjad). See töötab natiivselt koos K8-dega ja võimaldab teil käitada Selenoid-konteinereid kaunades, mis on jaotatud sõlmede vahel. Kõik töötab kohe karbist välja võttes, sealhulgas automaatne skaleerimine. Fantastiline, aga vajab testimist. Mul on juba õnnestunud see tööriist juurutada ja mitu katset läbi viia. Kuid järeldusi on liiga vara teha, pärast pika vahemaa tulemuste saamist teen võib-olla tulevastes artiklites ülevaate. Praegu jätan ainult lingid sõltumatutele uuringutele.
Illustratsioon infrastruktuuri hetkeseisust
Lingid uurimiseks
Sarnased tööriistad
7. Infrastructure as Code (IaC)
Tehnoloogia lühikirjeldus
Ja nüüd jõuame viimase osani. Tavaliselt ei vastuta selle tehnoloogia ja sellega seotud ülesannete eest automaatikainsenerid. Ja selleks on põhjused. Esiteks on paljudes organisatsioonides taristuküsimused DevOpsi osakonna kontrolli all ja arendusmeeskondadele ei lähe tegelikult korda, mis torujuhtme tööle paneb ja kuidas kõike sellega seonduvat toetada on vaja. Teiseks, olgem ausad, Infrastructure as Code (IaC) praktika pole paljudes ettevõtetes endiselt omaks võetud. Kuid kindlasti on sellest saanud populaarne trend ja oluline on püüda olla kaasatud sellega seotud protsessidesse, lähenemistesse ja tööriistadesse. Või vähemalt olla kursis.
Alustame selle lähenemisviisi kasutamise motivatsioonist. Oleme juba arutanud, et GitlabCI-s testide käitamiseks vajame Gitlab Runneri käitamiseks minimaalselt ressursse. Ja brauserite/emulaatoritega konteinerite käitamiseks peame reserveerima virtuaalse masina või klastri. Lisaks testimisressurssidele vajame märkimisväärsel hulgal võimsust arendus-, lavastus-, tootmiskeskkondade toetamiseks, mis hõlmab ka andmebaase, automaatseid ajakavasid, võrgukonfiguratsioone, koormuse tasakaalustajaid, kasutajaõigusi jne. Põhiküsimus on selle kõige toetamiseks vajalik pingutus. Muudatuste tegemiseks ja värskenduste levitamiseks on mitu võimalust. Näiteks GCP kontekstis saame kasutada brauseris kasutajaliidese konsooli ja teha kõiki toiminguid nuppudele klõpsates. Alternatiiviks oleks kasutada API-kutseid pilveüksustega suhtlemiseks või gcloudi käsurea utiliidi kasutamine soovitud manipulatsioonide tegemiseks. Kuid tõeliselt suure hulga erinevate üksuste ja infrastruktuuri elementide puhul muutub kõigi toimingute käsitsi tegemine keeruliseks või isegi võimatuks. Pealegi on kõik need käsitsi toimingud kontrollimatud. Me ei saa neid enne täitmist ülevaatamiseks esitada, kasutada versioonikontrollisüsteemi ega kiiresti tagasi võtta intsidendini viinud muudatusi. Selliste probleemide lahendamiseks lõid ja loovad insenerid automaatseid bash/shelli skripte, mis ei ole varasematest meetoditest palju paremad, kuna neid pole nii lihtne protseduurilises stiilis kiiresti lugeda, mõista, hooldada ja muuta.
Selles artiklis ja juhendis kasutan kahte IaC praktikaga seotud tööriista. Need on Terraform ja Ansible. Mõned inimesed usuvad, et neid pole mõtet samaaegselt kasutada, kuna nende funktsionaalsus on sarnane ja need on omavahel asendatavad. Kuid tõsiasi on see, et esialgu antakse neile täiesti erinevad ülesanded. Ja seda, et need tööriistad peaksid üksteist täiendama, kinnitasid HashiCorpi ja RedHati esindavad arendajad ühisel esitlusel. Kontseptuaalne erinevus seisneb selles, et Terraform on serverite endi haldamise tööriist. Kuigi Ansible on konfiguratsioonihaldustööriist, mille ülesanne on nendesse serveritesse tarkvara installida, konfigureerida ja hallata.
Veel üks nende tööriistade oluline eristav tunnus on kodeerimisstiil. Erinevalt bashist ja Ansiblest kasutab Terraform deklaratiivset stiili, mis põhineb täitmise tulemusel saavutatava soovitud lõppoleku kirjeldusel. Näiteks kui loome 10 VM-i ja rakendame muudatused läbi Terraformi, saame 10 VM-i. Kui käivitame skripti uuesti, ei juhtu midagi, kuna meil on juba 10 VM-i ja Terraform teab sellest, kuna salvestab infrastruktuuri hetkeseisu olekufaili. Kuid Ansible kasutab protseduurilist lähenemist ja kui palute tal luua 10 VM-i, siis esimesel käivitamisel saame sarnaselt Terraformiga 10 VM-i. Kuid pärast taaskäivitamist on meil juba 20 VM-i. See on oluline erinevus. Protseduurilises stiilis me praegust olekut ei salvesta ja kirjeldame lihtsalt toimingute jada, mis tuleb sooritada. Muidugi saame hakkama erinevate olukordadega, lisada mitmeid kontrolle ressursside olemasolu ja hetkeseisu kohta, kuid pole mõtet oma aega raisata ja pingutada selle loogika kontrolli all hoidmiseks. Lisaks suurendab see vigade tegemise ohtu.
Kõike eelnevat kokku võttes võime järeldada, et Terraform ja deklaratiivne tähistus on sobivam tööriist serverite varustamiseks. Kuid parem on konfiguratsioonihalduse töö delegeerida Ansible'ile. Kui see on kõrvale jäänud, vaatame kasutusjuhtumeid automatiseerimise kontekstis.
Automatiseerimise infrastruktuuri väärtus
Ainus oluline asi, mida siin mõista, on see, et testimise automatiseerimise infrastruktuuri tuleks käsitleda kogu ettevõtte infrastruktuuri osana. See tähendab, et kõiki IaC praktikaid tuleb rakendada globaalselt kogu organisatsiooni ressurssidele. Kes selle eest vastutab, sõltub teie protsessidest. DevOpsi meeskond on nendes küsimustes kogenum, nad näevad toimuvast tervikpilti. Kvaliteedikontrolli insenerid on aga rohkem kaasatud hooneautomaatika protsessi ja torujuhtme ülesehitusse, mis võimaldab paremini näha kõiki vajalikke muudatusi ja parendusvõimalusi. Parim variant on teha koostööd, vahetada teadmisi ja ideid, et saavutada oodatud tulemus.
Siin on mõned näited Terraformi ja Ansible kasutamisest testimise automatiseerimise kontekstis ja tööriistade kohta, millest me varem rääkisime:
1. Kirjeldage Terraformi abil VM-ide ja klastrite vajalikke omadusi ja parameetreid.
2. Paigalda Ansible abil testimiseks vajalikud tööriistad: docker, Selenoid, Selenium Grid ja lae alla vajalikud brauserite/emulaatorite versioonid.
3. Kirjeldage Terraformi abil selle VM-i omadusi, milles GitLab Runner käivitatakse.
4. Installige Ansible abil GitLab Runner ja vajalikud kaasnevad tööriistad, määrake seaded ja konfiguratsioonid.
Illustratsioon infrastruktuuri hetkeseisust
Lingid uurimiseks:
Sarnased tööriistad
Teeme kokkuvõtte!
Samm
Tehnoloogia
TÖÖRIISTAD
Automatiseerimise infrastruktuuri väärtus
1
Kohalik jooksmine
Node.js, seleen, Appium
- Kõige populaarsemad tööriistad veebi ja mobiili jaoks
- Toetab paljusid keeli ja platvorme (sh Node.js)
2
Versioonikontrollisüsteemid
Git
- Sarnased eelised arenduskoodiga
3
Konteinerimine
Docker, Selenium Grid, Selenoid (veeb, Android)
- Testide paralleelne läbiviimine
- Isoleeritud keskkonnad
- Lihtsad ja paindlikud versiooniuuendused
- Kasutamata ressursside dünaamiline peatamine
- Lihtne üles seada
4
CI/CD
Gitlab CI
- Katsetab torujuhtme osa
- Kiire tagasiside
- Nähtavus kogu ettevõttele/meeskonnale
5
Pilveplatvormid
Google Cloud Platform
- Ressursid nõudmisel (maksame ainult vajaduse korral)
- Lihtne hallata ja värskendada
- Kõigi ressursside nähtavus ja kontroll
6
Orkestreerimine
Kubernetes
Konteinerite kontekstis, mille brauserid/emulaatorid on kaustades:
- Skaleerimine/automaatne skaleerimine
- Enesetervendamine
- Värskendused ja tagasipööramised katkestusteta
7
Infrastruktuur kui kood (IaC)
Terraform, Ansible
- Sarnased eelised arendustaristuga
- Kõik koodi versioonide loomise eelised
- Lihtne teha muudatusi ja hooldada
- Täielikult automatiseeritud
Mõttekaardi diagrammid: infrastruktuuri areng
samm: kohalik
samm: VCS
3. samm: konteinerisse paigutamine
4. samm: CI/CD
samm: pilveplatvormid
samm: orkestreerimine
samm: IaC
Mis edasi?
Niisiis, see on artikli lõpp. Aga lõpetuseks tahaksin teiega mõned kokkulepped sõlmida.
Sinu poolt
Nagu alguses ütlesin, soovin, et artiklist oleks praktilist kasu ja see aitaks saadud teadmisi reaalses töös rakendada. lisan uuesti.
Kuid ka pärast seda ärge peatuge, harjutage, uurige asjakohaseid linke ja raamatuid, uurige, kuidas see teie ettevõttes töötab, leidke kohti, mida saaks parandada, ja osalege selles. Edu!
Minu poolt
Pealkirjast on näha, et see oli alles esimene osa. Vaatamata sellele, et see osutus üsna mahukaks, on olulised teemad siin siiski käsitlemata. Teises osas kavatsen vaadelda automatiseerimise infrastruktuuri IOS-i kontekstis. Apple'i piirangute tõttu iOS-i simulaatorite käitamisel ainult macOS-süsteemides on meie lahenduste valik kitsendatud. Näiteks ei saa me kasutada Dockerit simulaatori käitamiseks ega avalikke pilvi virtuaalmasinate käitamiseks. Kuid see ei tähenda, et muid alternatiive poleks. Püüan teid kursis hoida täiustatud lahenduste ja kaasaegsete tööriistadega!
Samuti pole ma maininud päris suuri jälgimisega seotud teemasid. 3. osas käsitlen kõige populaarsemaid infrastruktuuri jälgimise tööriistu ning milliseid andmeid ja mõõdikuid tuleks arvesse võtta.
Ja lõpuks. Tulevikus plaanin välja anda videokursuse testimise infrastruktuuri ja populaarsete tööriistade ehitamisest. Praegu on internetis päris palju DevOpsi kursusi ja loenguid, kuid kõik materjalid on välja toodud arenduse, mitte testide automatiseerimise kontekstis. Selles küsimuses vajan väga tagasisidet, kas selline kursus on testijate ja automaatikainseneride kogukonna jaoks huvitav ja väärtuslik. Ette tänades!
Allikas: www.habr.com