Osa 1: Veeb / Android
Märkus: see artikkel on originaali vene keelde tõlge Kuid kõik illustratsioonid, lingid, tsitaadid ja terminid on säilitatud originaalkeeles, et vältida tähenduse moonutamist vene keelde tõlkimisel. Soovin teile meeldivat õppimist!
Praegu on DevOps eriala üks nõutumaid IT-tööstuses. Kui avate populaarsed tööotsingu saidid ja seate palga filtrid, näete, et DevOpsiga seotud töökuulutused on nimekirja alguses. Kuid on oluline mõista, et see kehtib peamiselt 'vanem' positsiooni kohta, mis tähendab, et kandidaadil on kõrge oskuste tase, teadmised tehnoloogiatest ja tööriistadest. Samuti kaasneb sellega kõrge vastutustunne, mis on seotud tootmise katkematu töö tagamisega. Kuid me oleme hakanud unustama, mis on DevOps. Alguses ei olnud see mingi konkreetne inimene või osakond. Kui otsida selle termini definitsioone, leiame palju ilusaid ja õigeid nimisõnu, nagu metodoloogia, praktikad, kultuurifilosoofia, kontseptsioonide kogum jne.
Minu eriala on testimise automatiseerimise insener (QA automation engineer), kuid arvan, et see ei peaks olema seotud ainult automaatsete testide kirjutamise või testimise raamistiku arendamisega. 2020. aastal on automatiseerimise infrastruktuuri teadmised samuti vajalikud. See võimaldab iseseisvalt korraldada automatiseerimisprotsessi, alates testide käivitamisest kuni tulemuste edastamiseni kõigile huvitatud osalistele vastavalt seatud eesmärkidele. Seetõttu on DevOps'i oskused selle töö teostamiseks kohustuslikud. Ja see kõik on hea, kuid kahjuks on probleem (spoiler: see artikkel püüab seda probleemi lihtsustada). See, DevOps is complicated. It's obvious, as companies won't pay a lot for something that's easy to do... In the world of DevOps, there are a lot of tools, terms, and practices to master. This is especially challenging at the beginning of a career and depends on accumulated technical experience.
Allikas:
We will probably conclude the introductory part here and focus on the goal of this article.
What this article is about
In this article, I will share my experience in building an automation testing infrastructure. There are many sources of information online about various tools and how to use them, but I would like to discuss them exclusively in the context of automation. I believe many automation engineers are familiar with the situation where the tests developed are only run by themselves, and no one else cares about their maintenance. As a result, the tests become outdated, requiring time to update them. Again, at the beginning of a career, this can be quite a challenging task: to wisely determine which tools should help solve this problem, how to choose, configure, and maintain them. Some testers turn to DevOps (people) for help, and to be honest, this approach works. In many cases, it may be the only option, as we lack visibility into all dependencies. But, as we know, DevOps are very busy folks, thinking about the entire company's infrastructure, deployment, monitoring, microservices, and other similar tasks depending on the organization/team. As is often the case, automation is not a priority. In such cases, we should try to do everything possible from our side, from start to finish. This will reduce dependencies, speed up workflows, enhance our skills, and allow us to see a broader picture of what is happening.
Artiklis tutvustatakse kõige nõudlikumaid ja populaarsemaid tööriistu ning näidatakse, kuidas neid kasutada samm-sammult automatiseerimise infrastruktuuri ülesehitamiseks. Iga grupp on esindatud tööriistadega, mida on katsetatud isikliku kogemuse põhjal. Kuid see ei tähenda, et te peaksite kasutama sama. Tööriistad ise ei ole olulised, need tulevad ja kaovad. Meie inseneriülesanne on mõista põhialuseid: miks on meil vajalik see tööriistade grupp ja milliseid tööülesandeid saame nende abil lahendada. Seetõttu jätan iga sektsiooni lõpus viidatud sarnastele tööriistadele, mida teie organisatsioonis võib-olla kasutatakse.
Mida artiklis ei ole
Kordan, et artikkel ei räägi konkreetsetest tööriistadest, seega ei tule siia koodilõike dokumentatsioonist ja konkreetsete käskude kirjeldusi. Kuid iga sektsiooni lõpus jätan viidatud põhjalikule uurimisele.
See on tehtud põhjusel, et:
- see materjal on väga kergesti leitav erinevates allikates (dokumendid, raamatud, videokursused);
- kui hakkame süvenema, siis tuleb kirjutada 10, 20, 30 osa sellest artiklist (samal ajal on plaanis 2-3);
- ma lihtsalt ei soovi teie aega raisata, kuna võib-olla soovite kasutada teisi tööriistu samade eesmärkide saavutamiseks.
Praktika
Sooviksin väga, et see materjal oleks kasulik igale lugejale, mitte lihtsalt loetuks ja unustatuks. Igas õppimises on praktika väga oluline komponent. Selleks olen ette valmistanud. Teid ootab ka kodutöö, et olla kindel, et te ei kopeerinud lihtsalt käsurea käskinud ridu mõtlemata
Plaani
Samm
Tehnoloogia
Tööriistad
1
Kohalik käivitamine (valmista veeb / android demo testid ja käita neid kohalikult)
Node.js, Selenium, Appium
2
Versioonihaldussüsteemid
Git
3
Konteineriseerimine
Docker, Selenium grid, Selenoid (Veeb, Android)
4
CI / CD
Gitlab CI
5
Pilveplatvormid
Google Cloud Platform
6
Orkestreerimine
Kubernetes
7
Infrastruktuur koodina (IaC)
Terraform, Ansible
Iga sektsiooni struktuur
Et säilitada jutustust visuaalsena, on iga sektsioon kirjeldatud järgmise plaani järgi:
- tehnoloogia lühikirjeldus,
- väärtus automaatimise infrastruktuurile,
- ilustratsioon praegusest infrastruktuuri seisundist,
- viidatud õppimiseks,
- sarnased tööriistad.
1. Kohalik testide käitamine
Tehnoloogia lühikirjeldus
See on vaid ettevalmistav samm, et käivitada demonstreerimistestid kohapeal ja kontrollida, et need õnnestuvad. Praktikas kasutatakse Node.js, kuid programmitöö keel ja platvorm ei ole olulised; saate kasutada neid, mida teie ettevõttes kasutatakse.
Automatiseerimisvahenditena soovitan kasutada Selenium WebDriveri veebiplatvormide jaoks ja Appiumit Android-platvormide jaoks, kuna järgmistes sammudes kasutame Docker-pilte, mis on optimeeritud nende konkreetsete tööriistadega töötamiseks. Veelgi enam, viidates töökuulutuste nõuetele, on need tööriistad turul kõige nõutumad.
Nagu olete tähele pannud, käsitleme ainult veeb- ja Android-teste. Kahjuks on iOS täiesti teine lugu (tänu Apple'ile). Plaanin demonstreerida lahendusi ja praktikad, mis on seotud iOS-iga, järgmistes osades.
Väärtus automatiseerimisinfrastruktuurile
Infrastruktuuri vaatenurgast ei too kohaliku käivitamise tagamine mingit väärtust. Te ainult kontrollite, kas testid töötavad kohalikul masinal kohalikes brauserites ja simulaatorites. Kuid see on igal juhul vajalik lähtepunkt.
Praeguse infrastruktuuri oleku illustreerimine
Õppimise lingid
Sarnased tööriistad
- igany programmikeel, mis teile meeldib, koos Seleniumi/Appiumiga - testide jaoks;
- mistahes testid;
- iga testijooksja.
2. Versioonihaldussüsteemid (Git)
Tehnoloogia lühikirjeldus
Ei ole kellelegi üllatuseks, kui ütlen, et versioonihaldussüsteem on äärmiselt oluline osa töötamisest nii meeskonnas kui ka iseseisvalt. Erinevaid allikaid arvestades võime kindlalt öelda, et Git on kõige populaarsem esindaja. Versioonihaldussüsteem pakub mitmeid eeliseid, nagu koodivahetus, versioonide salvestamine, varasemate harude taastamine, projekti ajaloo jälgimine ja varukoopiad. Me ei hakka igat punkti üksikasjalikult arutama, kuna olen kindel, et olete sellega hästi kursis ja kasutate seda igapäevases töös. Kuid kui te pole, siis soovitan selle artikli lugemise peatada ja see auk kiiresti täita.
Väärtus automatiseerimisinfrastruktuurile
Ja siin võite esitada põhjendatud küsimuse: „Miks ta räägib meile Git'ist? Kõik teavad ja kasutavad seda nii arendus- kui ka autotestimise koodi jaoks.” Te oleksite täiesti õiged, kuid selles artiklis räägime me infrastruktuurist ja see lõik mängib ülevaate rolli peatükis 7: „Infrastruktuur kui kood (IaC)”. Meie jaoks tähendab see, et kogu infrastruktuur, sealhulgas testimis-, kirjeldatakse koodina, seega saame sellele rakendada ka versioonihaldussüsteeme ja saavutada sarnaseid eeliseid nagu arendus- ja automatiseerimiskoodile.
Käsitleme IaC-d üksikasjalikumalt sammus 7, kuid juba praegu saab alustada Git'i kasutamist kohalikult, luues kohaliku hoidla. Üldine pilt laieneb, kui lisame infrastruktuurile kaughoidla.
Praeguse infrastruktuuri oleku illustreerimine
Õppimise lingid
Sarnased tööriistad
3. Konteineriseerimine (Docker)
Tehnoloogia lühikirjeldus
Konteineriseerimise mängureeglite muutmise demonstreerimiseks teeme väikese ajarännaku mitme aastakümne taha. Tookord ostsid inimesed ja kasutasid serveri masinaid rakenduste käitamiseks. Kuid enamikul juhtudel ei olnud vajalikud ressursid rakenduse käitamiseks eelnevalt teada. Selle tulemusena kulutasid ettevõtted raha kallite võimsate serverite soetamiseks, kuid osa neist ressurssidest jäi täielikult kasutamata.
Järgmine arenguetapp olid virtuaalsed masinad (VM), mis lahendasid rahalise kulu probleemid kasutamata ressursside tõttu. See tehnoloogia võimaldas alustada rakenduste käitamist üksteisest sõltumatult ühe serveri sees, eraldades täielikult isoleeritud ruumi. Kuid kahjuks on igal tehnoloogial oma puudused. VM käitamine nõuab täielikku operatsioonisüsteemi, mis kasutab CPU-d, RAM-i, salvestust, ja OS-i, sõltuvalt peab arvestama litsentsikulu. Need tegurid mõjutavad laadimise kiirus ja muudavad üleviimise keerulisemaks.
Ja nüüd oleme jõudnud konteineriseerimise juurde. Taas lahendas see tehnoloogia eelneva probleemi, kuna konteinerid ei kasuta täisoperatsioonisüsteemi, mis vabastab palju ressursse ja pakub kiiret ja paindlikku lahendust üleviimiseks.
Muidugi, konteineritehnoloogia ei ole midagi uut ja seda tutvustati esmakordselt 70-ndate lõpus. Sel ajal viidi läbi palju teadusuuringuid, arenguid ja katseid. Kuid just Docker kohandas seda tehnoloogiat ja tegi selle massidele kergesti ligipääsetavaks. Tänapäeval, kui räägime konteineritest, mõtleme enamasti Dockerile. Kui räägime Docker-konteineritest, mõtleme Linuxi konteineritele. Saame kasutada Windowsi ja macOSi süsteeme konteinerite käitamiseks, kuid on oluline mõista, et sel juhul tekib täiendav kiht. Näiteks käivitab Docker Macis vaikselt konteinerid kerge Linuxi VM-i sees. Tagasi sellele teemele tuleme, kui arutame Androidi emulaatorite käitamist konteinerite sees, kuna siia tekib üks väga oluline nüanss, mida tuleb põhjalikumalt uurida.
Väärtus automatiseerimisinfrastruktuurile
Oleme välja selgitanud, et konteineriseerimine ja Docker on suured. Vaatame seda automatiseerimise kontekstis, sest iga tööriist või tehnoloogia peaks lahendama mingi probleemi. Märkigem esile ilmsed automatiseerimise testimise probleemid UI-testide kontekstis:
- suur hulk sõltuvusi Seleniumi ja eriti Appiumi installimisel;
- brauserite, simulaatorite ja draiverite versioonide vahelised ühilduvusprobleemid;
- puudub isoleeritud ruum brauserite/simulaatorite jaoks, mis on eriti kriitiline paralleelse käitamise puhul;
- raske on hallata ja toetada, kui tuleb käitada 10, 50, 100 või isegi 1000 brauserit korraga.
Kuid kuna Selenium on kõige populaarsem automatiseerimistööriist ja Docker on kõige populaarsem konteenerite loomise tööriist, siis ei tohiks kedagi üllatada, et keegi on proovinud neid ühendada, et saada võimas tööriist eelpoolmainitud probleemide lahendamiseks. Vaatame selliseid lahendusi lähemalt.
Selenium grid dockeris
See tööriist on maailma populaarseim Selenium, et hallata mitut brauserit mitmes masinas keskuselt. Käivitamiseks on vajalik registreerida vähemalt 2 osa: Hub ja Node(d). Hub on keskne sõlm, mis saab kõik testidest tulevad päringud ja jaotab need vastavatesse Node’desse. Iga Node jaoks saame seadistada konkreetse konfiguratsiooni, näiteks määrates vajaliku brauseri ja selle versiooni. Kuid me peame endiselt ise hoolitsema brauserite ühilduvate draiverite eest ja installima need vajalikele Node’idele. Sellepärast ei kasutata Selenium grid’i puhtal kujul, välja arvatud juhtudel, kui peame töötama brauseritega, mida ei saa installida Linuxi opsüsteemile. Kõigil teistel juhtudel on paindlikum ja õigem lahendus kasutada Docker-pilte Selenium grid Hub’i ja Node’ide käivitamiseks. See lähenemine lihtsustab oluliselt sõlmede haldamist, kuna saame valida sobiva pildi koos juba installitud ühilduvate brauserite ja draiveritega.
Hoolimata negatiivsetest arvustustest stabiilsuse osas, eriti kui käivitada suurt hulka Node’e paralleelselt, jääb Selenium grid endiselt populaarseimaks tööriistaks Selenium-testide paralleelseks käivitamiseks. Oluline on märkida, et avatud lähtekoodiga keskkonnas ilmuvad pidevalt erinevad täiustused ja modifikatsioonid sellele tööriistale, mis aitavad lahendada erinevaid kitsaskohti.
Selenoid for Web
See tööriist on läbimurre Seleniumi maailmas, kuna see töötab kohe kastist välja ja on teinud paljude automatiseerimise inseneride elu oluliselt lihtsamaks. Esiteks, see ei ole järjekordne Selenium Grid'i modifikatsioon. Selle asemel on arendajad loonud täiesti uue versiooni Selenium Hub'ist Go keeles, mis koos kergete Docker-piltidega erinevate brauserite jaoks on andnud hoogu automatiseerimise testimise arengule. Lisaks peame Selenium Grid'i puhul määratlema kõik vajalikud brauserid ja nende versioonid eelnevalt, mis ei ole probleem, kui töö toimub 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 eelnevalt vajalikud pildid brauseritega alla laadida ja värskendada Selenoid'i interakteeruvat konfiguratsioonifaili. Pärast seda, kui Selenoid saab testidelt päringu, käivitab see automaatselt vajaliku konteineri vajaliku brauseriga. Kui test on lõppenud, lõpetab Selenoid konteineri, vabastades seeläbi ressursid järgnevateks päringuteks. See lähenemine kõrvaldab täielikult tuntud 'sõlmdegratsiooni' probleemi, millega me sageli Selenium Grid'is silmitsi seisame.
Kuid kahjuks ei ole Selenoid ikka veel hõbepadrun. Me saime funktsiooni 'brauser nõudmisel', kuid funktsioon 'ressursid nõudmisel' ei ole endiselt saadaval. Selenoid'i kasutamiseks peame selle füüsilisel riistvaral või virtuaalmasinas kasutusele võtma, mis tähendab, et me peame eelnevalt teadma, kui palju ressursse tuleb eraldada. Ma arvan, et see ei ole probleem väikeste projektide puhul, mis käivitavad 10, 20 või isegi 30 brauserit korraga. Aga mis siis, kui me vajame 100, 500, 1000 ja rohkem? Pole mõtet pidevalt toetada ja maksta nii suure koguse ressursside eest. Artikli osades 5 ja 6 arutame lahendusi, mis võimaldavad skaleerida, seeläbi oluliselt vähendades ettevõtte kulusid.
Selenoid Androidile
Pärast Selenoid'i edu veebiautomatiseerimise tööriistana soovisid inimesed midagi sarnast Androidi jaoks. Ja see on juhtunud – Selenoid on välja antud Androidi toe ka. Üksikasjalikult kasutajapoolsetes punktides tööpõhimõte sarnaneb veebiautomatiseerimisega. Ainus erinevus seisneb selles, et Selenoid käivitab Androidi emulaatoritega konteinerid, mitte brauseritega. Minu arvates on see hetkel kõige võimsam tasuta tööriist Androidi testide paralleelseks käitamiseks.
Mulle ei meeldi rääkida selle tööriista negatiivsetest külgedest, kuna see meeldib mulle väga. Siiski on siin kohal samu puudusi, mis puudutavad ka veebiautomatiseerimist seoses skaleerimisega. Lisaks tuleb rääkida veel ühest piirangust, mis võib osutuda ootamatuks, kui seadistame tööriista esmakordselt. Androidi piltide käitamiseks on meil vaja füüsilist masinat või VM-i koos pesas virtualiseerimise toega. Praktilises juhendis demonstreerin, kuidas seda Linuxi VM-is aktiveerida. Kuid kui olete macOS kasutaja ja soovite Selenoid'i kohalikult käitada, siis Androidi teste käitada ei saa. Kuid alati võite kohaliku Linuxi VM-i käivitada koos seadistatud 'nested virtualisation' ja käitada Selenoid'i seal.
Praeguse infrastruktuuri oleku illustreerimine
Käesolevas artiklis lisame 2 tööriista, et illustreerida infrastruktuuri. Need on Selenium grid veebitestide jaoks ja Selenoid Androidi testide jaoks. GitHubi juhendis näitan ka, kuidas kasutada Selenoid'i veebitestide käitamiseks.
Õppimise lingid
Sarnased tööriistad
- On olemas teisi konteinerimise tööriistu, kuid Docker on kõige populaarsem. Kui soovite proovida midagi muud, pidage meeles, et need tööriistad, mida oleme vaadanud Seleniumi testide paralleelseks käitamiseks, ei tööta otse välja.
- Nagu juba öeldud, on olemas palju Selenium grid'i modifikatsioone, näiteks.
4. CI / CD
Tehnoloogia lühikirjeldus
Jätkuva integreerimine on arenduses üsna populaarne ja seisab koos versioonihaldesüsteemidega. Kuigi see on tõsi, tunnen ma, et terminoloogias on teatav segadus. Selles lõigus soovin ma kirjeldada kolme selle tehnoloogia modifikatsiooni oma vaatepunktist. Internetis on palju artikleid erinevate tõlgendustega ja täiesti normaalne on, kui teie arvamus erineb. Peamine on, et te oleksite oma kolleegidega samal lainel.
Nii et on olemas kolm terminit: CI — Continuous Integration (jätkuv integreerimine), CD — Continuous Delivery (jätkuv kohaletoimetamine) ja taas CD — Continuous Deployment (jätkuv juurutamine). (Edaspidi kasutan neid termineid ingliskeelsena). Iga modifikatsioon lisab teie arendusprotsessile mõned täiendavad etapid. Kuid sõna continuous on kõige olulisem. Selle konteksti juures mõistame midagi, mis toimub algusest lõpuni, katkestusteta või käsitsi sekkumiseta. Vaatame CI & CD ja CD-d antud kontekstis.
- Continuous Integration – see on arengu algfaas. Pärast uue koodi saatmist serverisse ootame kiiresti tagasisidet, et meie muudatused on head. Tavaliselt hõlmab CI staatilise koodi analüüsi tööriistade ja üksuste/ sisemiste API testide käivitamist. See võimaldab saada teavet meie koodi kohta juba mõne sekundi/ minuti pärast.
- Continuous Delivery on arenenum faas, mille käigus käivitame integreerimis-/UI-testid. Kuid sel hetkel ei saa me tulemusi nii kiiresti kui CI puhul. Esiteks võtavad need testid rohkem aega läbimiseks. Teiseks peame enne käivitamist oma muudatused test-/staging- keskkonnas juurutama. Veelgi enam, kui räägime mobiiliarendusest, lisandub meie rakenduse koostamise etapp.
- Continuous Deployment tähendab, et me vabastame automaatselt (release) meie muudatused tootmisse, kui kõik vastuvõtutestid on eelnevalt läbitud. Lisaks saab vabastamise etapist lähtudes seadistada erinevaid etappe, nagu näiteks smoke-testide käivitamine tootmises ja huvipakkuvate mõõdikute kogumine. Continuous Deployment on võimalik ainult juhul, kui automatiseeritud testide katvus on hea. Kui on vajalikud mingid käsitsi sekkumised, sealhulgas testimine, siis see pole enam Continuous (katkestusteta). Siis saame rääkida, et meie konveier vastab ainult Continuous Delivery praktikale.
Väärtus automatiseerimisinfrastruktuurile
Selles osas pean täpsustama, et kui räägime end-to-end UI-testidest, siis see tähendab, et peame meie muudatused ja seotud teenused testkeskkondadesse juurutama. Continuous Integration protsess ei rakendu antud ülesande jaoks ja peame hoolitsema vähemalt Continuous Delivery praktikate rakendamise eest. Continuous Deployment omab mõtet ka UI-testide kontekstis, kui plaanime neid käivitada tootmises.
Ja enne kui vaatame arhitektuuri muutmise illustratsiooni, tahan öelda paar sõna GitLab CI-st. Erinevalt teistest CI/CD tööriistadest, pakub GitLab kaugrepo ja palju muid lisafunktsioone. Seega on GitLab rohkem kui CI. See sisaldab kastist välja lähtekoodi haldamist, Agile juhtimist, CI/CD pipelines, logimise tööriistu ja mõõdikute kogumist. GitLabi arhitektuur koosneb GitLab CI/CD-st ja GitLab Runner-ist. Toome välja lühikese kirjelduse ametlikult lehelt:
Gitlab CI/CD on veebi rakendus koos API-ga, mis salvestab oma oleku andmebaasis, haldab projekte/ehitusi ja pakub kasutajaliidest. GitLab Runner on rakendus, mis töötleb ehitusi. Seda saab installida eraldi ja see töötab GitLab CI/CD-ga läbi API. Testide käitamiseks vajate nii GitLab instance'd kui ka Runner'it.
Praeguse infrastruktuuri oleku illustreerimine
Õppimise lingid
Sarnased tööriistad
- Ja palju teisi
5. Pilvplatvormid
Tehnoloogia lühikirjeldus
Selles jaotises arutame populaarset trendi, mida nimetatakse 'avalikeks pilvedeks'. Vaatamata tohutule kasule, mida toovad ülaltoodud virtualiseerimise ja konteinerimise tehnoloogiad, on meil endiselt vajalikke arvutusressursse. Ettevõtted ostavad kallid serverid või rentivad andmekeskusi, kuid sellisel juhul tuleb teha kalkulatsioone (mõnikord ebarealistlikke), kui palju ressursse me vajame, kas me kasutame neid 24/7 ja millistel eesmärkidel. Näiteks, tootmiseks on vajalik ööpäevaringne server, kuid kas vajame sarnaseid ressursse testimiseks väljaspool tööaega? See sõltub ka teostatava testimise tüübist. Näideteks võivad olla koormus-/stressitestsid, mida plaanime läbi viia väljaspool tööaega, et saada tulemusi järgmiseks päevaks. Kuid kindlasti ei ole ööpäevaringne serverite kättesaadavus vajalik end-to-end automaatsete testide jaoks ning eriti käsitsi testimise keskkondade jaoks. Taoliste olukordade jaoks oleks hea saada piisavalt ressursse vajadusel, kasutada neid ja lõpetada maksmine, kui need enam ei ole vajalikud. Veelgi enam, oleks imeline saada neid hetkega, tehes paar hiireklõpsu või käivitades paar skripti. Just selleks kasutatakse avalikke pilvi. Vaadakem määratlust:
„Avalik pilv määratletakse kui arvutusressursid, mida pakuvad kolmandate osapoolte teenusepakkujad üle avaliku Interneti, muutes need kergesti kättesaadavaks kõigile, kes soovivad neid kasutada või osta. Need võivad olla tasuta või müüa nõudmise alusel, võimaldades klientidel maksta ainult kulutatud CPU tsüklite, salvestusruumi või ribalaiuse eest.”
Levinud arvamus on, et avalikud pilved on kallid. Kuid nende peamine idee on ettevõtte kulude vähendamine. Nagu eelnevalt mainitud, võimaldavad avalikud pilved saada ressursse vajadusel ja maksta ainult nende kasutamise aja eest. Samuti unustame vahel, et töötajad saavad palka, ja spetsialistid on samuti kallid ressursid. Tuleb meeles pidada, et avalikud pilved kergendavad infrastruktuuri hooldust, mis võimaldab inseneridel keskenduda olulisematele ülesannetele.
Väärtus automatiseerimisinfrastruktuurile
Millised konkreetsed ressursid on meil vaja end-to-end UI-testide jaoks? Peamiselt virtuaalmasinad või klastrid (räägime Kubernetesest järgmises jaotises), et käivitada brauserid ja emulaatorid. Mida rohkem brausereid ja emulaatoreid soovime korraga käivitada, seda rohkem CPU-d ja mälu on vajalik ning seda rohkem tuleb meil selle eest maksta. Seega võimaldavad avalikud pilved automaatikate testimise kontekstis meil nõudmise järgi käivitada suurt arvu (100, 200, 1000 ...) brausereid/emulaatoreid, saada testimistulemusi võimalikult kiiresti ja lõpetada maksmine selliste ülemääraste ressursside eest.
Kõige populaarsemad pilveteenuse pakkujad on Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Praktilises juhendis on toodud GCP kasutamise näited, kuid üldiselt ei oma tähtsust, mida täpselt automaatika ülesannete jaoks kasutate. Kõik need pakuvad umbes sarnast funktsionaalsust. Tüüpiliselt keskendub teenuse pakkuja valiku juhend kogu ettevõtte infrastruktuurile ja äriotsustele, mis jäävad selle artikli raamidest väljapoole. Automaatikainseneridele võib olla huvitavam võrrelda pilveteenuse pakkujate kasutust konkreetsete testimise eesmärkide jaoks mõeldud pilveplatvormidega, nagu Sauce Labs, BrowserStack, BitBar jne. Nii teeme ka! Minu arvates on Sauce Labs kõige tuntum pilvtestimise farm, seega valisin ma selle võrdlemiseks.
GCP vs Sauce Labs automaatika eesmärkidel:
Kujutame ette, et meil on vaja samaaegselt läbi viia 8 web-testi ja 8 Android-testi. Selleks kasutame GCP-d ja käivitame 2 virtuaalmasinat Selenoidiga. Esimesel käivitame 8 konteinerit brauseritega. Teisel – 8 konteinerit emulaatoritega. Vaadakem hindu:
Ühe Chrome'i konteineri käivitamiseks on meil vaja n1-standard-1 masinat. Androidi puhul on see n1-standard-4 ühe emulaatori jaoks. Tegelikult on paindlikum ja odavam viis määrata konkreetseid kasutaja väärtusi CPU/dünaamilise mälu jaoks, kuid hetkel ei ole see Sauce Labsi võrdlemiseks oluline.
Ja siin on Sauce Labsi kasutustasud:
Ma arvan, et olete juba märganud erinevust, kuid siiski toome välja tabeli meie ülesande arvutustega:
Vajalikud ressursid
Kuu tasu
Tööajad(8.00 – 20.00)
Tööajad+ Eemaldatavad
GCP Webi 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 veebilehtede jaoks
Virtuaalne Cloud8 paralleeltestimine
$1.559
—
—
GCP Androidile
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 Androidile
Reaalne seadme pilv 8 paralleeltestimist
$1.999
—
—
Nagu näha, on kulude erinevus tohutu, eriti kui teste käivitada ainult tööajal kaheksa tundi. Kuid kulusid saab veelgi vähendada, kasutades esitatud masinaid. Mis see on?
Esitatud VM on instance, mille saate luua ja käivitada palju odavama hinnaga kui normaalsed instantsid. Siiski võib Compute Engine need instantsid katkestada (esitada), kui tal on vaja neid ressursse muude ülesannete jaoks. Esitatud 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 instance katkestamisi, siis võivad esitatud instantsid oluliselt vähendada teie Compute Engine'i kulusid. Näiteks võivad partii töötlemise töökohad töötada esitatud instantsidel. Kui mõned neist instantsidest katkestatakse töötlemise ajal, siis töö aeglustub, kuid ei peatu täiesti. Esitatud instantsid viivad lõpule teie partii töötlemise ülesanded, ilma et need koormaksid teie olemasolevaid instantsid ja ilma et peaksite maksma täishinna täiendavate normaalse instantside eest.
Ja see pole veel kõik! Tegelikult olen kindel, et keegi ei käivita teste 12 tundi järjest. Kui see nii on, saate automaatselt käivitada ja peatada virtuaalsed masinad, kui need pole vajalikud. Tegelik kasutusaeg võib langeda kuni 6 tunnini päevas. Sel juhul langeks tasu meie ülesande kontekstis koguni 11$ kuus 8 brauseri eest. Kas see pole imeline? Kuid esitatud masinatega peame olema ettevaatlikud ja valmis katkestusteks ning ebastabiilseks toimimiseks, kuigi neid olukordi saab ette näha ja programmeerimise teel käsitleda. See on seda väärt!
Aga kindlasti ei ütle ma, et 'ärge kunagi kasutage pilvetestimise farmisid'. Neil on mitmeid eeliseid. Esiteks ei ole see lihtsalt virtuaalne masin, vaid täielik lahendus testimise automatiseerimiseks, millel on välja töötatud funktsionaalsus: kaugjuhtimine, logimine, ekraanipildid, videote salvestamine, erinevad brauserid ja füüsilised mobiilseadmed. Paljusid olukordi võib see olla asendamatu suurepärane alternatiiv. Eriti on testimisplatvormid kasulikud IOS-automatiseerimiseks, kui avalikud pilved suudavad pakkuda ainult Linuxi/Windowsi süsteeme. Kuid IOS-st räägitakse järgmistes artiklites. Soovitan alati olukorda arvesse võtta ja ülesannetest lähtuvalt: mõnes on odavam ja efektiivsem kasutada avalikke pilvi, samas kui mõnes on testimisplatvormid igati raha väärt.
Praeguse infrastruktuuri oleku illustreerimine
Õppimise lingid
Sarnased tööriistad:
6. Orkestreerimine
Tehnoloogia lühikirjeldus
Mul on häid uudiseid – me oleme peaaegu artikli lõpuni jõudnud! Praegu on meie automatiseerimisstruktuur koosneb web ja Android-testidest, mida jooksutame paralleelselt GitLab CI kaudu, kasutades Dockerit toetavaid tööriistu: Selenium grid ja Selenoid. Veelgi enam, me kasutame virtuaalmasinaid, mis on loodud GCP kaudu, et käivitada nendes konteinerid, mis sisaldavad brausereid ja emulaatoreid. Kulude vähendamiseks käivitame need virtuaalsed masinad ainult nõudmisel ja peatame need, kui testimist ei toimu. Kas on midagi veel, mis võiks meie infrastruktuuri parandada? Vastus on jah! Tere tulemast Kubernetes (K8s)!
Alustame sellest, kuidas sõnad orkestreerimine, klaster ja Kubernetes omavahel seotud on. Kõrgel tasemel on orkestreerimine süsteem, mis juurutab ja haldab rakendusi. Testimise automatiseerimiseks on sellised konteineriseeritavad rakendused nagu Selenium grid ja Selenoid. Docker ja K8s täiendavad üksteist. Esimene on mõeldud rakenduste juurutamiseks, teine aga orkestreerimiseks. K8s on omakorda klaster. Klastri ülesanne on kasutada VM-e sõlmedena, mis võimaldab installida erinevaid funktsioone, programme ja teenuseid ühe serveri (klastri) raames. Kui mõni sõlm ebaõnnestub, haaravad teised sõlmed ülesande, tagades meie rakenduse katkematu töö. Lisaks sellele on K8s-l oluline funktsionaalsus, mis on seotud skaleerimisega, võimaldades automaatselt saada optimaalset ressursi hulka, tuginedes koormusele ja seatud piirangutele.
Tõele au andes on Kubernetes'i käsitsi juurutamine algusest peale mitte just lihtne ülesanne. Jätan lingi tuntud praktilisele juhendile "Kubernetes The Hard Way", ja kui teid huvitab, võite harjutada. Kuid õnneks on olemas alternatiivsed meetodid ja tööriistad. Lihtsaim neist on Google Kubernetes Engine (GKE) GCP-s, mis võimaldab saada valmis klastrit pärast paari klikki. Alguse tegemiseks soovitan just seda lähenemist, kuna see võimaldab teil keskenduda studeerimisele, kuidas kasutada K8s oma ülesannete jaoks, mitte uurida, kuidas sisemised komponendid omavahel integreeruvad.
Väärtus automatiseerimisinfrastruktuurile
Vaatame mõningaid olulisi funktsioone, mida K8s pakub:
- rakenduse juurutamine: multi-nodede klastrite kasutamine, mitte virtuaalmasinate;
- dünaamiline skaleerimine: vähendab kulusid ressurssidele, mis on kasutusel ainult nõudmisel;
- ennast taastav (Self-healing): automaatne pods'i taastamine (mis toob kaasa ka konteinerite taastamise);
- uuenduste väljalaskmine ja muudatuste tagasivõtmine ilma seisakuta: tööriistade, brauserite ja emulaatorite uuendamine ei katkesta praeguste kasutajate tööd
Kuid K8s ei ole endiselt hõbedane kuul. Kõikide eeliste ja piirangute mõistmiseks meie arutletud tööriistade kontekstis (Selenium grid, Selenoid) arutame lühidalt K8s ülesehitust. Klastris on kaks tüüpi node: Master Nodes ja Workers Nodes. Master Nodes vastutavad haldamise, juurutamise ja ajastamisotsuste eest. Workers nodes on need, kus rakendused töötavad. Node'id sisaldavad ka konteinerite käitamise keskkonda. Meie puhul on selleks Docker, mis vastutab konteineritega seotud toimingute eest. Kuid on ka alternatiivseid lahendusi, näiteks. Oluline on mõista, et skaleerimine või ennast taastamine ei kehti konteineritele otseselt. See rakendatakse pods'ide arvu suurendamise või vähendamise kaudu, mis omakorda sisaldavad konteinerit (tavaliselt üks konteiner pod'i kohta, kuid ülesande järgi võib olla ka rohkem). Kõrgetasemeline hierarhia esindab töötaja node'e, mille sees on pods, mille sees on käivitatud konteinerid.
Skaalafunktsioon on võtmetähtsusega ja seda saab rakendada nii node'ide sees klastrite node-poolides kui ka pod'ide sees node'is. On kaks tüüpi skaalamist, mis kehtivad nii node'ide kui ka pod'ide kohta. Esimene tüüp on horisontaalne – skaleerimine toimub node'ide/pod'ide arvu suurendamise abil. Selline tüüp on eelistatum. Teine tüüp on vastavalt vertikaalne. Skaleerimine toimub node'ide/pod'ide suuruse suurendamisega, mitte nende arvu suurendamisega.
Nüüd vaatame meie tööriistu ülaltoodud mõistete kontekstis.
Selenium grid
Nagu eespool mainitud, on Selenium grid väga populaarne tööriist ja pole üllatav, et see on konteineriseeritud. Seega pole üllatav, et Selenium grid'i saab käitada K8s-i keskkonnas. Näidet sellest, kuidas seda teha, võib leida ametlikust K8s-i hoidlast. Nagu tavaliselt, lisan sektsiooni lõppu lingid. Lisaks on praktilises juhendis näidatud, kuidas seda teha Terraformi abil. Samuti on juhised, kuidas skaleerida pod'ide arvu, mis sisaldavad brauserikonteinereid. Kuid automaatse skaalimise funktsioon K8s-i kontekstis on endiselt keeruline ülesanne. Kui ma hakkasin õppima, ei leidnud ma mingit praktilist juhendit ega soovitusi. Pärast mitmeid uuringuid ja katsetusi koos DevOps-meeskonna toega valisime lähenemise, kus tõstame konteinerid koos vajalike brauseritega ühe pod'i sees, mis asub ühes töötaja node'is. Selline lähenemine võimaldab meil rakendada horisontaalset skaleerimisstrateegiat node'ide arvu suurendamise kaudu. Loodan, et tulevikus olukord muutub ja näeme üha rohkem parimate lähenemisviiside ja valmislahenduste kirjeldusi, eriti pärast Selenium grid 4 väljaandmist uue sisearhitektuuriga.
Selenoid:
Praegu on Selenoid'i käitamine K8s-is suurim pettumus. Need ei ole ühilduvad. Teoreetiliselt saame tõsta Selenoid-konteineri pod'i sees, kuid kui Selenoid hakkab käitama brauserikonteinereid, on need endiselt samas pod'is. See muudab skaleerimise võimatuks ja seetõttu ei erine Selenoid'i töö klastri sees virtuaalmasinast. Lugu lõppeb siinkohal.
Moon:
Teades seda kitsaskohta Selenoid'i töös, on arendajad välja töötanud võimsama tööriista, mida nad kutsuvad Mooniks. See tööriist oli algselt mõeldud töötama Kubernetes'e keskkonnas ning seetõttu on automaatne skaleerimisvõimekus saadaval. Veelgi enam, ma ütleks, et praegu on see ainus tööriist maailmas Seleniumis, mis pakub välja karbist välja native K8s klastri tuge (ei ole enam, vaata järgmist tööriista ). Mooni võtmeomadus, mis tagab selle toe, on:
Completely stateless. Selenoid hoiab mälus teavet praegu käimasolevate brauseriseansside kohta. Kui mingil põhjusel selle protsess kokku kukub, kaovad kõik käimasolevad seansid. Moonil puudub seevastu sisemine olek ja see saab olla replikatsiooniks andmekeskustes. Brauseriseansid püsivad aktiivsed isegi siis, kui üks või enam replikat laguneb.
Nii et Moon on suurepärane lahendus, kuid ühe probleemiga – see ei ole tasuta. Hind sõltub seansside arvust. Tasuta saab käivitada vaid 0-4 seanssi, mis pole just väga kasulik. Kuid alates viiendast seansist tuleb maksta 5$ igaühe eest. Olukord võib ettevõtteti varieeruda, kuid meie puhul pole Mooni kasutamine mõistlik. Nagu ma eespool kirjutasin, saame vajadusel käivitada VMs koos Selenium Gridiga või suurendada sõlmede arvu klastris. Ühe pipeline'i kohta käivitame umbes 500 brauserit ja peatame kõik ressursid pärast testide lõppu. Kui me oleksime kasutanud Mooni, oleksime pidanud maksma täiendavaid 500 x 5 = 2500 $ kuus, sõltumata sellest, kui sageli me teste käivitame. Ja jälle, ma ei ütle "ärge kasutage Moont". Teie ülesannete jaoks võib see olla asendamatu lahendus, näiteks kui teie organisatsioonis on palju projekte/tiime ning teil on vaja suurt ühist klastri kõigi jaoks. Nagu alati, jätan linki lõppu ja soovitan teha kõik vajalikud arvutused teie ülesande kontekstis.
Callisto: (Tähelepanu! Seda ei ole originaalses artiklis 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õlkes töötasin, ilmus netis uus paljulubav tööriist Callisto (tere, Cypress ja teised Seleniumi tapjad). See töötab K8s-iga natiivselt ja võimaldab Selenoid-konteinereid pods-des käitada, jaotatuna Nodes-idele. Kõik töötab otse välja kastist, sealhulgas automaatne skaleerimine. Fantastiline, kuid tuleb testida. Mul on juba õnnestunud see tööriist üles seada ja teha mõned katsed. Kuid järeldusi on veel vara teha, pärast pikaajalisi tulemusi, võib-olla teen järgmistes artiklites ülevaate. Praegu jätan ainult lingid iseseisvaks uurimiseks.
Praeguse infrastruktuuri oleku illustreerimine
Õppimise lingid
Õppimise lingid
Sarnased tööriistad
7. Infrastruktuur kui kood (IaC)
Tehnoloogia lühikirjeldus
Ja nüüd oleme jõudnud viimase jaotuseni. Tavaliselt ei kuulu see tehnoloogia ja seotud ülesanded automatiseerimise inseneride vastutusalasse. Sellel on oma põhjused. Esiteks on paljudes organisatsioonides infrastruktuuri küsimused DevOps osakonna kontrolli all, ning arendustiimid ei muretse eriti selle pärast, kuidas pipeline töötab ja kuidas kõike, mis sellega seotud, toetada. Teiseks, olgem ausad, praktikat «Infrastruktuur kui kood (IaC)» ei rakendata endiselt paljudes ettevõtetes. Kuid kindlasti on see saanud populaarseks suunaks ja on oluline püüda olla seotud selle protsesside, lähenemiste ja tööriistadega. Või vähemalt olla kursis toimuvaga.
Alustame selle lähenemise kasutamise motivatsiooniga. Oleme juba arutanud, et GitlabCI testide käivitamiseks vajame vähemalt ressursse Gitlab Runneri käitamiseks. Ja et käivitada brauserite/emulaatorite konteinerid, peame reserveerima VM-i või klastrit. Peale testimise ressursside on meil vaja märkimisväärset hulka võimekust arenduskeskkondade, staging'i ja tootmise toetamiseks, mis hõlmab ka andmebaase, automaatseid ajakavasid, võrgukonfiguratsioone, koormuste tasakaalustajat, kasutajate õigusi ja nii edasi. Peamine probleem on nõutavates pingutustes, et seda kõike toetada. On mitmeid viise, kuidas saame muudatusi teha ja uuendusi välja anda. Näiteks GCP kontekstis saame kasutada brauseris UI-konsooli ja teha kõiki toiminguid, klikkides nuppudel. Alternatiivne meetod võib olla API-kõnede kasutamine pilveelementidega suhtlemiseks või k командной строке gcloud utiliidi rakendamine vajalike toimingute teostamiseks. Kuid tõeliselt suure hulga erinevate elementide ja infrastruktuuri elementide korral muutub kõiki toiminguid käsitsi teostada raske või isegi võimatuks. Veelgi enam, kõik need käsitsi toimingud on kontrollimatud. Me ei saa neid enne täitmist üle vaadata, kasutada versioonihaldussüsteemi ega kiiresti tagasi kerida muudatusi, mis on põhjustanud intsidenti. Selliste problemidega tegelemiseks on insenerid loonud ja loovad automaatseid bash/shell-skripte, mis ei ole oluliselt parem kui eelnevad meetodid, kuna neid ei ole just lihtne kiiresti lugeda, mõista, toetada ja modifitseerida protseduurilises stiilis.
Selles artiklis ja praktilises juhendis kasutan kahte tööriista, mis kuuluvad IaC praktika alla. Need on Terraform ja Ansible. Mõned arvavad, et nende samal ajal kasutamine pole mõttekas, kuna nende funktsioonid on sarnased ja nad on üksteisega asendatavad. Kuid asi on selles, et algselt on nende eesmärgid täiesti erinevad. Ja fakt, et need tööriistad peaksid teineteist täiendama, on kinnitatud koosolekul, mille korraldasid HashiCorpi ja RedHati esindavad arendajad. Kontseptuaalne erinevus seisneb selles, et Terraform on serverite haldamiseks mõeldud provisioningu tööriist, samas kui Ansible on konfiguratsioonihalduse tööriist, mille eesmärk on tarkvara installimine, seadistamine ja haldamine nendel serveritel.
Teine oluline erinevus nende tööriistade vahel on koodi kirjutamise stiil. Erinevalt bashist ja Ansible'ist kasutab Terraform deklaratiivset stiili, mis põhineb soovitud lõppseisundi kirjeldamisel, mida on vaja saavutada käitamise tulemusena. Näiteks kui kavatseme luua 10 virtuaalmasinat (VM) ja rakendada muudatusi läbi Terraformi, saame 10 VM-i. Kui käivitame skripti uuesti, siis ei toimu midagi, kuna meil on juba 10 VM-i ja Terraform teab sellest, kuna ta salvestab infrastruktuuri praeguse oleku olekufaile. Ansible seevastu kasutab protseduuri lähenemist ja kui palume sellel luua 10 VM-i, saame esimesel käivitamisel 10 VM-i, nagu ka Terraformiga. Kuid pärast korduvat käivitamist on meil juba 20 VM-i. See on oluline erinevus. Protseduurilises stiilis me ei salvesta praegust seisundit, vaid kirjeldame lihtsalt samme, mida tuleb järgida. Loomulikult saame töötada erinevate olukordadega, lisada kontrollib, kas ressursid ja praegune seisund eksisteerivad, kuid pole mõtet raisata aega ja pingutada selle loogika kontrollimisega. Lisaks suurendab see viga tegemise riski.
Kokkuvõtteks võib öelda, et serverite provisionimiseks on sobivam tööriist Terraform ja deklaratiivne märgistus. Kuid konfiguratsioonihalduse töö tuleks paremini delegeerida Ansible'ile. Kui oleme sellest aru saanud, vaatame automaatimise kontekstis kasutamise näiteid.
Väärtus automatiseerimisinfrastruktuurile
Siin on oluline mõista, et testimise automatiseerimise infrastruktuur peaks olema osa kogu ettevõtte infrastruktuurist. See tähendab, et kõik IaC-praktikad tuleb rakendada globaalselt kogu organisatsiooni ressurssidele. Kes on selle eest vastutav, sõltub teie protsessidest. DevOps-meeskond on nendes küsimustes kogenum, nad näevad kogu toimuvat pilti. Samas on QA-insenerid rohkem kaasatud automatiseerimise ja pipeline'i ülesehitamise protsessi, mis võimaldab neil paremini näha kõiki vajalikke muudatusi ja täiustamise võimalusi. Parim variant on töötada koos, jagades teadmisi ja ideid oodatud tulemuse saavutamiseks.
Tooksin 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. Paigaldada Ansible'i abil vajalikud testimise tööriistad: docker, Selenoid, Selenium Grid ja laadida vajalikud brauserite/emulaatorite versioonid.
3. Kirjeldada Terraformi kaudu VM-i omadused, milles töötatakse GitLab Runner.
4. Paigaldada Ansible'i abil GitLab Runner ja vajalikud kaasnevad tööriistad, määrata seaded ja konfiguratsioonid.
Praeguse infrastruktuuri oleku illustreerimine
Uuringuks vajalikud lingid:
Sarnased tööriistad
Teeme kokkuvõtte!
Samm
Tehnoloogia
Tööriistad
Väärtus automatiseerimisinfrastruktuurile
1
Kohalik jooks
Node.js, Selenium, Appium
- Kõige populaarsemad tööriistad veebis ja mobiilis
- Toetab paljusid keeli ja platvorme (sealhulgas Node.js)
2
Versioonihaldussüsteemid
Git
- Sarnased eelised arendusprogrammiga
3
Konteineriseerimine
Docker, Selenium grid, Selenoid (Veeb, Android)
- Testide paralleelne käitamine
- Isolaatud keskkonnad
- Lihtne, paindlik versioonide värskendamine
- Dünaamiline mitteaktiivsete ressursside peatamine
- Lihtne seadistada
4
CI / CD
Gitlab CI
- Testid on osa konveierist
- Kiire tagasiside
- Nähtavus kogu ettevõttes / meeskonnas
5
Pilveplatvormid
Google Cloud Platform
- Ressursid vastavalt nõudlusele (maksame ainult siis, kui neid vajame)
- Lihtne hallata ja värskendada
- Kõigi ressursside nähtavus ja kontroll
6
Orkestreerimine
Kubernetes
Konteinerite kontekstis brauserite/emulaatoritega pods'i sees:
- Skaalautuvus / automaatne skaala
- Iseseisev taastumine
- A värskendused ja tagasipöördumised katkemata
7
Infrastruktuur koodina (IaC)
Terraform, Ansible
- Sarnased eelised arendusinfrastruktuuris
- Kõik koodi versioonimise eelised
- Lihtne teha muudatusi ja hallata
- Totally automated
Mõttekaardi diagrammid: infrastruktuuri evolutsioon
step1: Kohalik
step2: VCS
step3: Konteineriseerimine
step4: CI/CD
step5: Pilveplatvormid
step6: Orkestreerimine
step7: IaC
Mis edasi?
Nii et, see on artikli lõpp. Kuid lõpetuseks tahaksin seada teiega mõned kokkulepped.
Teie poolt
Kuidas alguses öeldi, tahaksin, et artikkel tooks praktilist kasu ja aitaks teil saadud teadmisi reaalses töös rakendada. Lisatakse veel kord.
Kuid isegi pärast seda ärge peatage, praktiseerige, uurige asjakohaseid linke ja raamatuid, õppige, kuidas see töötab teie ettevõttes, leidke kohti, mida saab parandada, ja osalege selles. Edu!
Minu poolt
Pealkirjast on näha, et see oli vaid esimene osa. Kuigi see tuli üsna suur, pole siin endiselt olulisi teemasid käsitlemata. Teises osas kavatseme arutada automatiseerimise infrastruktuuri IOS-i kontekstis. Apple'i piirangute tõttu, mis seondub IOS simulaatorite käitamisega ainult macOS süsteemides, on meie lahenduste valik piiratud. Näiteks pole meil võimalik kasutada Dockerit simulaatori käitamiseks või avalikke pilvi virtuaalmasinate käitamiseks. Kuid see ei tähenda, et teisi alternatiive ei oleks. Püüan teid kursis hoida tipptasemel lahenduste ja kaasaegsete tööriistadega!
Samuti ei maininud ma üsna ulatuslikke teemasid, mis on seotud jälgimisega. Osa 3-s kavatseme arutada kõige populaarsemaid tööriistu infrastruktuuri jälgimiseks ning milliseid andmeid ja mõõdikuid tuleks arvesse võtta.
Ja lõpetuseks. Tulevikus plaanin välja anda videokursuse testimisinfra ehitamisest ja populaarsetest tööriistadest. Praegu on internetis üsna palju kursusi ja loenguid DevOpsi teemal, kuid kõik materjalid esitatakse arendamise kontekstis, mitte testimise automatiseerimise. Selle teema osas on mul väga vajalik tagasiside, kas selline kursus oleks huvitav ja väärtuslik testijate ja automatiseerijate kogukonnale. Aitäh juba ette!
Allikas: habr.com
