Diel 1: Web/Android
remark: dit artikel is in oersetting yn it Russysk fan it orizjinele artikel Alle yllustraasjes, keppelings, sitaten en termen wurde lykwols bewarre yn 'e orizjinele taal om ferfoarming fan' e betsjutting te foarkommen by it oersetten yn it Russysk. Ik winskje jo lokkich studearjen!
Op it stuit is de DevOps-spesjaliteit ien fan 'e meast yn' e fraach yn 'e IT-sektor. As jo populêre siden foar sykjen nei wurk iepenje en filterje op salaris, sille jo sjen dat DevOps-relatearre banen boppe oan 'e list steane. It is lykwols wichtich om te begripen dat dit benammen ferwiist nei in 'Senior' posysje, wat betsjut dat de kandidaat in heech nivo fan feardichheden, kennis fan technology en ark hat. Dit komt ek mei in hege graad fan ferantwurdlikens ferbûn mei de ûnûnderbrutsen wurking fan produksje. Wy begûnen lykwols te ferjitten wat DevOps is. Yn it earstoan wie it gjin spesifike persoan of ôfdieling. As wy sykje nei definysjes fan dizze term, fine wy in protte moaie en korrekte haadwurden, lykas metodyk, praktiken, kulturele filosofy, groep fan begripen, ensfh.
Myn spesjalisaasje is in test automatisearring yngenieur (QA automatisearring yngenieur), mar ik leau dat it moat net wurde assosjearre allinnich mei it skriuwen fan auto-tests of ûntwikkeljen test ramt arsjitektuer. Yn 2020 is kennis fan automatisearringsinfrastruktuer ek essensjeel. Hjirmei kinne jo it automatisearringsproses sels organisearje, fan it útfieren fan testen oant it leverjen fan resultaten oan alle belanghawwenden yn oerienstimming mei jo doelen. As resultaat binne DevOps-feardigens in must om it wurk dien te krijen. En dit alles is goed, mar spitigernôch is d'r in probleem (spoiler: dit artikel besiket te ferienfâldigjen dit probleem). It punt is dat DevOps dreech is. En dit is fanselssprekkend, om't bedriuwen net folle betelje foar iets dat maklik te dwaan is ... Yn 'e DevOps-wrâld binne d'r in grut oantal ark, termen en praktiken dy't behearske wurde moatte. Dit is foaral lestich oan it begjin fan in karriêre en hinget ôf fan 'e opboude technyske ûnderfining.
Boarne:
Hjir sille wy wierskynlik einigje mei it ynliedende diel en rjochtsje op it doel fan dit artikel.
Wêr giet dit artikel oer?
Yn dit artikel sil ik myn ûnderfining diele mei it bouwen fan in ynfrastruktuer foar testautomatisaasje. D'r binne in protte boarnen fan ynformaasje op it ynternet oer ferskate ark en hoe't se se brûke, mar ik soe se gewoan yn 'e kontekst fan automatisearring wolle sjen. Ik leau dat in protte automatisearring yngenieurs binne bekend mei de situaasje as nimmen útsein jo rint de ûntwikkele tests of soarget foar it behâld fan harren. As gefolch wurde tests ferâldere en moatte jo tiid besteegje oan it bywurkjen fan se. Nochris, oan it begjin fan in karriêre, kin dit nochal in drege taak wêze: ferstannich beslute hokker ark moatte helpe om in bepaald probleem te eliminearjen, hoe se te selektearjen, te konfigurearjen en te ûnderhâlden. Guon testers wenden har ta DevOps (minsken) foar help en, litte wy earlik wêze, dizze oanpak wurket. Yn in protte gefallen kin dit de ienige opsje wêze, om't wy gjin sicht hawwe yn alle ôfhinklikens. Mar lykas wy witte, binne DevOps heul drokke jonges, om't se moatte tinke oer de ynfrastruktuer fan it heule bedriuw, ynset, tafersjoch, mikrotsjinsten en oare ferlykbere taken ôfhinklik fan 'e organisaasje/team. Lykas gewoanlik it gefal is, is automatisearring gjin prioriteit. Yn sa'n gefal moatte wy besykje alles mooglik fan ús kant te dwaan fan begjin oant ein. Dit sil ôfhinklikens ferminderje, de workflow fersnelle, ús feardigens ferbetterje en ús it gruttere byld sjen kinne fan wat der bart.
It artikel presintearret de populêrste en populêrste ark en lit sjen hoe't jo se kinne brûke om stap foar stap in automatisearringynfrastruktuer te bouwen. Elke groep wurdt fertsjintwurdige troch ark dy't binne hifke troch persoanlike ûnderfining. Mar dat betsjut net dat jo itselde ding moatte brûke. De ark sels binne net wichtich, se ferskine en wurde ferâldere. Us technyske taak is om de basisprinsipes te begripen: wêrom wy dizze groep ark nedich binne en hokker wurkproblemen wy kinne oplosse mei har help. Dêrom lit ik oan 'e ein fan elke seksje keppelings nei ferlykbere ark dy't kinne wurde brûkt yn jo organisaasje.
Wat is net yn dit artikel
Ik werhelje nochris dat it artikel net giet oer spesifike ark, dus d'r sil gjin ynfoegingen fan koade wêze fan 'e dokumintaasje en beskriuwingen fan spesifike kommando's. Mar oan 'e ein fan elke seksje lit ik keppelings foar detaillearre stúdzje.
Dit wurdt dien omdat:
- dit materiaal is heul maklik te finen yn ferskate boarnen (dokumintaasje, boeken, fideokursussen);
- as wy begjinne te gean djipper, wy sille moatte skriuwe 10, 20, 30 dielen fan dit artikel (wylst de plannen binne 2-3);
- Ik wol gewoan jo tiid net fergrieme, om't jo miskien oare ark wolle brûke om deselde doelen te berikken.
Praktyk
Ik soe wirklik graach wolle dat dit materiaal nuttich is foar elke lêzer, en net allinich lêzen en ferjitten. Yn elke stúdzje is praktyk in heul wichtige komponint. Dêrfoar haw ik my taret. D'r wachtet ek op jo húswurk om derfoar te soargjen dat jo de rigels fan 'e kommando's dy't jo útfiere net sûnder kop kopiearje.
Plan
Stap
Technology
tools
1
Lokaal rinnen (tariede web- / android-demo-tests en útfiere it lokaal)
Node.js, Selenium, Appium
2
Ferzje kontrôle systemen
gean
3
Containerization
Docker, Selenium grid, Selenoid (Web, Android)
4
CI/CD
Gitlab CI
5
Cloud platfoarms
Google Cloud Platfoarm
6
Orkestraasje
Kubernetes
7
Ynfrastruktuer as koade (IaC)
Terraform, Ansible
Struktuer fan elke seksje
Om it ferhaal dúdlik te hâlden, wurdt elke seksje beskreaun neffens de folgjende skets:
- koarte beskriuwing fan de technology,
- wearde foar automatisearring ynfrastruktuer,
- yllustraasje fan 'e hjoeddeistige steat fan' e ynfrastruktuer,
- keppelings nei stúdzje,
- ferlykbere ark.
1. Run tests lokaal
Koarte beskriuwing fan de technology
Dit is gewoan in tariedende stap om de demo-tests lokaal út te fieren en te kontrolearjen dat se passe. Yn it praktyske diel wurdt Node.js brûkt, mar de programmeartaal en platfoarm binne ek net wichtich en kinne jo brûke dy't brûkt wurde yn jo bedriuw.
As automatisearringsark advisearje ik lykwols it gebrûk fan Selenium WebDriver foar webplatfoarms en Appium foar it Android-platfoarm, respektivelik, om't wy yn 'e folgjende stappen Docker-ôfbyldings sille brûke dy't binne oanpast om spesifyk te wurkjen mei dizze ark. Boppedat, ferwizend nei de taakeasken, binne dizze ark it meast yn 'e fraach op' e merke.
Lykas jo miskien hawwe opfallen, beskôgje wy allinich web- en Android-tests. Spitigernôch is iOS in folslein oar ferhaal (tank Apple). Ik plan om IOS-relatearre oplossingen en praktiken yn oankommende dielen te sjen.
Wearde foar automatisearring ynfrastruktuer
Fanút in ynfrastruktuerperspektyf jout lokaal rinnen gjin wearde. Jo kontrolearje allinich dat de tests op 'e lokale masine rinne yn lokale browsers en simulators. Mar yn alle gefallen is dit in needsaaklik útgongspunt.
Yllustraasje fan 'e hjoeddeistige steat fan ynfrastruktuer
Keppelings om te ferkennen
Similar ark
- elke programmeartaal dy't jo leuk fine yn kombinaasje mei Selenium / Appium tests;
- alle tests;
- eltse test runner.
2. Ferzjekontrôlesystemen (Git)
Koarte beskriuwing fan de technology
It sil foar gjinien in grutte iepenbiering wêze as ik sis dat ferzjekontrôle in ekstreem wichtich ûnderdiel is fan ûntwikkeling, sawol yn in team as yndividueel. Op grûn fan ferskate boarnen is it feilich te sizzen dat Git de populêrste fertsjintwurdiger is. In ferzjekontrôlesysteem biedt in protte foardielen, lykas dielen fan koade, opslaan fan ferzjes, weromsette nei eardere tûken, tafersjoch op projektskiednis en backups. Wy sille elk punt net yn detail besprekke, om't ik der wis fan bin dat jo der tige bekend mei binne en it brûke yn jo deistich wurk. Mar as ynienen net, dan advisearje ik it lêzen fan dit artikel te stopjen en dit gat sa gau mooglik op te foljen.
Wearde foar automatisearring ynfrastruktuer
En hjir kinne jo in ridlike fraach stelle: "Wêrom fertelt hy ús oer Git? Elkenien wit dit en brûkt it sawol foar ûntwikkelingskoade as foar auto-testkoade. Jo sille perfoarst gelyk hawwe, mar yn dit artikel hawwe wy it oer ynfrastruktuer en dizze seksje fungearret as foarbyld foar seksje 7: "Ynfrastruktuer as koade (IaC)". Foar ús betsjut dit dat de hiele ynfrastruktuer, ynklusyf testen, beskreaun wurdt yn 'e foarm fan koade, sadat wy der ek ferzjesystemen op kinne tapasse en ferlykbere foardielen krije as foar ûntwikkeling en automatisearringskoade.
Wy sille IaC yn mear detail sjen yn stap 7, mar sels no kinne jo Git lokaal begjinne te brûken troch in lokaal repository te meitsjen. It grutte byld sil útwreide wurde as wy in remote repository tafoegje oan 'e ynfrastruktuer.
Yllustraasje fan 'e hjoeddeistige steat fan ynfrastruktuer
Keppelings om te ferkennen
Similar ark
3. Containerization (Docker)
Koarte beskriuwing fan de technology
Om te demonstrearjen hoe't kontenerisaasje de regels fan it spul hat feroare, litte wy in pear desennia werom yn 'e tiid gean. Doe kochten en brûkten minsken servermasines om applikaasjes út te fieren. Mar yn 'e measte gefallen wiene de fereaske opstartboarnen net fan tefoaren bekend. As gefolch hawwe bedriuwen jild útjûn oan 'e oankeap fan djoere, krêftige servers, mar guon fan dizze kapasiteit waard net folslein brûkt.
De folgjende poadium fan evolúsje wie firtuele masines (VM's), dy't it probleem oplosse fan jild fergriemen op net brûkte boarnen. Dizze technology makke it mooglik om applikaasjes ûnôfhinklik fan elkoar binnen deselde tsjinner út te fieren, en folslein isolearre romte allocearje. Mar, spitigernôch, hat elke technology syn neidielen. It útfieren fan in VM fereasket in folslein bestjoeringssysteem, dat CPU, RAM, opslach ferbrûkt en, ôfhinklik fan it OS, lisinsjekosten moatte wurde rekken holden. Dizze faktoaren beynfloedzje de ladingssnelheid en meitsje portabiliteit lestich.
En no komme wy by containerization. Nochris lost dizze technology it foarige probleem op, om't konteners gjin folsleine OS brûke, dy't in grutte hoemannichte boarnen befrijt en in flugge en fleksibele oplossing foar portabiliteit leveret.
Fansels is kontenerisaasjetechnology neat nij en waard earst yn 'e lette jierren '70 yntrodusearre. Yn dy dagen waarden in protte ûndersyk, ûntjouwings en besykjen útfierd. Mar it wie Docker dy't dizze technology oanpast en maklik tagonklik makke foar de massa's. Tsjintwurdich, as wy prate oer konteners, bedoele wy yn 'e measte gefallen Docker. As wy prate oer Docker-konteners, bedoele wy Linux-konteners. Wy kinne Windows- en macOS-systemen brûke om konteners út te fieren, mar it is wichtich om te begripen dat yn dit gefal in ekstra laach ferskynt. Bygelyks, Docker op Mac rint konteners stil yn in lichtgewicht Linux VM. Wy sille weromkomme nei dit ûnderwerp as wy beprate it rinnen fan Android-emulators yn konteners, dus hjir is d'r in heul wichtige nuânse dy't yn mear detail besprutsen wurde moat.
Wearde foar automatisearring ynfrastruktuer
Wy fûnen út dat containerization en Docker cool binne. Litte wy dit sjen yn 'e kontekst fan automatisearring, om't elk ark of technology in probleem moat oplosse. Lit ús de foar de hân lizzende problemen fan testautomatisearring yn 'e kontekst fan UI-tests sketse:
- in grut oantal ôfhinklikens by it ynstallearjen fan Selenium en benammen Appium;
- kompatibiliteitsproblemen tusken ferzjes fan browsers, simulators en bestjoerders;
- gebrek oan isolearre romte foar browsers / simulators, dat is benammen kritysk foar parallel rinnen;
- lestich te behearjen en te ûnderhâlden as jo 10, 50, 100 of sels 1000 browsers tagelyk útfiere moatte.
Mar om't Selenium it populêrste automatisearringsark is en Docker it populêrste kontenerisaasje-ark is, soe it gjin ferrassing wêze moatte dat immen besocht hat se te kombinearjen om in krêftich ark te meitsjen om de boppeneamde problemen op te lossen. Litte wy sokke oplossingen yn mear detail beskôgje.
Seleniumraster yn docker
Dit ark is it populêrste yn 'e Selenium-wrâld foar it útfieren fan meardere browsers op meardere masines en it behearen fan se fanút in sintrale hub. Om te begjinnen, moatte jo op syn minst 2 dielen registrearje: Hub en Node(s). Hub is in sintrale knooppunt dy't alle oanfragen fan testen ûntfangt en ferspriedt nei de passende knooppunten. Foar elke knooppunt kinne wy in spesifike konfiguraasje konfigurearje, bygelyks troch de winske blêder en syn ferzje op te jaan. Wy moatte lykwols noch sels soargje foar kompatibele browser-bestjoerders en ynstallearje se op 'e winske knopen. Om dizze reden wurdt Selenium grid net brûkt yn syn suvere foarm, útsein as wy moatte wurkje mei browsers dy't net kinne wurde ynstalleare op Linux OS. Foar alle oare gefallen soe in signifikant fleksibele en korrekte oplossing wêze om Docker-ôfbyldings te brûken om Selenium grid Hub en Nodes út te fieren. Dizze oanpak makket it knooppuntbehear sterk ferienfâldige, om't wy de ôfbylding kinne selektearje dy't wy nedich binne mei kompatibele ferzjes fan browsers en sjauffeurs dy't al ynstalleare binne.
Nettsjinsteande negative beoardielingen oer stabiliteit, benammen by it útfieren fan in grut oantal Knooppunten parallel, Selenium grid is noch altyd it meast populêre ark foar it útfieren fan Selenium tests parallel. It is wichtich om te notearjen dat ferskate ferbetterings en oanpassingen fan dit ark konstant ferskine yn iepen boarne, dy't ferskate knyppunten bestride.
Selenoid foar web
Dit ark is in trochbraak yn 'e wrâld fan Selenium, om't it direkt út' e doaze wurket en it libben fan in protte automatisearringsingenieurs folle makliker makke hat. Alderearst is dit gjin oare wiziging fan it Selenium-raster. Ynstee makken de ûntwikkelders in folslein nije ferzje fan Selenium Hub yn Golang, dy't, kombinearre mei lichtgewicht Docker-ôfbyldings foar ferskate browsers, ympuls joech oan 'e ûntwikkeling fan testautomatisearring. Boppedat moatte wy yn it gefal fan Selenium Grid alle fereaske browsers en har ferzjes fan tefoaren bepale, wat gjin probleem is as jo wurkje mei mar ien browser. Mar as it giet om meardere stipe browsers, is Selenoid de nûmer ien oplossing dankzij syn 'browser on demand'-funksje. Alles wat fan ús fereaske is is om de nedige ôfbyldings mei browsers fan tefoaren te downloaden en it konfiguraasjetriem te aktualisearjen wêrmei Selenoid ynteraksje. Nei't Selenoid in fersyk fan 'e tests ûntfangt, sil it automatysk de winske kontener starte mei de winske browser. As de test is foltôge, sil Selenoid de kontener weromlûke, en dêrmei boarnen frijmeitsje foar takomstige oanfragen. Dizze oanpak elimineert folslein it bekende probleem fan 'knooppuntdegradaasje' dat wy faak tsjinkomme yn Selenium grid.
Mar, helaas, Selenoid is noch altyd gjin sulveren kûgel. Wy hawwe de funksje 'browser on demand' krigen, mar de funksje 'boarnen op fraach' is noch altyd net beskikber. Om Selenoid te brûken, moatte wy it ynsette op fysike hardware of op in VM, wat betsjut dat wy fan tefoaren moatte witte hoefolle boarnen moatte wurde tawiisd. Ik tink dat dit gjin probleem is foar lytse projekten dy't 10, 20 of sels 30 browsers parallel rinne. Mar wat as wy 100, 500, 1000 of mear nedich binne? It hat gjin sin om safolle middels hieltyd te ûnderhâlden en te beteljen. Yn seksjes 5 en 6 fan dit artikel sille wy oplossingen beprate wêrmei jo skaalfergrutting kinne, en dêrmei bedriuwskosten signifikant ferminderje.
Selenoid foar Android
Nei it sukses fan Selenoid as webautomatisearringsark, woene minsken wat ferlykber foar Android. En it barde - Selenoid waard útbrocht mei Android-stipe. Fanút it eachpunt fan 'e brûker op hege nivo is it prinsipe fan wurking fergelykber mei webautomatisearring. It ienige ferskil is dat Selenoid ynstee fan browserkontainers Android-emulatorkonteners rint. Yn myn miening is dit op it stuit it machtichste fergese ark foar it parallel útfieren fan Android-tests.
Ik soe echt net wolle prate oer de negative aspekten fan dit ark, om't ik it echt leuk fyn. Mar dochs binne d'r deselde neidielen dy't jilde foar webautomatisearring en binne ferbûn mei skaalfergrutting. Njonken dit moatte wy prate oer noch ien beheining dy't as in ferrassing komme kin as wy it ark foar it earst ynstelle. Om Android-ôfbyldings út te fieren, hawwe wy in fysike masine as VM nedich mei geneste virtualisaasjestipe. Yn 'e how-to-gids lit ik sjen hoe't jo dit kinne ynskeakelje op in Linux VM. As jo lykwols in macOS-brûker binne en Selenoid lokaal wolle ynsette, dan sil dit net mooglik wêze om Android-tests út te fieren. Mar jo kinne altyd in Linux VM lokaal útfiere mei 'neste virtualisaasje' konfigureare en Selenoid ynsette.
Yllustraasje fan 'e hjoeddeistige steat fan ynfrastruktuer
Yn 'e kontekst fan dit artikel sille wy 2-ark tafoegje om de ynfrastruktuer te yllustrearjen. Dit binne Selenium-grid foar webtests en Selenoid foar Android-tests. Yn it GitHub-tutorial sil ik jo ek sjen litte hoe't jo Selenoid brûke om webtests út te fieren.
Keppelings om te ferkennen
Similar ark
- D'r binne oare ark foar kontenerisaasje, mar Docker is de populêrste. As jo wat oars wolle besykje, hâld dan yn gedachten dat de ark dy't wy hawwe behannele foar it parallel útfieren fan Selenium-tests net út 'e doaze sille wurkje.
- Lykas al sein, binne d'r in protte oanpassingen fan seleniumgrid, bygelyks,.
4.CI/CD
Koarte beskriuwing fan de technology
De praktyk fan trochgeande yntegraasje is frij populêr yn ûntwikkeling en is op par mei ferzjekontrôlesystemen. Nettsjinsteande dit, ik fiel dat der betizing yn terminology. Yn dizze paragraaf wol ik 3 modifikaasjes fan dizze technology beskriuwe út myn eachpunt. Op it ynternet fine jo in protte artikels mei ferskillende ynterpretaasjes, en it is absolút normaal as jo miening ferskilt. It wichtichste is dat jo op deselde side binne mei jo kollega's.
Dat, d'r binne 3 termen: CI - Continuous Integration, CD - Continuous Delivery en nochris CD - Continuous Deployment. (Hjirûnder sil ik dizze termen yn it Ingelsk brûke). Elke modifikaasje foeget ferskate ekstra stappen ta oan jo ûntwikkelingpipeline. Mar it wurd kontinu (trochgeande) is it wichtichste ding. Yn dit ferbân bedoele wy eat dat bart fan begjin oant ein, sûnder ûnderbrekking of hânmjittich yntervinsje. Litte wy yn dit ferbân nei CI & CD en CD sjen.
- Trochrinnende yntegraasje dit is de earste stap fan evolúsje. Nei it yntsjinjen fan nije koade nei de tsjinner, ferwachtsje wy rappe feedback te ûntfangen dat ús feroarings ok binne. Typysk omfettet CI it útfieren fan ark foar statyske koade-analyze en ienheid / ynterne API-tests. Hjirmei kinne wy yn in pear sekonden / minuten ynformaasje krije oer ús koade.
- Trochgeande levering is in mear avansearre stap dêr't wy rinne yntegraasje / UI tests. Op dit stadium krije wy lykwols net sa fluch resultaten as by CI. Earst nimme dizze soarten testen langer om te foltôgjen. Twad, foardat it lansearjen, moatte wy ús wizigingen ynsette yn 'e test-/staging-omjouwing. Boppedat, as wy it hawwe oer mobile ûntwikkeling, dan ferskynt in ekstra stap om in build fan ús applikaasje te meitsjen.
- Trochrinnende ynset giet derfan út dat wy automatysk ús feroarings frijlitte oan produksje as alle akseptaasjetests binne trochjûn yn 'e foarige stadia. Njonken dit kinne jo nei it frijlittingsstadium ferskate stadia konfigurearje, lykas it útfieren fan reektests op produksje en it sammeljen fan metriken fan belang. Trochrinnende ynset is allinich mooglik mei goede dekking troch automatisearre tests. As hânmjittige yntervinsjes nedich binne, ynklusyf testen, dan is dit net mear Kontinu (kontinu). Dan kinne wy sizze dat ús pipeline allinich foldocht oan 'e praktyk fan Continuous Delivery.
Wearde foar automatisearring ynfrastruktuer
Yn dizze seksje moat ik dúdlik meitsje dat as wy prate oer end-to-end UI-tests, it betsjut dat wy ús wizigingen en assosjearre tsjinsten moatte ynsette om omjouwings te testen. Trochrinnende yntegraasje - it proses is net fan tapassing foar dizze taak en wy moatte soargje foar it ymplementearjen fan op syn minst Continuous Deliver-praktiken. Continuous Deployment makket ek sin yn 'e kontekst fan UI-tests as wy se yn produksje sille útfiere.
En foardat wy nei de yllustraasje fan 'e arsjitektuerferoaring sjogge, wol ik in pear wurden sizze oer GitLab CI. Oars as oare CI / CD-ark, biedt GitLab in repository op ôfstân en in protte oare ekstra funksjes. Sa is GitLab mear dan CI. It omfettet boarnekoadebehear, Agile-behear, CI / CD-pipelines, logging-ark en metriken sammelje út 'e doaze. De GitLab-arsjitektuer bestiet út Gitlab CI/CD en GitLab Runner. Hjir is in koarte beskriuwing fan 'e offisjele webside:
Gitlab CI / CD is in webapplikaasje mei in API dy't syn steat yn in databank opslacht, projekten / bout beheart en in brûkersynterface leveret. GitLab Runner is in applikaasje dy't builds ferwurket. It kin apart wurde ynset en wurket mei GitLab CI / CD fia in API. Foar testen dy't rinne, hawwe jo sawol Gitlab-eksimplaar as Runner nedich.
Yllustraasje fan 'e hjoeddeistige steat fan ynfrastruktuer
Keppelings om te ferkennen
Similar ark
- En in protte oaren
5. Wolke platfoarms
Koarte beskriuwing fan de technology
Yn dizze seksje sille wy prate oer in populêre trend neamd 'iepenbiere wolken'. Nettsjinsteande de enoarme foardielen dy't de hjirboppe beskreaune virtualisaasje- en kontenerisaasjetechnologyen leverje, hawwe wy noch komputerboarnen nedich. Bedriuwen keapje djoere servers of hiere datasintra, mar yn dit gefal is it nedich om berekkeningen (soms ûnrealistysk) te meitsjen fan hoefolle boarnen wy nedich binne, oft wy se 24/7 sille brûke en foar hokker doelen. Produksje fereasket bygelyks in server dy't XNUMX/XNUMX draait, mar hawwe wy ferlykbere boarnen nedich foar testen bûten wurktiden? It hinget ek ôf fan it type test dat wurdt útfierd. In foarbyld soe load-/stresstests wêze dy't wy fan plan binne te fieren yn net-wurktiden om de oare deis resultaten te krijen. Mar perfoarst is XNUMX/XNUMX-serverbeskikberens net fereaske foar ein-oan-ein automatisearre tests en foaral net foar manuele testomjouwings. Foar sokke situaasjes soe it goed wêze om safolle boarnen te krijen as nedich op oanfraach, se te brûken en stopje te beteljen as se net mear nedich binne. Boppedat soe it geweldich wêze om se direkt te ûntfangen troch in pear mûsklikken te meitsjen of in pear skripts út te fieren. Dit is wêr't iepenbiere wolken foar brûkt wurde. Litte wy nei de definysje sjen:
"De iepenbiere wolk wurdt definiearre as komputertsjinsten oanbean troch providers fan tredden oer it iepenbiere ynternet, wêrtroch se beskikber binne foar elkenien dy't se brûke of keapje wol. Se kinne fergees wêze of ferkocht op oanfraach, wêrtroch klanten allinich per gebrûk kinne betelje foar de CPU-syklusen, opslach of bânbreedte dy't se konsumearje."
Der is in miening dat iepenbiere wolken djoer binne. Mar har wichtichste idee is om bedriuwskosten te ferminderjen. Lykas earder neamd, kinne iepenbiere wolken jo boarnen op oanfraach krije en allinich betelje foar de tiid dat jo se brûke. Ek ferjitte wy soms dat meiwurkers salarissen krije, en spesjalisten binne ek in djoere boarne. It moat rekken holden wurde dat iepenbiere wolken ynfrastruktuerstipe folle makliker meitsje, wêrtroch yngenieurs kinne rjochtsje op wichtigere taken.
Wearde foar automatisearring ynfrastruktuer
Hokker spesifike boarnen hawwe wy nedich foar end-to-end UI-tests? Yn prinsipe binne dit firtuele masines as klusters (wy sille prate oer Kubernetes yn 'e folgjende paragraaf) foar it útfieren fan browsers en emulators. De mear browsers en emulators wy wolle rinne tagelyk, de mear CPU en ûnthâld nedich en hoe mear jild wy moatte betelje foar it. Sa kinne iepenbiere wolken yn 'e kontekst fan testautomatisearring ús in grut oantal (100, 200, 1000 ...) browsers/emulators op oanfraach útfiere, testresultaten sa fluch mooglik krije en stopje mei beteljen foar sa'n waanzinnig boarne-yntinsyf krêft.
De populêrste wolkproviders binne Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). De how-to-gids jout foarbylden fan hoe't jo GCP brûke, mar yn 't algemien makket it net út wat jo brûke foar automatisearringstaken. Se leverje allegear sawat deselde funksjonaliteit. Typysk, om in provider te selektearjen, rjochtet it management him op 'e heule ynfrastruktuer en saaklike easken fan it bedriuw, wat bûten it berik fan dit artikel falt. Foar automatisearringsingenieurs sil it ynteressanter wêze om it gebrûk fan wolkproviders te fergelykjen mei it gebrûk fan wolkplatfoarms spesifyk foar testdoelen, lykas Sauce Labs, BrowserStack, BitBar, ensfh. Dat litte wy it ek dwaan! Nei myn miening is Sauce Labs de meast ferneamde pleats foar wolktesten, en dêrom haw ik it brûkt foar fergeliking.
GCP vs Sauce Labs foar automatisearringsdoelen:
Litte wy ús foarstelle dat wy 8 webtests en 8 Android-tests tagelyk moatte útfiere. Hjirfoar sille wy GCP brûke en 2 firtuele masines mei Selenoid útfiere. Op de earste sille wy 8 konteners ophelje mei browsers. Op de twadde binne d'r 8 konteners mei emulators. Litte wy nei de prizen sjen:
Om ien kontener mei Chrome út te fieren, moatte wy n1-standert-1 auto. Yn it gefal fan Android sil it wêze n1-standert-4 foar ien emulator. In feite is in fleksibeler en goedkeaper manier om spesifike brûkerswearden yn te stellen foar CPU / Unthâld, mar op it stuit is dit net wichtich foar fergeliking mei Sauce Labs.
En hjir binne de tariven foar it brûken fan Sauce Labs:
Ik leau dat jo it ferskil al opmurken hawwe, mar ik sil noch in tabel jaan mei berekkeningen foar ús taak:
Required resources
Montly
Wurkoeren(8 oere - 8 oere)
Wurkoeren+ Ferwiderlik
GCP foar web
n1-standert-1 x 8 = n1-standert-8
$194.18
23 dagen * 12h * 0.38 = $ 104.88
23 dagen * 12h * 0.08 = $ 22.08
Saus Labs foar Web
Virtual Cloud8 parallelle tests
$1.559
-
-
GCP foar Android
n1-standert-4 x 8: n1-standert-16
$776.72
23 dagen * 12h * 1.52 = $ 419.52
23 dagen * 12h * 0.32 = $ 88.32
Saus Labs foar Android
Real Device Cloud 8 parallelle tests
$1.999
-
-
Sa't jo sjen kinne, is it ferskil yn kosten enoarm, foaral as jo allinich testen útfiere yn in tolve oeren wurkperioade. Mar jo kinne besunigje kosten noch fierder as jo brûke preemptible masines. Wat is it?
In preemptible VM is in eksimplaar dat jo kinne oanmeitsje en útfiere tsjin in folle legere priis dan normale eksimplaren. Compute Engine kin dizze gefallen lykwols beëinigje (foarkomme) as it tagong fereasket ta dy boarnen foar oare taken. Preempibele eksimplaren binne tefolle Compute Engine-kapasiteit, sadat har beskikberens ferskilt mei gebrûk.
As jo apps fouttolerant binne en mooglike foaropsjes foar eksimplaar kinne wjerstean, dan kinne foarkommende gefallen jo Compute Engine-kosten signifikant ferminderje. Batchferwurkingstaken kinne bygelyks rinne op preempible eksimplaren. As guon fan dy eksimplaren beëinigje by it ferwurkjen, fertraget de baan, mar stopet net folslein. Preempibele eksimplaren foltôgje jo batchferwurkingstaken sûnder ekstra wurkdruk te pleatsen op jo besteande eksimplaren en sûnder dat jo de folsleine priis moatte betelje foar ekstra normale gefallen.
En it is noch net foarby! Yn 'e realiteit bin ik der wis fan dat gjinien tests foar 12 oeren útfiert sûnder pauze. En as dat sa is, dan kinne jo firtuele masines automatysk begjinne en stopje as se net nedich binne. De wurklike gebrûkstiid kin wurde fermindere nei 6 oeren deis. Dan sil de betelling yn 'e kontekst fan ús taak ôfnimme nei $ 11 per moanne foar 8 browsers. Is dit net prachtich? Mar mei preemptible masines wy moatte wêze foarsichtich en taret op ûnderbrekkings en instability, hoewol't dizze situaasjes kinne wurde foarsjoen en ôfhannele yn software. It is it wurdich!
Mar ik sis lang net 'gebrûk nea wolktestpleatsen'. Se hawwe in oantal foardielen. Alderearst is dit net allinich in firtuele masine, mar in folsleine oplossing foar testautomatisaasje mei in set fan funksjonaliteit út 'e doaze: tagong op ôfstân, logs, skermôfbyldings, fideo-opname, ferskate browsers en fysike mobile apparaten. Yn in protte situaasjes kin dit in essensjeel chic alternatyf wêze. Testplatfoarms binne benammen nuttich foar IOS-automatisearring, as iepenbiere wolken allinich Linux / Windows-systemen kinne oanbiede. Mar wy sille prate oer iOS yn 'e folgjende artikels. Ik advisearje om altyd nei de situaasje te sjen en te begjinnen fan 'e taken: yn guon gefallen is it goedkeaper en effisjinter om iepenbiere wolken te brûken, en yn oaren binne de testplatfoarms perfoarst it jild wurdich.
Yllustraasje fan 'e hjoeddeistige steat fan ynfrastruktuer
Keppelings om te ferkennen
Fergelykbere ark:
6. Orkestraasje
Koarte beskriuwing fan de technology
Ik haw goed nijs - wy binne hast oan 'e ein fan it artikel! Op it stuit bestiet ús automatisearring-ynfrastruktuer út web- en Android-tests, dy't wy parallel troch GitLab CI rinne, mei Docker-ynskeakele ark: Selenium grid en Selenoid. Boppedat brûke wy firtuele masines makke fia GCP om konteners te hostjen mei browsers en emulators. Om kosten te ferminderjen, begjinne wy dizze firtuele masines allinich op fraach en stopje se as testen net wurde útfierd. Is d'r wat oars dat ús ynfrastruktuer ferbetterje kin? It antwurd is ja! Moetsje Kubernetes (K8s)!
Lit ús earst ris sjen hoe't de wurden orkestraasje, kluster en Kubernetes mei elkoar besibbe binne. Op in heech nivo is orkestraasje it systeem dat applikaasjes ynset en beheart. Foar testautomatisearring binne sokke containerisearre applikaasjes Selenium grid en Selenoid. Docker en K8s komplementearje inoar. De earste wurdt brûkt foar ynset fan applikaasjes, de twadde foar orkestraasje. Op syn beurt is K8s in kluster. De taak fan it kluster is om VM's as knooppunten te brûken, wêrtroch jo ferskate funksjonaliteit, programma's en tsjinsten yn ien server (kluster) kinne ynstallearje. As ien fan 'e knooppunten mislearret, sille oare knooppunten ophelje, wat soarget foar ûnûnderbrutsen wurking fan ús applikaasje. Njonken dit hat K8s wichtige funksjonaliteit yn ferbân mei skaalfergrutting, tank oan dêr't wy automatysk krije it optimale bedrach fan middels basearre op de lading en set grinzen.
Yn wierheid, it manuell ynsetten fan Kubernetes fanôf it begjin is hielendal gjin triviale taak. Ik lit in keppeling nei de ferneamde hoe-to-gids "Kubernetes The Hard Way" en as jo ynteressearre binne, kinne jo it oefenje. Mar, gelokkich, binne d'r alternative metoaden en ark. De maklikste manier is om Google Kubernetes Engine (GKE) yn GCP te brûken, wêrtroch jo in klearmakke kluster yn in pear mûsklikken kinne krije. Ik advisearje dizze oanpak te brûken om te begjinnen mei learen, om't jo jo kinne rjochtsje op it learen hoe't jo de K8's brûke foar jo taken ynstee fan te learen hoe't de ynterne komponinten mei elkoar yntegreare wurde moatte.
Wearde foar automatisearring ynfrastruktuer
Litte wy in pear wichtige funksjes besjen dy't de K8s leveret:
- applikaasje-ynset: it brûken fan in multi-knooppuntkluster ynstee fan VM's;
- dynamyske skaalfergrutting: ferleget de kosten fan middels dy't allinich op fraach brûkt wurde;
- self-healing: automatysk herstel fan pods (as gefolch dêrfan wurde konteners ek restaurearre);
- útrol fan updates en weromdraaien fan wizigingen sûnder downtime: it bywurkjen fan ark, browsers en emulators ûnderbrekke it wurk fan hjoeddeistige brûkers net
Mar de K8s is noch altyd gjin sulveren kûgel. Om alle foardielen en beheiningen te begripen yn 'e kontekst fan' e ark dy't wy beskôgje (Selenium grid, Selenoid), sille wy koart de struktuer fan K8s beprate. Kluster befettet twa soarten knooppunten: masterknooppunten en arbeidersknooppunten. Master Nodes binne ferantwurdlik foar behear, ynset en planning besluten. Wurkknooppunten binne wêr't applikaasjes wurde lansearre. Knooppunten befetsje ek in container runtime omjouwing. Yn ús gefal is dit Docker, dy't ferantwurdlik is foar kontener-relatearre operaasjes. Mar der binne bygelyks ek alternative oplossings. It is wichtich om te begripen dat skaalfergrutting of selshealing net direkt jildt foar konteners. Dit wurdt útfierd troch it tafoegjen/ferminderjen fan it oantal pods, dy't op har beurt konteners befetsje (meastal ien container per pod, mar ôfhinklik fan de taak kinne d'r mear wêze). De hiërargy op hege nivo bestiet út arbeidersknooppunten, wêrfan't pods binne, wêrfan konteners opheven binne.
De skaalfunksje is kaai en kin tapast wurde op beide knooppunten binnen in klusterknooppuntpool en pods binnen in knooppunt. D'r binne 2 soarten skaalfergrutting dy't jilde foar sawol knooppunten as pods. It earste type is horizontaal - skaalfergrutting bart troch it fergrutsjen fan it oantal knopen / pods. Dit type is mear foarkar. It twadde type is, dus, fertikaal. Skaalfergrutting wurdt útfierd troch it fergrutsjen fan de grutte fan knopen / pods, en net har oantal.
Litte wy no nei ús ark sjen yn 'e kontekst fan' e boppesteande termen.
Selenium grid
Lykas earder neamd, Selenium grid is in hiel populêr ark, en it is gjin ferrassing dat it is containerized. Dêrom komt it as gjin ferrassing dat Selenium grid kin wurde ynset yn K8s. In foarbyld fan hoe't jo dit dwaan kinne jo fine yn 'e offisjele K8s repository. Lykas gewoanlik hechtsje ik keppelings oan 'e ein fan' e seksje. Derneist lit de hoe-to-gids sjen hoe't jo dit dwaan yn Terraform. D'r binne ek ynstruksjes oer hoe't jo it oantal pods kinne skaalje dat browserkontainers befetsje. Mar de automatyske skaalfergrutting yn 'e kontekst fan K8s is noch altyd net in folslein foar de hân lizzende taak. Doe't ik begon te studearjen, fûn ik gjin praktyske begelieding of oanbefellings. Nei ferskate stúdzjes en eksperiminten mei de stipe fan it DevOps-team, hawwe wy keazen foar de oanpak fan it ferheegjen fan konteners mei de nedige browsers binnen ien pod, dy't yn ien arbeidersknooppunt leit. Dizze metoade lit ús de strategy fan horizontale skaalfergrutting fan knopen tapasse troch har oantal te ferheegjen. Ik hoopje dat dit sil feroarje yn 'e takomst en wy sille sjen mear en mear beskriuwingen fan bettere oanpak en klearmakke oplossingen, benammen nei de frijlitting fan Selenium grid 4 mei in feroare ynterne arsjitektuer.
Selenoïde:
Selenoid-ynset yn K8s is op it stuit de grutste teloarstelling. Se binne net kompatibel. Yn teory kinne wy in Selenoid-kontener yn in pod ferheegje, mar as Selenoid konteners mei browsers begjint te lansearjen, sille se noch yn deselde pod wêze. Dit makket skaalfergrutting ûnmooglik en as gefolch sil it wurk fan Selenoid yn in kluster net ferskille fan wurk yn in firtuele masine. Einfan it ferhaal.
Moanne:
Troch dizze knelpunt te witten by it wurkjen mei Selenoid, hawwe de ûntwikkelders in krêftiger ark útbrocht mei de namme Moon. Dit ark is oarspronklik ûntworpen om te wurkjen mei Kubernetes en, as gefolch, kin en moat de autoscaling-funksje brûkt wurde. Boppedat soe ik sizze dat it op dit stuit is allinnich in ark yn 'e Selenium-wrâld, dy't native K8s-kluster-stipe hat út' e doaze (net mear beskikber, sjoch folgjende ark ). De wichtichste skaaimerken fan Moon dy't dizze stipe leverje binne:
Folslein steateleas. Selenoid bewarret yn it ûnthâld ynformaasje oer op it stuit rinnende blêder sesjes. As it proses om ien of oare reden crasht - dan binne alle rinnende sesjes ferlern. Moon hat yn tsjinstelling ta gjin ynterne steat en kin wurde replikearre oer datasintra. Browser-sesjes bliuwe libben, sels as ien of mear replika's falle.
Dat, Moon is in geweldige oplossing, mar d'r is ien probleem: it is net fergees. De priis hinget ôf fan it oantal sesjes. Jo kinne allinich 0-4 sesjes fergees útfiere, wat net bysûnder nuttich is. Mar, fanôf de fyfde sesje, moatte jo $ 5 foar elk betelje. De situaasje kin ferskille fan bedriuw nei bedriuw, mar yn ús gefal is it gebrûk fan Moon sinleas. Lykas ik hjirboppe beskreaun, kinne wy VM's útfiere mei Selenium Grid op fraach of it oantal knopen yn it kluster ferheegje. Foar likernôch ien pipeline lansearje wy 500 browsers en stopje alle boarnen neidat de tests binne foltôge. As wy Moon brûkten, soene wy in ekstra 500 x 5 = $ 2500 per moanne moatte betelje, nettsjinsteande hoe faak wy tests útfiere. Nochris, ik sis net net brûke Moanne. Foar jo taken kin dit in ûnmisbere oplossing wêze, bygelyks as jo in protte projekten/teams yn jo organisaasje hawwe en jo in grut mienskiplik kluster foar elkenien nedich hawwe. Lykas altyd lit ik in keppeling oan 'e ein en riede oan om alle nedige berekkeningen te dwaan yn' e kontekst fan jo taak.
Callisto: (Oandacht! Dit is net yn it orizjinele artikel en is allinich befette yn 'e Russyske oersetting)
Lykas ik sei, Selenium is in heul populêr ark, en it IT-fjild ûntwikkelet heul fluch. Wylst ik wurke oan 'e oersetting, ferskynde in nij belofte ark neamd Callisto op it web (hallo Cypress en oare Selenium-killers). It wurket natuerlik mei K8's en lit jo Selenoid-konteners útfiere yn pods, ferdield oer knopen. Alles wurket direkt út 'e doaze, ynklusyf autoscaling. Fantastysk, mar moat wurde hifke. Ik haw al slagge om dit ark yn te setten en ferskate eksperiminten út te fieren. Mar it is te betiid om konklúzjes te lûken, nei it ûntfangen fan resultaten oer in lange ôfstân, miskien sil ik in resinsje dwaan yn takomstige artikels. Foar no lit ik allinnich keppelings foar ûnôfhinklik ûndersyk.
Yllustraasje fan 'e hjoeddeistige steat fan ynfrastruktuer
Keppelings om te ferkennen
Similar ark
7. Ynfrastruktuer as koade (IaC)
Koarte beskriuwing fan de technology
En no komme wy by de lêste paragraaf. Typysk binne dizze technology en relatearre taken net de ferantwurdlikens fan automatisearringsingenieurs. En d'r binne redenen foar dit. As earste, yn in protte organisaasjes binne ynfrastruktuerproblemen ûnder kontrôle fan 'e DevOps-ôfdieling en de ûntwikkelingsteams dogge it net echt oer wat de pipeline makket en hoe't alles wat dêrmei ferbûn is moat wurde stipe. As twadde, lit ús earlik wêze, wurdt de praktyk fan Infrastructure as Code (IaC) noch altyd net oannommen yn in protte bedriuwen. Mar it is perfoarst in populêre trend wurden en it is wichtich om te besykjen belutsen te wurden by de prosessen, oanpakken en ark dy't dêrmei ferbûn binne. Of op syn minst op 'e hichte bliuwe.
Litte wy begjinne mei de motivaasje foar it brûken fan dizze oanpak. Wy hawwe al besprutsen dat om testen yn GitlabCI út te fieren, wy op syn minst de middels nedich binne om Gitlab Runner út te fieren. En om konteners mei browsers / emulators út te fieren, moatte wy in VM of kluster reservearje. Neist it testen fan boarnen hawwe wy in signifikant bedrach fan kapasiteit nedich om ûntwikkeling, staging, produksjeomjouwings te stypjen, dy't ek databases, automatyske skema's, netwurkkonfiguraasjes, loadbalancers, brûkersrjochten, ensfh. It wichtichste probleem is de ynspanning dy't nedich is om it allegear te stypjen. D'r binne ferskate manieren wêrop wy wizigingen kinne meitsje en updates útrolje. Bygelyks, yn 'e kontekst fan GCP kinne wy de UI-konsole brûke yn' e browser en alle aksjes útfiere troch te klikken op knoppen. In alternatyf soe wêze om API-oproppen te brûken om te ynteraksje mei wolkentiteiten, of brûk it gcloud-kommando-rigelhulpprogramma om de winske manipulaasjes út te fieren. Mar mei in echt grut oantal ferskillende entiteiten en ynfrastruktuer eleminten wurdt it dreech of sels ûnmooglik om alle operaasjes mei de hân út te fieren. Boppedat binne al dizze hânmjittige aksjes net te kontrolearjen. Wy kinne se net foar beoardieling yntsjinje foar útfiering, in ferzjekontrôlesysteem brûke, en de wizigingen dy't liede ta it ynsidint fluch weromdraaie. Om sokke problemen op te lossen, makken en meitsje yngenieurs automatyske bash / shell-skripts, dy't net folle better binne as eardere metoaden, om't se net sa maklik binne om fluch te lêzen, te begripen, te ûnderhâlden en te feroarjen yn in prosedurele styl.
Yn dit artikel en hoe-to-gids brûke ik 2-ark relatearre oan IaC-praktyk. Dit binne Terraform en Ansible. Guon minsken leauwe dat it gjin sin hat om se tagelyk te brûken, om't har funksjonaliteit ferlykber is en se binne útwikselber. Mar it feit is dat se yn earste ynstânsje folslein oare taken krije. En it feit dat dizze ark elkoar moatte oanfolje, waard befêstige op in mienskiplike presintaasje troch ûntwikkelders dy't HashiCorp en RedHat fertsjintwurdigje. It konseptuele ferskil is dat Terraform in foarsjenningsark is foar it behearen fan de servers sels. Wylst Ansible in ark foar konfiguraasjebehear is waans taak is om software te ynstallearjen, te konfigurearjen en te behearjen op dizze servers.
In oar wichtich ûnderskiedend skaaimerk fan dizze ark is de kodearringstyl. Oars as bash en Ansible, brûkt Terraform in deklarative styl basearre op in beskriuwing fan 'e winske einstân dy't berikt wurde as gefolch fan útfiering. As wy bygelyks 10 VM's sille oanmeitsje en de wizigingen tapasse fia Terraform, dan krije wy 10 VM's. As wy rinne it skript wer, neat sil barre sûnt wy hawwe al 10 VMs, en Terraform wit oer dit omdat it bewarret de hjoeddeiske steat fan de ynfrastruktuer yn in steat triem. Mar Ansible brûkt in prosedurele oanpak en, as jo it freegje om 10 VM's te meitsjen, dan sille wy by de earste lansearring 10 VM's krije, fergelykber mei Terraform. Mar nei it opnij starte sille wy al 20 VM's hawwe. Dit is it wichtige ferskil. Yn prosedurele styl bewarje wy de hjoeddeistige steat net en beskriuwe gewoan in opienfolging fan stappen dy't moatte wurde útfierd. Fansels kinne wy ferskate situaasjes behannelje, ferskate kontrôles tafoegje foar it bestean fan boarnen en de hjoeddeistige steat, mar d'r is gjin punt om ús tiid te fergriemen en ynspanningen te setten om dizze logika te kontrolearjen. Boppedat fergruttet dit it risiko fan flaters.
Gearfetsjend al it boppesteande, kinne wy konkludearje dat Terraform en deklarative notaasje binne in mear gaadlik ark foar foarsjenning tsjinners. Mar it is better om it wurk fan konfiguraasjebehear te delegearjen oan Ansible. Mei dat út 'e wei, litte wy sjen nei gebrûksgefallen yn' e kontekst fan automatisearring.
Wearde foar automatisearring ynfrastruktuer
It ienige wichtige ding om hjir te begripen is dat de ynfrastruktuer foar testautomatisaasje moat wurde beskôge as diel fan 'e heule bedriuwynfrastruktuer. Dit betsjut dat alle IaC-praktiken wrâldwiid moatte wurde tapast op 'e boarnen fan' e heule organisaasje. Wa't dêr ferantwurdlik foar is, hinget ôf fan jo prosessen. It DevOps-team hat mear ûnderfining yn dizze problemen, se sjogge it heule byld fan wat der bart. QA-yngenieurs binne lykwols mear belutsen by it proses fan it bouwen fan automatisearring en de struktuer fan 'e pipeline, wêrtroch't se alle fereaske feroarings en kânsen foar ferbettering better kinne sjen. De bêste opsje is om gear te wurkjen, kennis en ideeën út te wikseljen om it ferwachte resultaat te berikken.
Hjir binne in pear foarbylden fan it brûken fan Terraform en Ansible yn 'e kontekst fan testautomatisearring en de ark dy't wy earder besprutsen:
1. Beskriuw de nedige skaaimerken en parameters fan VM's en klusters mei Terraform.
2. Brûk Ansible, ynstallearje de ark nedich foar testen: docker, Selenoid, Selenium Grid en download de fereaske ferzjes fan browsers / emulators.
3. Brûk Terraform, beskriuw de skaaimerken fan 'e VM wêryn GitLab Runner sil wurde lansearre.
4. Ynstallearje GitLab Runner en de nedige byhearrende ark mei Ansible, set ynstellings en konfiguraasjes.
Yllustraasje fan 'e hjoeddeistige steat fan ynfrastruktuer
Keppelings om te ferkennen:
Similar ark
Litte wy it gearfetsje!
Stap
Technology
tools
Wearde foar automatisearring ynfrastruktuer
1
Lokaal rinnen
Node.js, Selenium, Appium
- De meast populêre ark foar web en mobyl
- Unterstützt in protte talen en platfoarms (ynklusyf Node.js)
2
Ferzje kontrôle systemen
gean
- Fergelykbere foardielen mei ûntwikkelingskoade
3
Containerization
Docker, Selenium grid, Selenoid (Web, Android)
- Running tests parallel
- Isolearre omjouwings
- Ienfâldige, fleksibele ferzjeupgrades
- Dynamysk stopjen fan net brûkte boarnen
- Maklik te setten
4
CI/CD
Gitlab CI
- Tests diel fan 'e pipeline
- Fluch feedback
- Sichtberens foar it hiele bedriuw/team
5
Cloud platfoarms
Google Cloud Platfoarm
- Boarnen op oanfraach (wy betelje allinich as it nedich is)
- Maklik te behearjen en te aktualisearjen
- Sichtberens en kontrôle fan alle boarnen
6
Orkestraasje
Kubernetes
Yn 'e kontekst fan konteners mei browsers / emulators yn pods:
- Skaalfergrutting / automatyske skaalfergrutting
- Self-healing
- Updates en weromdraaien sûnder ûnderbrekking
7
Ynfrastruktuer as koade (IaC)
Terraform, Ansible
- Fergelykbere foardielen mei ûntwikkelingsinfrastruktuer
- Alle foardielen fan koade ferzje
- Maklik om feroaringen te meitsjen en te ûnderhâlden
- Folslein automatisearre
Mind map diagrammen: evolúsje fan ynfrastruktuer
stap 1: Lokaal
stap 2: VCS
stap 3: Containerization
stap 4: CI / CD
stap 5: Wolke Platfoarms
stap 6: Orkestraasje
stap 7:iac
Wat is folgjende?
Dat, dit is de ein fan it artikel. Mar ta beslút wol ik wol wat ôfspraken mei dy meitsje.
Fan dyn kant
Lykas oan it begjin sein, soe ik graach wolle dat it artikel fan praktysk nut is en jo helpt om de kennis dy't opdien is yn echt wurk oan te passen. Ik foegje nochris ta.
Mar sels dêrnei net stopje, oefenje, studearje relevante keppelings en boeken, útfine hoe't it wurket yn jo bedriuw, fine plakken dy't kinne wurde ferbettere en diel oan it. Súkses!
Fan myn kant
Oan de titel kinne jo sjen dat dit mar it earste diel wie. Nettsjinsteande it feit dat it frij grut bliek te wêzen, wurde wichtige ûnderwerpen hjir noch net behannele. Yn it twadde diel bin ik fan plan om te sjen nei automatisearring ynfrastruktuer yn 'e kontekst fan IOS. Fanwegen Apple's beheiningen foar it útfieren fan iOS-simulators allinich op macOS-systemen, is ús oanbod fan oplossingen beheind. Wy kinne bygelyks Docker net brûke om de simulator of iepenbiere wolken út te fieren om firtuele masines út te fieren. Mar dit betsjut net dat der gjin oare alternativen binne. Ik sil besykje jo op 'e hichte te hâlden mei avansearre oplossingen en moderne ark!
Ek haw ik net frij grutte ûnderwerpen neamd yn ferbân mei monitoring. Yn diel 3 sil ik de populêrste ark foar ynfrastruktuermonitoring sjen en hokker gegevens en metriken te beskôgjen.
En ta beslút. Yn 'e takomst plan ik in fideokursus frij te litten oer it bouwen fan testynfrastruktuer en populêre ark. Op it stuit binne d'r nochal wat kursussen en lêzingen oer DevOps op it ynternet, mar alle materialen wurde presintearre yn 'e kontekst fan ûntwikkeling, net testautomatisearring. Oer dit probleem haw ik echt feedback nedich oer de fraach oft sa'n kursus ynteressant en weardefol sil wêze foar de mienskip fan testers en automatisearringsingenieurs. Tank foarôf!
Boarne: www.habr.com