Osa 1: Web / Android
Märkus: see artikkel on originaali venekeelse tõlge Siiski on kõik illustratsioonid, lingid, tsitaadid ja terminid säilitatud originaalkeeles, et vältida tähenduse moonutamist venekeelsel tõlkel. Soovin teile head õppimist!
Praegu on DevOps eriala üks nõutumaid IT-sektoris. Kui avate populaarsed tööotsingu saidid ja seadistate palga filtrid, siis näete, et DevOpsiga seotud ametikohad on loendi alguses. Kuid on oluline mõista, et see kehtib peamiselt ‘Senior’ positsioonide kohta, mis eeldab, et kandidaadil on kõrge oskuste tase ja teadmised tehnoloogiatest ning tööriistadest. Sellega kaasneb ka kõrge vastutus, mis on seotud tootmise sujuva toimimisega. Siiski oleme unustamas, mis DevOps tegelikult on. Algusest peale ei olnud see mingi konkreetne inimene või osakond. Kui otsida selle termini määratlemisi, leiame palju kauneid ja õigeid nimisõnu, nagu metoodika, praktikad, kultuuriline filosoofia, kontseptide kogum ja nii edasi.
Minu spetsialiseerumine on testimise automatiseerimise insener (QA automation engineer), kuid ma usun, et see ei tohiks piirda end ainult automaatsete testide kirjutamise või testimisraamistike arhitektuuri väljatöötamisega. Alates 2020. aastast on automatiseerimise infrastruktuuri tundmine samuti vajalik. See võimaldab iseseisvalt korraldada automatiseerimisprotsessi, alustades testide käitamisest ja lõpetades tulemuste edastamisega kõigile asjaosalistele vastavalt seatud eesmärkidele. Seetõttu on DevOps'i oskused selle töö täitmiseks hädavajalikud. Ja see kõik on hea, kuid kahjuks on üks probleem (spoiler: käesolev artikel püüab seda probleemi lihtsustada). Probleem seisneb selles, et DevOps on keeruline. Ja see on ilmne, sest ettevõtted ei maksa palju selle eest, mis on lihtne teha... DevOps'i maailmas on palju tööriistu, termineid ja praktikaid, millega tutvuda. Eriti raske on see karjääri alguses ning sõltub kogunenud tehnilisest kogemusest.
Allikas:
Siinkohal lõpetame sissejuhatava osa ja keskendume artikli eesmärgile.
Millest see artikkel räägib
Selles artiklis jagan oma kogemusi testimisautomaatika infrastruktuuri loomisel. Internetis on palju teabeallikaid erinevate tööriistade ja nende kasutamise kohta, kuid sooviksin neid käsitleda rangelt automaatika kontekstis. Usun, et paljude automatiseerimise inseneride jaoks on tuttav olukord, kus välja töötatud teste ei käita keegi peale enda ning nende hooldamine jääb tähelepanuta. Tulemuseks on see, et testid muutuvad aegunuks ja tuleb kulutada aega nende ajakohastamisele. Alustava karjääri jooksul võib see olla suhteliselt keeruline ülesanne: õigesti otsustada, millised tööriistad peaksid aitama selle probleemi lahendamisel, kuidas neid valida, seadistada ja hallata. Mõned testijad pöörduvad abi saamiseks DevOps'i (inimeste) poole ja olgem ausad, see lähenemine töötab. Paljudel juhtudel võib see olla ainus valik, kuna meil puudub ülevaade kõigist sõltuvustest. Kuid nagu teame, on DevOps väga hõivatud, kuna nad peavad mõtlema kogu ettevõtte infrastruktuurile, juurutamisele, jälgimisele, mikroteenustele ja muudele sarnastele ülesannetele, sõltuvalt organisatsioonist/tiimist. Nagu tavaliselt, ei ole automatiseerimine prioriteet. Sellisel juhul peame proovima teha kõik endast oleneva algusest lõpuni. See vähendab sõltuvusi, kiirendab töövoogu, täiustab meie oskusi ja võimaldab näha laiemat pilti toimuvast.
Artiklis on toodud kõige nõudlikumad ja populaarsed tööriistad ning selgitatud, kuidas neid kasutada samm-sammult automatiseerimise infrastruktuuri loomiseks. Igas rühmas on esitatud tööriistad, mida on testitud isikliku kogemuse põhjal. Kuid see ei tähenda, et peaksite kasutama samu tööriistu. Tööriistade enda tähtsus ei ole oluline, need tulevad ja lähevad. Meie inseneride ülesanne on mõista põhialuseid: miks meil on vaja seda tööriistade rühma ja milliseid tööülesandeid saame nende abil lahendada. Seetõttu jätan iga jaotise lõpus linke sarnastele tööriistadele, mida teie organisatsioonis võib-olla kasutatakse.
Mida see artikkel ei käsitle
Kordan veel kord, et artikkel ei käsitle konkreetseid tööriistu, seetõttu ei tule siin koodilõike dokumentatsioonist ega konkreetsete käskude selgitusi. Kuid iga jaotise lõpus jätan lingid põhjalikuks tutvumiseks.
See on tehtud põhjusel, et:
- seda materjali on väga lihtne leida erinevates allikates (dokumentatsioon, raamatud, videokursused);
- kui me hakkame süvitsi minema, peame kirjutama 10, 20, 30 osa sellest artiklist (kuigi plaanis on 2-3);
- Ma ei soovi teie aega raisata, kuna te võite soovida kasutada teisi tööriistu samade eesmärkide saavutamiseks.
Praktika
Soovin, et see materjal oleks igale lugejale kasulik, mitte lihtsalt loetud ja unustatud. Igas õppes on praktika väga oluline osa. Selleks olen valmistanud. Samuti ootab teid kodutöö, et olla kindel, et te ei kopeerinud lihtsameelselt käivitatavaid käsku.
Plaani
Samm
Tehnoloogia
Tööriistad
1
Kohalik käitamine (valmistage veeb / android demo testid ja käitage neid kohalikult)
Node.js, Selenium, Appium
2
Versioonihaldussüsteemid
Git
3
Konteineriseerimine
Docker, Selenium grid, Selenoid (Web, Android)
4
CI / CD
Gitlab CI
5
Pilveteenused
Google Cloud Platform
6
Orkestreerimine
Kubernetes
7
Infrastruktuur kui kood (IaC)
Terraform, Ansible
Iga jaotise struktuur
Kuna jutustuse selge visualiseerimise säilitamiseks on iga jaotis kirjeldatud järgmise plaani kohaselt:
- tehnoloogia lühikirjeldus,
- väärtus automatiseerimisinfrastruktuuri jaoks,
- olekuillustratsioon infrastruktuuri jaoks,
- õppimise lingid,
- sarnased tööriistad.
1. Kohalik testide käitamine
Tehnoloogia lühikirjeldus
See on vaid ettevalmistav samm, et käivitada demonstreerivaid teste kohalikke ja kontrollida, et need edukalt läbivad. Praktikas kasutatakse Node.js-i, kuid programmeerimiskeel ja platvorm ei ole olulised ning võib kasutada ka neid, mida teie ettevõttes kasutatakse.
Kuid automaatimistööriistadena soovitan kasutada Selenium WebDriveri web-platvormide jaoks ja Appiumi Android-platvormide jaoks, sest järgmistel sammudel kasutame Docker-pilte, mis on kohandatud nende tööriistadega töötamiseks. Veelgi enam, viidates töökuulutuste nõuetele, on need tööriistad turul kõige nõudlikumad.
Kuidas te võisite märgata, vaatleme ainult web- ja Android-teste. Kahjuks on IOS täiesti erinev lugu (aitäh Apple). Plaanin demonstreerida IOS-i lahendusi ja praktikaid järgnevates osades.
Väärtus automaatimise infrastruktuurile
Infrastruktuuri seisukohalt ei paku kohalik käivitamine mingit väärtust. Sa kontrollid ainult, et testid töötavad kohalikul masinal kohalikes brauserites ja simulatsioonides. Kuid igal juhul on see vajalik lähtepunkt.
Praeguse infrastruktuuri seisundi illustreerimine
Uurimiseks mõeldud lingid
Sarnased töötajad
- igasugune programmeerimiskeel, mis sulle meeldib, koos Selenium/Appium - testidega;
- iga test;
- iga testijooksja.
2. Versioonihaldussüsteemid (Git)
Tehnoloogia lühikirjeldus
Ei ole kellelegi uudiseks, kui ütlen, et versioonihaldussüsteem on äärmiselt oluline osa arendamisest nii meeskonnas kui ka individuaalselt. Erinevatele allikatele toetudes võib kindlalt öelda, et Git on selle vallas kõige populaarsem esindaja. Versioonihaldussüsteem pakub mitmeid eeliseid, nagu koodi jagamine, versioonide hoidmine, taastumine varasematele harudele, projekti ajaloo jälgimine ja varukoopiad. Me ei hakka iga punkti detailselt arutama, kuna olen kindel, et olete sellega hästi tuttav ja kasutate seda oma igapäevases töös. Kuid kui te ei ole, siis soovitan teil seda artiklit lugemist peatada ja seda tühimikku võimalikult kiiresti täita.
Väärtus automaatimise infrastruktuurile
Siin võite esitada mõistliku küsimuse: „Miks ta räägib meile Gitist? Kõik teavad ja kasutavad seda nii arenduskoodi kui ka automaattestide jaoks.” Te oleksite täiesti õiged, kuid selles artiklis räägime infrastruktuurist ja see jaotis mängib rolli eelvaateks jaotisele 7: „Infrastruktuur kui kood (IaC)”. Meie jaoks tähendab see, et kogu infrastruktuur, sealhulgas testimise infrastruktuur, kirjeldatakse koodina, seega võime sellele rakendada versioonihaldussüsteeme ja saada sarnaseid eeliseid nagu arenduskoodi ja automatiseerimise puhul.
Vaadake IaC-d üksikasjalikumalt sammul 7, kuid juba praegu saate alustada Giti kasutamist kohalikult, luues kohaliku repositooriumi. Üldine pilt laieneb, kui lisame infrastruktuurile kaugrepositooriumi.
Praeguse infrastruktuuri seisundi illustreerimine
Uurimiseks mõeldud lingid
Sarnased töötajad
3. Konteinerimise (Docker) teema
Tehnoloogia lühikirjeldus
Kuidas konteineriseerimine on mängu reegleid muutnud, saame aru, kui vaatame tagasi mõned kümned aastad. Tookord ostsid ja kasutasid inimesed servereid rakenduste käimiseks. Enamasti ei olnud aga vajalikud ressursid rakenduste käitamiseks ette teada. See viis selleni, et ettevõtted kulutasid raha kallite võimsate serverite ostmiseks, kuid osa neist ressurssidest jäi kasutamata.
Evolutsiooni järgmine etapp olid virtuaalsed masinad (VM), mis lahendasid probleemid, mis olid seotud kasutamata ressursside kulutamisega. See tehnoloogia võimaldas rakenduste käitamist üksteisest iseseisvalt ühes serveris, eraldades täielikult isoleeritud ruumi. Kahjuks on aga igal tehnoloogial oma puudused. VM käitamine nõuab täis funktsionaalset operatsioonisüsteemi, mis kasutab CPU-d, RAM-i, salvestusruumi ja sõltuvalt operatsioonisüsteemist tuleb arvestada ka litsentsikuludega. Need tegurid mõjutavad laadimisaega ja muudavad portatiivsuse keerulisemaks.
Nüüd oleme jõudnud konteineriseerimise juurde. See tehnoloogia lahendas taas eelmise probleemi, kuna konteinerid ei kasuta täisfunktsionaalset operatsioonisüsteemi, mis vabastab suure hulga ressursse ning pakub kiiret ja paindlikku lahendust kandmiseks.
Loomulikult ei ole konteineriseerimise tehnoloogia midagi uut, see esitati esmakordselt 70. aastate lõpus. Sel ajal tehtud palju uurimusi ja katseid. Kuid just Docker kohandas selle tehnoloogia ja tegi selle massidele hõlpsasti kättesaadavaks. Tänapäeval, kui räägime konteineritest, mõtleme enamasti Dockerile. Rääkides Docker-konteineritest, mõtleme Linuxi konteineritele. Saame kasutada Windowsi ja macOS süsteeme konteinerite käitamiseks, kuid oluline on mõista, et sel juhul tekib täiendav kiht. Näiteks käivitab Docker Macis märkamatult konteinerid kergkaalu Linuxi virtuaalmasina sees. Me tuleme sellele teemal tagasi, kui arutame Androidi emulaatorite käitamise üle konteinerites, kuna siin on oluline nüanss, mida tuleb üksikasjalikumalt arutada.
Väärtus automaatimise infrastruktuurile
Oleme leidnud, et konteineriseerimine ja Docker on suurepärased. Vaatame seda automatiseerimise kontekstis, sest iga tööriist või tehnoloogia peaks lahendama mingi probleemi. Määratlegem automaatika testimise ilmsed probleemid UI-testide kontekstis:
- suured sõltuvused Seleniumi ja eriti Appiumi installimisel;
- ühilduvusprobleemid brauserite, simulaatorite ja draiverite versioonide vahel;
- puudub isoleeritud ruum brauserite/simulaatorite jaoks, mis on eriti kriitiline, kui käitada paralleelselt;
- raske hallata ja toetada, kui on vaja käivitada 10, 50, 100 või isegi 1000 brauserit korraga.
Kuna Selenium on kõige populaarsem automatiseerimistööriist ja Docker kõige populaarsem konteineriseerimise tööriist, ei peaks olema üllatus, et keegi püüdis neid ühendada, et luua võimas tööriist eespool mainitud probleemide lahendamiseks. Uurime neid lahendusi lähemalt.
Selenium grid in docker
See tööriist on maailma kõige populaarsem Selenium, mis võimaldab mitme brauseri käitamist mitmel masinal ning nende haldamist keskpunktist. Käivitamiseks on vajalik registreerida vähemalt 2 osa: Hub ja Node(d). Hub on keskne sõlm, mis saab kõik päringud testidelt ja jaotab need vastavatesse Nodes-se. Iga Node'i jaoks saame seadistada konkreetse konfiguratsiooni, näiteks määrata vajaliku brauseri ja selle versiooni. Kuid meil on endiselt vaja ise hoolitseda brauserite ühilduvate draiverite eest ning installida need vajalikesse Nodes-se. Seetõttu ei kasutata Selenium grid'i puhtal kujul, välja arvatud juhtudel, kui peame töötama brauseritega, mida ei saa Linuxi operatsioonisüsteemis installida. Kõikidel muudel juhtudel on palju paindlikum ja õigem lahendus kasutada Docker-pilte Selenium grid Hub'i ja Nodes'e käitamiseks. See lähenemine lihtsustab oluliselt sõlmede haldamist, kuna saame valida vajaliku pildi, kus on juba installitud ühilduvad brauserite ja draiverite versioonid.
Hoolimata negatiivsetest arvustustest stabiilsuse kohta, eriti suurte Nodes'ide samaaegsel käivitamisel, jääb Selenium grid siiski kõige populaarsemaks tööriistaks Selenium-testide paralleelseks käivitamiseks. On oluline märkida, et avatud lähtekoodiga lahendustes ilmuvad pidevalt erinevad täiustused ja modifikatsioonid, mis aitavad lahendada erinevaid kitsaskohti.
Selenoid for Web
See komponent on murranguline Seleniumi maailmas, kuna see töötab otse välja kastist ja on teinud paljude automatiseerimise inseneride elu oluliselt lihtsamaks. Esiteks, see ei ole lihtsalt veel üks modifikatsioon Selenium gridist. Selle asemel on arendajad loonud täiesti uue versiooni Selenium Hubist Golangi keeles, mis koos kergete Docker-piltidega erinevate brauserite jaoks on andnud impulsi testimise automatiseerimise arengule. Veelgi enam, Selenium Gridis peame me ette määrama kõik vajalikud brauserid ja nende versioonid, mis ei ole probleem, kui töötame ainult ühe brauseriga. Kuid kui jutt käib mitmest toetatavast brauserist, siis Selenoid on number üks lahendus, tänu funktsioonile 'brauser nõudmisel'. Kõik, mida meilt nõutakse, on vajalikud pildid brauseritega eelnevalt üles laadida ja uuendada konfiguratsioonifaili, millega Selenoid suhtleb. Kui Selenoid saab testidest päring, käivitab ta automaatselt vajaliku konteineri soovitud brauseriga. Kui test on lõpule viidud, Selenoid vabastab konteineri, andes järgnevaid päringute ressursse vabaks. See lähenemine kõrvaldab täielikult tuntud probleemi 'sõlmede dementeerimisest', millega me sageli Selenium gridis kokku puutume.
Kahjuks ei ole Selenoid siiski hõbedane kuul. Saime funktsiooni 'brauserid nõudmise järgi', kuid funktsioon 'ressursid nõudmise järgi' pole veel saadaval. Selenoid'i kasutamiseks peame selle kastma füüsilisse riistvarasse või virtuaalmasinasse, mis tähendab, et peame eelnevalt teadma, kui palju ressursse on vaja eraldada. Ma arvan, et see ei ole probleem väikeste projektide puhul, mis käivitavad samal ajal 10, 20 või isegi 30 brauserit. Aga mis siis, kui me vajame 100, 500, 1000 ja rohkem? Pole mingit mõtet pidevalt hoida ja maksta nii suure hulga ressursside eest. Artikli osades 5 ja 6 arutame lahendusi, mis võimaldavad skaleeruda, vähendades sellega oluliselt ettevõtte kulusid.
Selenoid for Android
Pärast Selenoid'i edukat kasutamist veebiautomaatika tööriistana soovisid inimesed midagi sarnast Androidile. Ja see juhtus – Selenoid ilmus Androidi toe kaudu. Kasutaja kõrgetasemelise vaatepunktist on tööpõhimõte sarnane veebiautomaatsusele. Ainus erinevus on see, et veebibrauserite konteinerite asemel käivitab Selenoid Android-emulaatorite konteinerid. Minu arvates on see praegu kõige võimsam tasuta tööriist Androidi testide paralleelseks käivitamiseks.
Mulle ei meeldiks üldse rääkida selle tööriista negatiivsetest külgedest, kuna see tõesti meeldib mulle. Kuid siiski on siin kohal need samad puudused, mis on seotud web-automaatikaga, seonduvad skaleerimisega. Lisaks sellele tuleb rääkida veel ühest piirangust, mis võib osutuda üllatuseks, eriti kui seadistame tööriista esmakordselt. Android-piltide käivitamiseks on meil vajalik füüsiline masin või VM koos sisemiste virtualiseerimise toetusega. Praktikas juhendan, kuidas seda Linuxi VM-is aktiveerida. Siiski, kui olete macOS kasutaja ja soovite Selenoidit kohapeal juurutada, siis Android-testide käitamine sellel on võimatu. Kuid alati võite kohapeal käivitada Linuxi VM-i koos seadistatud sisemise virtualiseerimisega ja juurutada Selenoid seal.
Praeguse infrastruktuuri seisundi illustreerimine
Selles artiklis lisame 2 tööriista infrastruktuuri illustreerimiseks. Need on Selenium grid web-testide jaoks ja Selenoid Android-testide jaoks. GitHubis olevas juhendis näitan samuti, kuidas kasutada Selenoidit web-testide käitamiseks.
Uurimiseks mõeldud lingid
Sarnased töötajad
- On olemas ka teisi konteinerimiseks mõeldud tööriistu, kuid Docker on neist kõige populaarsem. Kui soovite proovida midagi muud, pidage meeles, et need tööriistad, mida me käsitlesime Seleniumi testide paralleelse käitamise jaoks, ei tööta otse välja pakkumisel.
- Nagu juba mainitud, on olemas palju Selenium grid'i modifikatsioone, näiteks.
4. CI / CD
Tehnoloogia lühikirjeldus
Jätkuva integreerimise praktika on arenduses üsna populaarne ja seondub versioonihaldussüsteemidega. Sellegipoolest tunnen, et terminoloogia osas on segadust. Selles lõigus soovin ma kirjeldada kolme selle tehnoloogia modifikatsiooni oma vaatenurgast. Internetist leiate palju artikleid erinevate tõlgendustega, ja on täiesti normaalne, kui teie arvamus erineb. Peamine on, et oleksite oma kolleegidega ühel lainel.
Nii et on olemas kolm terminit: CI - Continuous Integration (jätkuv integreerimine), CD - Continuous Delivery (jätkuv kohaletoimetamine) ja jälle CD - Continuous Deployment (jätkuv juurutamine). (Edasi kasutan neid termineid inglise keeles). Iga muudatus lisab teie arendusprotsessile mitmeid täiendavaid etappe. Kuid sõna pidev (katkestusteta) on kõige olulisem. Selle all mõtleme midagi, mis toimub algusest lõpuni, ilma katkestuste või käsitsi sekkumiseta. Vaatame CI & CD-d ja CD-d antud kontekstis.
- Pidev Integratsioon – on evolutsiooni esimene samm. Uue koodi serverisse saatmise järel ootame kiiret tagasisidet selle kohta, et meie muudatused on korras. Tavaliselt hõlmab CI staatilise koodi analüüsi tööriistade ja moodulitestide/ sisemiste API testide käivitamist. See võimaldab meil saada teavet meie koodi kohta juba mõne sekundi/ minuti jooksul.
- Jätkuv kohaletoimetamine on rohkem arenenud etapp, kus käivitame integratsiooni/UI-testid. Kuid sel hetkel ei saa me tulemusi nii kiiresti, kui CI puhul. Esiteks, need testide tüübid vajavad rohkem aega läbimiseks. Teiseks, enne käivitamist peame oma muudatused deployima testimis-/staging- keskkonda. Veelgi enam, kui räägime mobiilsete rakenduste arendamisest, tuleb lisaloodud etapp rakenduse kogumise jaoks.
- Jätkuv juurutamine tähendab, et me vabastame automaatselt (release) oma muudatused tootmisse, kui kõik vastuvõtute testid on eelnevates etappides läbitud. Lisaks sellele saab pärast release'i etappi seadistada erinevaid etappe, nagu smoke-testide käivitamine tootmises ja huvipakkuvate mõõdikute kogumine. Jätkuv juurutamine on võimalik vaid hea automatiseeritud testide katvuse korral. Kui on vajalikud mingid käsitsi sekkumised, sealhulgas testimine, siis see ei ole enam Jätkuv (continuous). Siis saame rääkida, et meie torujuhe vastab ainult Jätkuva Edastamise praktikale.
Väärtus automaatimise infrastruktuurile
Selles jaotises pean selgitama, et kui räägime lõpp- kuni-lõpp UI-testimisest, siis see tähendab, et peame oma muudatused ja seotud teenused häälestama testkeskkondadesse. Jätkuv integreerimine ei ole selle ülesande puhul rakendatav ja peame tagama, et rakendame vähemalt jätkava kohaletoimetamise praktikaid. Jätkuv juurutamine on samuti mõttekas UI-testimise kontekstis, kui kavatseme neid käitada tootmises.
Ja enne kui vaatame arhitektuuri muudatuste illustratsiooni, tahan öelda paar sõna GitLab CI-st. Erinevalt teistest CI/CD-tööriistadest pakub GitLab kaugrepositooriumi ja palju muid lisafunktsioone. Seega on GitLab rohkem kui lihtsalt CI. See sisaldab valmis lahendusena lähtekoodi haldust, Agile juhtimist, CI/CD pipelines, logimise tööriistu ja mõõdikute kogumist. GitLabi arhitektuur koosneb GitLab CI/CD-st ja GitLab Runnerist. Tõin välja lühikese kirjelduse ametlikult veebilehelt:
Gitlab CI/CD on veebirakendus koos API-ga, mis salvestab oma seisundi andmebaasi, haldab projekte/ehitusi ja pakub kasutajaliidest. GitLab Runner on rakendus, mis töötleb ehitusi. Seda saab juurutada eraldi ja see töötab GitLab CI/CD-ga API kaudu. Testide käitamiseks on vajalik nii GitLabi instants kui ka Runner.
Praeguse infrastruktuuri seisundi illustreerimine
Uurimiseks mõeldud lingid
Sarnased töötajad
- Ja paljusid teisi
5. Pilveteenused
Tehnoloogia lühikirjeldus
Selles osas räägime populaarsest suundumusest, mida nimetatakse 'avalikeks pilvedeks'. Vaatamata tohutule kasule, mida pakuvad ülaltoodud virtualiseerimise ja konteineriseerimise tehnoloogiad, on meil endiselt vaja arvutusresources. Ettevõtted soetavad kallid serverid või rendivad andmekeskuseid, kuid sel juhul on vajalik teha arvutusi (mõnikord ebareaalsed) selle kohta, kui palju ressursse me vajame, kas me kasutame neid 24/7 ja milleks. Näiteks on tootmisprotsessiks vajalik pidevalt töötav server, kuid kas meil on selliseid ressursse vaja ka testimiseks väljaspool tööaega? See sõltub ka teostatud testimise tüübist. Näiteks koormus-/stressitestid, mida plaanime teha väljaspool tööaega, et saada tulemused järgmiseks päevaks. Kuid kindlasti ei vajata serverite ööpäevaringset kättesaadavust end-to-end automaatsete testide jaoks ja eriti käsitsi testimise keskkondade jaoks. Selliste olukordade jaoks oleks hea saada täpselt nii palju ressursse, kui on vajalik nõudmisel, kasutada neid ja lõpetada maksmine, kui neid enam ei vajata. Veelgi rohkem oleks suurepärane saada neid koheselt, tehes paar hiireklõpsu või käivitades mõned skriptid. Selleks kasutatakseki avalikke pilvi. Vaatame määratlust:
Avaliku pilve all mõistetakse kolmandate osapoolte pakutavaid arvutusteenuseid, mis on kergesti kättesaadavad üle avaliku Interneti ning mis on avatud kõigile, kes soovivad neid kasutada või osta. Need võivad olla tasuta või müüdud vastavalt vajadusele, võimaldades klientidel maksta ainult tarbitud CPU tsüklite, salvestuse või ribalaiuse eest.
On arvamus, et avalikud pilved on kallid. Kuid nende põhieesmärk on vähendada ettevõtte kulusid. Nagu juba mainitud, võimaldavad avalikud pilved saada ressursse nõudmisel ja maksta ainult nende kasutamise eest. Samuti unustame tihti, et töötajad saavad palka ja spetsialistid on samuti kallis ressurss. Tuleb arvestada, et avalikud pilved hõlbustavad infrastruktuuri haldamist, lubades inseneridel keskenduda olulistele ülesannetele.
Väärtus automaatimise infrastruktuurile
Millised konkreetsed ressursid on meil vajalikud end-to-end UI-testimiseks? Peamiselt on need virtuaalmasinad või klastrid (räägime Kubernetesest järgmisel teemal) brauserid ja emulaatorid käitamiseks. Mida rohkem brausereid ja emulaatoreid soovime samaaegselt käitada, seda rohkem CPU-d ja mälu on vajalik ning seda rohkem peame selle eest maksma. Nii on avalikud pilveplatvormid automaatsete testide kontekstis võimaldavad meil käitada suurt hulka (100, 200, 1000 …) brausereid/emulaatoreid nõudmisel, saada testimistulemusi võimalikult kiiresti ja lõpetada maksmine nende hullumeelselt ressursimahukate jõudluste eest.
Kõige populaarsemad pilveteenuse pakkujad on Amazon Web Services (AWS), Microsoft Azure ja Google Cloud Platform (GCP). Praktikas on GCP kasutamise näidised esitatud juhendis, kuid üldiselt ei ole oluline, millist te kasutate automatiseerimise jaoks. Kõik pakuvad ligikaudu samu funktsioone. Tavaliselt keskendub teenusepakkuja valimise juhend ettevõtte kogu infrastruktuurile ja ärinõuetele, mis jääb selle artikli raames välja. Automatiseerimise inseneridele oleks huvitavam võrrelda pilveteenuse pakkujate kasutamist pilveplatvormide kasutamisega, mis on konkreetselt suunatud testimise eesmärkidele, nagu Sauce Labs, BrowserStack, BitBar jne. Niisiis, teeme seda! Minu arvates on Sauce Labs kõige tuntum pilvetestimise farm, seega valisin selle võrdluseks.
GCP vs Sauce Labs automatiseerimise eesmärkidel:
Kujutame ette, et meil on vaja samaaegselt käivitada 8 veebitestimist ja 8 Androidi testi. Selleks kasutame GCP-d ja käivitame 2 virtuaalmasinat Selenoidiga. Esimesel tõstame 8 konteinerit, kus on brauserid. Teisel – 8 konteinerit emulaatoritega. Vaadakem hindasid:
Ühe Chrome'i konteineri käivitamiseks vajame n1-standard-1 masinat. Androidi puhul on see n1-standard-4 ühe emulaatori jaoks. Tegelikult on paindlikum ja odavam viis määrata kindlaid kasutaja väärtusi CPU/Memory, kuid hetkel ei ole see Sauce Labsiga võrreldes oluline.
Siin on Sauce Labsi kasutustasud:
Arvan, et olete juba hinnavahet märganud, kuid esitan siiski tabeli arvutustega meie ülesande jaoks:
Nõutavad ressursid
Kuu hind
Tööaeg(8.00 - 20.00)
Tööaeg+ Eemaldatav
GCP veebi jaoks
n1-standard-1 x 8 = n1-standard-8
$194.18
23 päeva * 12h * 0.38 = 104.88$
23 päeva * 12h * 0.08 = 22.08$
Sauce Labs veebi jaoks
Virtuaalne Cloud8 paralleelsed testid
$1.559
—
—
GCP Androidi jaoks
n1-standard-4 x 8: n1-standard-16
$776.72
23 päeva * 12h * 1.52 = 419.52$
23 päeva * 12h * 0.32 = 88.32$
Sauce Labs Androidi jaoks
Reaalsete seadmete pilv 8 paralleelsed testid
$1.999
—
—
Nagu näha, on hinnavahe tohutu, eriti kui teste käivitada ainult tööajal. Kuid kulusid on võimalik veelgi vähendada, kui kasutada eemaldatavaid masinaid. Mis need on?
Eemaldatav VM on instants, mille saate luua ja käitada palju madalama hinnaga kui tavalised instantsid. Siiski võib arvutitehnika need instantsid lõpetada (eemaldada), kui tal on teiste ülesannete jaoks nende ressursside kasutamiseks vajalikke ressursse. Eemaldatavad instantsid on üleliigne Compute Engine'i maht, seega nende kättesaadavus varieerub kasutuse järgi.
Kui teie rakendused on vigade suhtes taluvad ja suudavad taluda võimalikke instantside peatamisi, võivad peatatavad instantsid oluliselt vähendada teie Compute Engine'i kulusid. Näiteks võivad partiitöötlemise ülesanded toimida peatatavates instantsides. Kui mõned neist instantsidest töötlemise ajal lõpetavad, aeglustub töö, kuid ei peatu täielikult. Peatatavad instantsid täidavad teie partiitöötlemise ülesandeid, ilma et need lisaks koormust teie olemasolevatele instantsidele ja ilma, et peaksite maksma täishinda täiendavate normaalsed instantside eest.
Ja see pole veel lõpp! Tõeliselt olen kindel, et keegi ei käivita teste 12 tundi järjest ilma pausita. Ja kui see on tõsi, siis võite automaatselt käivitada ja peatada virtuaalmasinad, kui neid ei vajata. Tegelik kasutusaeg võib langeda kuni 6 tunnini päevas. Siis võib maksmine meie ülesande kontekstis langeda isegi 11 dollarini kuus 8 brauseri eest. Kas see ei ole suurepärane? Kuid peatavate masinatega peame olema ettevaatlikud ja valmis katkestusteks ning ebastabiilseks toimimiseks, kuigi neid olukordi saab programmiliselt ette näha ja käsitleda. See on seda väärt!
Aga ma ei ütle kunagi ‘ärge kasutage pilvetesteerimise farmisid’. Neil on mitmeid eeliseid. Esiteks, see ei ole lihtsalt virtuaalne masin, vaid tõeline lahendus testimise automatiseerimiseks, mis sisaldab palju funktsioone: kaugjuurdepääs, logid, ekraanipildid, videote salvestamine, erinevad brauserid ja füüsilised mobiilseadmed. Paljudes olukordades võib see olla asendamatu ja luksuslik alternatiiv. Eriti kasulikud on testimisplatvormid IOS-automatiseerimise jaoks, kus avalikud pilved pakuvad sageli ainult Linuxi/Windowsi süsteeme. Kuid IOS-ist räägime järgmistes artiklites. Soovitan alati hinnata olukorda ja lähtuda ülesannetest: mõnes on odavam ja efektiivsem kasutada avalikke pilvi, teistes aga on testimisplatvormid kindlasti oma rahaga väärt.
Praeguse infrastruktuuri seisundi illustreerimine
Uurimiseks mõeldud lingid
Sarnased tööriistad:
6. Orkestreerimine
Tehnoloogia lühikirjeldus
Mul on head uudised – me oleme peaaegu artikli lõpuni jõudnud! Praegu koosneb meie automatiseerimise infrastruktuur veebist ja Androidi testidest, mida me käitame paralleelselt GitLab CI kaudu, kasutades Dockerit toetavaid tööriistu: Selenium grid ja Selenoid. Veelgi enam, me kasutame GCP kaudu loodud virtuaalmasinaid, et käivitada nendes konteinerid brauserite ja emulaatoritega. Kulude vähendamiseks käivitame neid virtuaalmasinaid ainult nõudmisel ja peatame, kui testimist ei toimu. Kas on midagi veel, mis võiks meie infrastruktuuri parandada? Vastus on – jah! Tere tulemast Kubernetesesse (K8s)!
Alustuseks vaatame, kuidas on seotud sõnad orkestreerimine, klaster ja Kubernetes. Kõrgeimal tasemel on orkestreerimine süsteem, mis juurutab ja haldab rakendusi. Selliste konteineriseeritud rakenduste testimise automatiseerimiseks on Selenium grid ja Selenoid. Docker ja K8s täiendavad üksteist. Esimene on mõeldud rakenduste juurutamiseks, teine aga orkestreerimiseks. Omalt poolt on K8s klaster. Klastri ülesanne on kasutada VMs Node`idena, mis võimaldab installida erinevat funktsionaalsust, programme ja teenuseid ühe serveri (klastri) raames. Kui mõni Node ebaõnnestub, haaravad teised Nodes vahetult üle, tagades meie rakenduse katkestusteta töö. Lisaks sellele omab K8s olulist funktsionaalsust, mis on seotud skaleerimise (scaling) võimalustega, mille kaudu saame automaatselt optimaalse ressursside arvu, tuginedes koormusele ja kehtestatud piirangutele.
Tõtt öeldes on Kubernetes'i käsitsi seadistamine nullist täiesti keeruline ülesanne. Jätan lingi tuntud praktilisele juhendile "Kubernetes The Hard Way", ja kui teid huvitab, võite harjutada. Kuid õnneks on olemas alternatiivsed viisid ja tööriistad. Lihtsaim neist on Google Kubernetes Engine (GKE) GCP-s, mis võimaldab teil mõne kliki järel saada valmis klastrit. Algõppeks soovitan just seda lähenemist, sest see lubab teil keskenduda K8s kasutamise õppimisele oma ülesannete jaoks, mitte uurida, kuidas sisekomponendid omavahel integreeritud peaksid olema.
Väärtus automaatimise infrastruktuurile
Vaatame mõningaid tähtsaid funktsioone, mida K8s pakub:
- rakenduse juurutamine: multi-node klastrite kasutamine, mitte virtuaalmasinate;
- dünaamiline skaleerimine: vähendab kulutusi ressurssidele, mis on aktiivsed ainult nõudmisel;
- iseparanemine (Self-healing): automaatne pods'i taastamine (mille kaudu taastuvad ka konteinerid);
- uuenduste ja muudatuste tagasivõtmine ilma seisakuteta: tööriistade, brauserite ja emulaatorite uuendamine ei katkesta praeguste kasutajate tööd
Kuid K8s ei ole siiski hõbekuul. Kõikide eeliste ja piirangute mõistmiseks antud kontekstis (Selenium grid, Selenoid) arutame lühidalt K8s struktuuri. Klaster sisaldab kahte tüüpi node'e: Master Node'id ja Worker Node'id. Master Node'id vastutavad haldamise, juurutamise ja jaotuseotsuste eest. Worker Node'id on need, kus rakendused on käivitatud. Node'id sisaldavad ka konteinerite käitamiskeskkonda. Meie juhul on see Docker, mis vastutab konteineritega seotud operatsioonide eest. Kuid on ka alternatiivseid lahendusi, näiteks. On oluline mõista, et skaleerimine või isekorrekteerimine ei kehti konteinerite kohta otseselt. Seda rakendatakse pod'ide arvu lisamise/vähendamise kaudu, mis omakorda sisaldavad konteinerite (tavaliselt on üks konteiner pod'is, kuid sõltuvalt ülesandest võib neid olla rohkem). Kõrgetasemeline hierarhia koosneb worker node'idest, mille sees on pod'id, mille sees on käivitatud konteinerid.
Skaalafunktsioon on põhifunktsioon, mida saab rakendada nii cluster node-pool'i nodes'itele kui ka node'i pods'idele. On olemas kaks tüüpi skaleerimist, mis kehtivad nii nodes'ite kui ka pods'ite kohta. Esimene tüüp on horisontaalne – skaleerimine toimub nodes'ite/pods'ite arvu suurendamise teel. See tüüp on eelistatavam. Teine tüüp on vastavalt vertikaalne. Skaleerimine toimub nodes'ite/pods'ite suuruste suurendamise kaudu, mitte nende arvu kaudu.
Vaadakem nüüd meie tööriistu eelnevalt mainitud mõtteteemade kontekstis.
Selenium grid
Nagu eelnevalt mainitud, on Selenium grid väga populaarne tööriist ning pole üllatav, et see on konteineriseeritud. Seetõttu ei ole üllatav, et Selenium grid'i saab käivitada K8s-is. Näidet selle kohta, kuidas seda teha, saab leida ametlikust K8s-repositooriumist. Nagu tavaks, lisan viidatud lingid sektsiooni lõppu. Lisaks sellele on praktilises juhendis näidatud, kuidas seda teha Terraformi abil. Samuti on olemas juhised, kuidas skaaleerida pod'e, mis sisaldavad brauserikonteinereid. Kuid automaatne skaleerimine K8s-i kontekstis on endiselt keeruline ülesanne. Kui ma tundsin huvi, ei leidnud ma praktilisi juhendeid ega soovitusi. Pärast mitmeid uuringuid ja eksperimente DevOps meeskonna toel valisime lähenemise konteinerite tõstmiseks, kus on vajalikud brauserid ühes pod'is, mis asub ühes töötaja node'is. Selline lähenemine võimaldab rakendada horisontaalse skaleerimise strateegiat node'ide arvu suurendamisega. Loodan, et tulevikus olukord paraneb ning näeme üha rohkem parimaid lähenemisi ja valmislahendusi, eriti pärast Selenium grid 4 väljaandmist, millel on muudetud sisearhitektuur.
Selenoid:
Praegu on Selenoid'i kasutamine K8s-is suurim pettumus. Nad ei ole ühilduvad. Teoreetiliselt saame seadistada Selenoid-konteineri pod'i sees, kuid kui Selenoid hakkab käivitama konteinerite brausereid, jäävad need ikkagi samasse pod'i. See muudab skaleerimise võimatuks ja seetõttu ei erine Selenoid'i töö klastris milleski sellest, kuidas see toimib virtuaalses masinas. Loo lõpp.
Moon:
Teades seda kitsaskohta Selenoid'iga töötamisel, on arendajad loonud võimsama tööriista nimega Moon. See tööriist oli algselt mõeldud kasutamiseks Kubernetesega ning seetõttu saab ja tuleb kasutada automaatse skaleerimise funktsiooni. Rohkemgi veel, võiksin öelda, et hetkel on see ainus tööriist Seleniumi maailmas, mis pakub kohe algusest peale native K8s klastritoetust (ei, vt järgmist tööriista ). Peamine omadus, mis Moon'il selle toe tagab, on:
Completely stateless. Selenoid salvestab mälu kaudu informatsiooni praegu töötavate brauseriseansside kohta. Kui mingil põhjusel selle protsess kokku kukub, kaovad kõik töötavad seansid. Moonil seevastu pole sisemist olekut ja seda saab replitseerida andmekeskustes. Brauseriseansid jäävad elujõuliseks isegi siis, kui üks või mitu replikat kukuvad.
Nii, Moon on suurepärane lahendus, kuid on üks probleem – see ei ole tasuta. Hind sõltub sessioonide arvust. Tasuta on võimalik käivitada vaid 0-4 sessiooni, mis ei ole eriti kasulik. Kuid alates viiendast sessioonist tuleb igaühe eest maksta 5 $. Olukord võib ettevõtteti erineda, kuid meie puhul on Moon kasutamine mõttetu. Nagu ma juba eespool selgitasin, saame käivitada VMs Selenium Gridiga nõudmisel või suurendada Nodes'i arvu klastris. Ühe pipeline'i kohta käivitame umbes 500 brauserit ja peatame kõik ressursid pärast testide lõppu. Kui me kasutaksime Mooni, peaksime maksma lisaks 500 x 5 = 2500 $ kuus, olenemata sellest, kui sageli me teste käivitame. Ja jälle, ma ei ütle, et 'ärge kasutage Mooni'. Teie ülesannete puhul võib see olla asendamatu lahendus, näiteks juhul, kui teil on organisatsioonis palju projekte/tiime ja vajate suurt jagatud klastrit kõigi jaoks. Nagu alati, jätan allapoole lingi ja soovitan teha kõik vajalikud arvutused teie ülesande kontekstis.
Callisto: (Tähelepanu! Seda ei leidunud originaalis ja see on ainult vene tõlkes.)
Nagu ma ütlesin, on Selenium väga populaarne tööriist ja IT-sektor areneb väga kiiresti. Samal ajal, kui ma tõlkega tegelesin, ilmus võrku uus paljutõotav tööriist Callisto (tere, Cypress ja teised Seleniumi konkurendid). See töötab natiivsete K8s-iga ja võimaldab Selenoid-konteinereid käitada pods, jaotatuna Node'ide vahel. Kõik töötab kohe välja kastist, sealhulgas automaatne skaleerimine. Fantastiline, kuid seda tuleb testida. Olen juba suutnud selle tööriista käivitada ja teha mõned eksperimendid. Kuid järeldusi on vara teha, pärast tulemuste saamist pikas perspektiivis plaanin kindlasti kirjutada ülevaate järgnevates artiklites. Praegu jätan siia vaid lingid iseseisvaks uurimiseks.
Praeguse infrastruktuuri seisundi illustreerimine
Uurimiseks mõeldud lingid
Uurimiseks mõeldud lingid
Sarnased töötajad
7. Infrastruktuur kui kood (IaC)
Tehnoloogia lühikirjeldus
Ja ja oleme jõudnud viimase jao juurde. Üldiselt ei kuulu see tehnoloogia ja sellega seotud ülesanded automaatika inseneride vastutusalasse. Sellel on omad põhjused. Esiteks, paljudes organisatsioonides on infrastruktuuriküsimused DevOps osakonna kontrolli all ja arendusmeeskond ei muretse eriti selle pärast, kuidas pipeline töötab ja kuidas kõike, mis sellega seotud, toetada. Teiseks, olgem ausad, praktikad "Infrastruktuur kui kood (IaC)" ei ole veel paljudes ettevõtetes rakendatud. Kuid kindlasti on see saanud populaarseks suunaks ja on oluline püüda olla seotud sellega seotud protsesside, lähenemiste ja tööriistadega. Või vähemalt olla kursis arengutega.
Alustame motivatsiooni arutamisega, miks selline lähenemine on vajalik. Oleme juba arutanud, et GitlabCI testide käivitamiseks vajame vähemalt ressursse Gitlab Runner’i käivitamiseks. Brauserite/emulaatorite konteinerite käivitamiseks peame reserveerima VM või klastrit. Lisaks testimisressurssidele on meil vaja märkimisväärset hulka võimekust, et toetada arenduse, staging’i ja tootmisprotsesside keskkondi, mis hõlmavad ka andmebaase, automaatseid ajakavu, võrgukonfiguratsioone, koormuse tasakaalustajat, kasutajate õigusi jne. Peamine probleem seisneb kõigi nende elementide toetamiseks vajalikes pingutustes. On mitmeid viise, kuidas saame muudatusi teha ja uuendusi rakendada. Näiteks GCP kontekstis saame kasutada brauseri kasutajaliidest ja täita kõik toimingud nuppude klikkimise kaudu. Alternatiivne meetod võib olla API-kutsede kasutamine pilveelementidega suhtlemiseks või gcloud käsureautomi kasutamine vajalike toimingute teostamiseks. Kuid tõeliselt suure hulga erinevate elementide ja infrastruktuuri komponentidega muutub kõikide toimingute käsitsi tegemine keeruliseks või isegi võimatuks. Veelgi enam, kõik need käsitsi teostatavad toimingud on kontrollimata. Me ei saa neid enne täitmist üle vaadata, versioonihaldussüsteemi kasutada ega kiiresti tagasi kerida muudatusi, mis viisid probleemini. Selliste probleemide lahendamiseks on insenerid loonud ja loovad automaatseid bash/shell skripte, mis ei ole palju parem eelmistest meetoditest, kuna neid pole eriti lihtne kiiresti lugeda, mõista, hallata ja protseduurilises stiilis muuta.
Selles artiklis ja praktilises juhendis kasutan kahte tööriista, mis kuuluvad IaC praktikasse. Need on Terraform ja Ansible. Mõned arvavad, et ei ole mõtet neid samal ajal kasutada, kuna nende funktsioonid on sarnased ja nad on omavahel asendatavad. Kuid asi on selles, et algselt on nende eesmärgid täiesti erinevad. Ja tõsiasi, et need tööriistad peavad üksteist täiendama, kinnitati ühises esitluses, mille tegid HashiCorpi ja RedHati esindavad arendajad. Kontseptuaalne erinevus seisneb selles, et Terraform on serverite haldamiseks mõeldud provisioningu tööriist. Ansible aga on konfigureerimise haldamise tööriist, mille ülesanne on nendele serveritele tarkvara installimine, seadistamine ja haldamine.
Teiste tööriistade peamine eripära on koodi kirjutamise stiil. Erinevalt bash'ist ja Ansible'ist kasutab Terraform deklaratiivset lähenemist, mis põhineb soovitud lõppseisundi kirjelduse loomisel. Näiteks kui plaanime luua 10 virtuaalmasinat ja rakendada muudatusi läbi Terraformi, siis saame 10 virtuaalmasinat. Kui skripti uuesti käivitada, ei juhtu midagi, kuna meil on juba 10 virtuaalmasinat ja Terraform teab sellest, kuna hoiab infrastruktuuri praegust olekut state-failis. Ansible aga kasutab protseduurilist lähenemist ja kui palume tal luua 10 virtuaalmasinat, siis esimesel käivitamisel saame 10 virtuaalmasinat, just nagu Terraformiga. Kuid pärast korduvat käivitamist on meil juba 20 virtuaalmasinat. See ongi oluline erinevus. Protseduurilises stiilis ei hoia me praegust olekut ja kirjeldame lihtsalt sammude järjekorda, mis tuleb täita. Loomulikult saame käsitleda erinevaid olukordi, lisada kontrollid ressursside olemasolu ja praeguse oleku kohta, kuid pole mõtet raisata meie aega ja pingutada selle loogika kontrollimisel. Lisaks suurendab see riski eksida.
Kokkuvõttes võib öelda, et serverite provisionimiseks on kõige sobivam tööriist Terraform ja deklaratiivne süntaks. Konfiguratsioonide haldamise ülesanded on aga parem delegeerida Ansible'ile. Tutvume nüüd automaatika kontekstis kasutamise näidetega.
Väärtus automaatimise infrastruktuurile
Siin on oluline mõista, et testimise automatiseerimise infrastruktuur peab olema osa ettevõtte kogu infrastruktuurist. See tähendab, et kõik IaC-praktikad peaksid olema rakendatud globaalselt kogu organisatsiooni ressurssidele. Kes selle eest vastutab, sõltub teie protsessidest. DevOps meeskond on selles osas kogenum, nad näevad kogu toimuvat pilti. Siiski on QA-insenerid rohkem kaasatud automatiseerimise ehitamisse ja pipeline'i struktuuri, mis võimaldab neil paremini näha vajalikke muudatusi ja täiustamise võimalusi. Parim lahendus on koostöö, teadmiste ja ideede jagamine soovitud tulemuse saavutamiseks.
Tulen välja mõned näited Terraformi ja Ansible'i kasutamisest testimise automatiseerimise kontekstis ning tööriistadest, millest oleme varem rääkinud:
1. Kirjeldada Terraformi kaudu vajalikud omadused ja parameetrid VM-idele ja klastritele.
2. Installida Ansible'i abil testimiseks vajalikud tööriistad: docker, Selenoid, Selenium Grid ning laadida alla vajalikud brauserite/emulaatorite versioonid.
3. Kirjeldada Terraformi kaudu VM-i omadused, kus töötab GitLab Runner.
4. Installida Ansible'i abil GitLab Runner ja vajalikud seotud tööriistad, seada konfiguratsioonid ja seaded.
Praeguse infrastruktuuri seisundi illustreerimine
Uurimislingid:
Sarnased töötajad
Teeme kokkuvõtte!
Samm
Tehnoloogia
Tööriistad
Väärtus automaatimise infrastruktuurile
1
Kohalik käitamine
Node.js, Selenium, Appium
- Kõige populaarsemad tööriistad veebilehtede ja mobiilsete rakenduste jaoks
- Toetab mitmeid keeli ja platvorme (sealhulgas Node.js)
2
Versioonihaldussüsteemid
Git
- Sarnased eelised arenduskoodeksiga
3
Konteineriseerimine
Docker, Selenium grid, Selenoid (Web, Android)
- Paralleelsed testide käivitamised
- Isoleeritud keskkonnad
- Lihtne ja paindlik versioonide uuendamine
- Dünaamiline mittekasutatavate ressursside peatamine
- Lihtne seadistada
4
CI / CD
Gitlab CI
- Testid on osa konveierist
- Kiire tagasiside
- Töötajatele / meeskonnale nähtavus
5
Pilveteenused
Google Cloud Platform
- Nõudmisel ressursid (maksame ainult siis, kui need on vajalikud)
- Lihtne hallata ja värskendada
- Kõigi ressursside nähtavus ja kontroll
6
Orkestreerimine
Kubernetes
Konteinerite kontekstis, kus veebibrauserid/emulaatorid on podides:
- Suurendamine / automaatne suurendamine
- Iseseisvalt taastumine
- Uuendused ja tagasivõtmised katkestusteta
7
Infrastruktuur kui kood (IaC)
Terraform, Ansible
- Sarnased eelised arendustegevuse infrastruktuurile
- Kõik koodiversioonimise eelised
- Lihtne muudatusi teha ja hooldada
- Täielikult automatiseeritud
Mõttekaardi diagrammid: infrastruktuuri evolutsioon
step1: Kohalik
step2: VCS
step3: Konteinerimine
step4: CI/CD
step5: Pilve platvormid
step6: Orkestreerimine
step7: IaC
Mis edasi?
Nii et see oli artikli lõpp. Kuid lõpuks sooviksin teiega teatud kokkuleppeid kehtestada.
Teie poolt
Nagu alguses mainitud, sooviksin, et artikkel oleks praktiliselt kasulik ja aitaks teid rakendada omandatud teadmisi reaalses töös. Lisa veel kord.
Kuid isegi pärast seda ärge peatuge, harjutage, uurige asjakohaseid linke ja raamatuid, uurige, kuidas see teie ettevõttes töötab, leidke kohti, kus midagi saaks parandada ja osalege selles. Edu!
Minu poolt
Pealkirjast nähtub, et see oli ainult esimene osa. Kuigi see osutus üsna mahukaks, ei ole siin siiski olulisi teemasid käsitletud. Teises osas plaanin käsitleda automatiseerimise infrastruktuuri IOS-i kontekstis. Apple’i piirangute tõttu, mis seavad IOS emulatorite käitamise ainult macOS süsteemidesse, on meie lahenduste komplekt kitsendatud. Näiteks ei saa me kasutada Dockerit emulaatori käitamiseks või avalikke pilvi virtuaalmasinate käitamiseks. Kuid see ei tähenda, et pole olemas muid alternatiive. Püüan hoida teid kursis uuenduslike lahenduste ja kaasaegsete tööriistadega!
Samuti ei maininud ma üsna suurte teemadega seonduvat, mis puudutab jälgimist. Kolmandas osas kavatsen vaadata üle kõige populaarsed infrastruktuuri jälgimise tööriistad ning milliseid andmeid ja mõõdikuid tuleks arvesse võtta.
Ja lõpetuseks. Tulevikus plaanin välja anda videokursuse testimisstrateegiate ja populaarsete tööriistade loomise kohta. Praegu on internetis palju DevOps kursusi ja loenguid, kuid kõik materjalid käsitlevad arendust, mitte testimise automatiseerimist. Siin vajaksin väga tagasisidet, kas selline kursus oleks testijate ja automatiseerijate kogukonnale huvitav ja väärtuslik. Ette tänades!
Allikas: habr.com
