Hluti 1: Vefur/Android
Athugið: þessi grein er þýðing á rússnesku af upprunalegu greininni Hins vegar eru allar myndir, tenglar, tilvitnanir og hugtök varðveitt á frummálinu til að koma í veg fyrir brenglun á merkingunni þegar þau eru þýdd á rússnesku. Ég óska þér gleðilegs náms!
Eins og er er DevOps sérgreinin ein sú eftirsóttasta í upplýsingatæknigeiranum. Ef þú opnar vinsælar atvinnuleitarsíður og síar eftir launum muntu sjá að DevOps tengd störf eru efst á listanum. Hins vegar er mikilvægt að skilja að hér er aðallega átt við „Senior“ stöðu, sem gefur til kynna að umsækjandinn hafi mikla færni, þekkingu á tækni og verkfærum. Þessu fylgir einnig mikil ábyrgð sem fylgir óslitnum rekstri framleiðslunnar. Hins vegar fórum við að gleyma hvað DevOps er. Upphaflega var það ekki neinn ákveðinn einstaklingur eða deild. Ef við leitum að skilgreiningum á þessu hugtaki finnum við mörg falleg og rétt nafnorð, svo sem aðferðafræði, starfshætti, menningarheimspeki, hugtakaflokk o.s.frv.
Mín sérhæfing er sjálfvirkniprófunarverkfræðingur (QA sjálfvirkniverkfræðingur), en ég tel að það ætti ekki aðeins að tengja það við að skrifa sjálfvirk próf eða þróa prófunarrammaarkitektúr. Árið 2020 er þekking á innviðum sjálfvirkni einnig nauðsynleg. Þetta gerir þér kleift að skipuleggja sjálfvirkniferlið sjálfur, allt frá því að keyra prófanir til að veita öllum hagsmunaaðilum niðurstöður í samræmi við markmið þín. Fyrir vikið er DevOps kunnátta nauðsynleg til að vinna verkið. Og allt er þetta gott, en því miður er vandamál (spoiler: Þessi grein reynir að einfalda þetta vandamál). Málið er að DevOps er erfitt. Og þetta er augljóst, því fyrirtæki munu ekki borga mikið fyrir eitthvað sem auðvelt er að gera... Í DevOps heiminum er mikill fjöldi tækja, skilmála og venja sem þarf að ná góðum tökum. Þetta er sérstaklega erfitt í upphafi ferils og fer eftir uppsafnaðri tæknireynslu.
Heimild:
Hér munum við líklega ljúka við inngangshlutann og einblína á tilgang þessarar greinar.
Um hvað fjallar þessi grein?
Í þessari grein ætla ég að deila reynslu minni af því að byggja upp sjálfvirkniprófunarinnviði. Það eru margar upplýsingaveitur á netinu um ýmis verkfæri og hvernig á að nota þau, en mig langar að skoða þau eingöngu í samhengi við sjálfvirkni. Ég tel að margir sjálfvirkniverkfræðingar kannast við aðstæður þegar enginn nema þú keyrir þróuð próf eða er sama um að viðhalda þeim. Fyrir vikið verða próf úrelt og þú þarft að eyða tíma í að uppfæra þau. Aftur, í upphafi ferils getur þetta verið frekar erfitt verkefni: skynsamlega að ákveða hvaða verkfæri ættu að hjálpa til við að útrýma tilteknu vandamáli, hvernig á að velja, stilla og viðhalda þeim. Sumir prófunaraðilar leita til DevOps (menn) til að fá hjálp og við skulum vera heiðarleg, þessi aðferð virkar. Í mörgum tilfellum getur þetta verið eini kosturinn þar sem við höfum ekki sýnileika í öllum ósjálfstæðum. En eins og við vitum eru DevOps mjög uppteknir krakkar, vegna þess að þeir þurfa að hugsa um allan innviði fyrirtækisins, dreifingu, eftirlit, örþjónustu og önnur svipuð verkefni eftir stofnun/teymi. Eins og venjulega er sjálfvirkni ekki í forgangi. Í slíku tilviki verðum við að reyna að gera allt sem hægt er af okkar hálfu frá upphafi til enda. Þetta mun draga úr ósjálfstæði, flýta fyrir vinnuflæði, bæta færni okkar og gera okkur kleift að sjá heildarmyndina af því sem er að gerast.
Greinin kynnir vinsælustu og vinsælustu verkfærin og sýnir hvernig á að nota þau til að byggja upp sjálfvirkniinnviði skref fyrir skref. Hver hópur er táknaður með verkfærum sem hafa verið prófuð með persónulegri reynslu. En það þýðir ekki að þú þurfir að nota það sama. Verkfærin sjálf eru ekki mikilvæg, þau birtast og verða úrelt. Verkfræðiverkefni okkar er að skilja grunnreglurnar: hvers vegna við þurfum þennan hóp verkfæra og hvaða vinnuvandamál við getum leyst með hjálp þeirra. Þess vegna skil ég eftir í lok hvers hluta tengla á svipuð verkfæri sem gætu verið notuð í fyrirtækinu þínu.
Hvað er ekki í þessari grein
Ég endurtek enn og aftur að greinin fjallar ekki um ákveðin verkfæri, þannig að það verður engin innskot af kóða úr skjölunum og lýsingum á tilteknum skipunum. En í lok hvers hluta skil ég eftir hlekki fyrir nákvæma rannsókn.
Þetta er gert vegna þess að:
- þetta efni er mjög auðvelt að finna í ýmsum heimildum (skjölum, bókum, myndbandsnámskeiðum);
- ef við förum að fara dýpra, verðum við að skrifa 10, 20, 30 hluta þessarar greinar (á meðan áætlanirnar eru 2-3);
- Ég vil bara ekki eyða tíma þínum þar sem þú gætir viljað nota önnur tæki til að ná sömu markmiðum.
Practice
Ég myndi virkilega vilja að þetta efni væri gagnlegt fyrir alla lesendur, en ekki bara lesið og gleymt. Í hvaða námi sem er er æfing mjög mikilvægur þáttur. Fyrir þetta hef ég undirbúið mig. Það er líka heimavinna sem bíður þín til að ganga úr skugga um að þú afritar ekki áhyggjulaust línurnar í skipunum sem þú ert að framkvæma.
Áætlun
Skref
Tækni
Verkfæri
1
Staðbundin keyrsla (undirbúið vef- / Android kynningarpróf og keyrðu það á staðnum)
Node.js, Selen, Appium
2
Útgáfustýringarkerfi
fara
3
Gámavæðing
Docker, Selenium grid, Selenoid (vefur, Android)
4
CI/CD
Gitlab CI
5
Skýpallar
Google Cloud Platform
6
Útfærsla
Kubernetes
7
Innviði sem kóða (IaC)
Terraform, Ansible
Uppbygging hvers hluta
Til að halda frásögninni skýrri er hverjum kafla lýst í samræmi við eftirfarandi útlínur:
- stutt lýsing á tækninni,
- gildi fyrir sjálfvirkni innviði,
- mynd af núverandi ástandi innviða,
- tenglar á nám,
- svipuð verkfæri.
1. Keyrðu prófanir á staðnum
Stutt lýsing á tækninni
Þetta er bara undirbúningsskref til að keyra kynningarprófin á staðnum og sannreyna að þau standist. Í verklega hlutanum er Node.js notað en forritunarmálið og vettvangurinn skipta heldur ekki máli og þú getur notað þau sem eru notuð í þínu fyrirtæki.
Hins vegar, sem sjálfvirkniverkfæri, mæli ég með því að nota Selenium WebDriver fyrir vefpalla og Appium fyrir Android pallinn, í sömu röð, þar sem í næstu skrefum munum við nota Docker myndir sem eru sérsniðnar til að vinna sérstaklega með þessum verkfærum. Þar að auki, með vísan til starfskröfur, eru þessi verkfæri eftirsóttust á markaðnum.
Eins og þú hefur kannski tekið eftir, tökum við aðeins tillit til vef- og Androidprófa. Því miður er iOS allt önnur saga (takk Apple). Ég ætla að sýna IOS tengdar lausnir og venjur í komandi hlutum.
Gildi fyrir innviði sjálfvirkni
Frá sjónarhóli innviða veitir hlaup á staðnum engin verðmæti. Þú athugar aðeins að prófin keyri á staðbundinni vél í staðbundnum vöfrum og hermum. En í öllu falli er þetta nauðsynlegt upphafspunktur.
Mynd af núverandi stöðu innviða
Tenglar til að skoða
Svipuð verkfæri
- hvaða forritunarmál sem þú vilt í tengslum við Selenium/Appium próf;
- hvaða próf sem er;
- hvaða tilraunahlaupara sem er.
2. Útgáfustýringarkerfi (Git)
Stutt lýsing á tækninni
Það verður ekki mikil opinberun fyrir neinn ef ég segi að útgáfustýring sé afar mikilvægur þáttur í þróun, bæði í hópi og einstaklingsbundnum. Miðað við ýmsar heimildir er óhætt að segja að Git sé vinsælasti fulltrúinn. Útgáfustýringarkerfi veitir marga kosti, svo sem deilingu kóða, geymsla útgáfur, endurheimt í fyrri útibú, eftirlit með verkefnasögu og afrit. Við munum ekki ræða hvert atriði í smáatriðum, þar sem ég er viss um að þú þekkir það vel og notar það í daglegu starfi þínu. En ef allt í einu ekki, þá mæli ég með því að gera hlé á lestri þessarar greinar og fylla þetta skarð eins fljótt og auðið er.
Gildi fyrir innviði sjálfvirkni
Og hér geturðu spurt sanngjarnrar spurningar: „Af hverju er hann að segja okkur frá Git? Þetta vita allir og nota það bæði fyrir þróunarkóða og fyrir sjálfvirka prófunarkóða.“ Það er alveg rétt hjá þér, en í þessari grein erum við að tala um innviði og þessi hluti virkar sem forskoðun fyrir hluta 7: „Infrastructure as Code (IaC)“. Fyrir okkur þýðir þetta að öllum innviðum, þar með talið prófunum, er lýst í formi kóða, þannig að við getum líka beitt útgáfukerfi á hann og fengið svipaðan ávinning og fyrir þróunar- og sjálfvirknikóða.
Við munum skoða IaC nánar í skrefi 7, en jafnvel núna geturðu byrjað að nota Git á staðnum með því að búa til staðbundna geymslu. Stóra myndin verður stækkuð þegar við bætum fjargeymslu við innviðina.
Mynd af núverandi stöðu innviða
Tenglar til að skoða
Svipuð verkfæri
3. Gámavæðing (Docker)
Stutt lýsing á tækninni
Til að sýna fram á hvernig gámavæðing hefur breytt leikreglunum skulum við fara aftur í tímann nokkra áratugi. Á þeim tíma keypti fólk og notaði netþjónavélar til að keyra forrit. En í flestum tilfellum var ekki vitað um nauðsynlegar ræsingarauðlindir fyrirfram. Þess vegna eyddu fyrirtæki peningum í kaup á dýrum, öflugum netþjónum, en hluti þessarar getu var ekki fullnýttur.
Næsta stig þróunar voru sýndarvélar (VMs), sem leystu vandamálið við að sóa peningum í ónotaðar auðlindir. Þessi tækni gerði það mögulegt að keyra forrit óháð hvert öðru innan sama netþjóns og úthlutaði algjörlega einangruðu plássi. En því miður hefur hvaða tækni sína galla. Að keyra VM krefst fulls stýrikerfis, sem eyðir örgjörva, vinnsluminni, geymsluplássi og, allt eftir stýrikerfinu, þarf að taka tillit til leyfiskostnaðar. Þessir þættir hafa áhrif á hleðsluhraða og gera færanleika erfitt.
Og nú komum við að gámavæðingu. Enn og aftur leysir þessi tækni fyrra vandamálið, þar sem gámar nota ekki fullt stýrikerfi, sem losar um mikið magn af auðlindum og veitir hraðvirka og sveigjanlega lausn fyrir færanleika.
Auðvitað er gámatæknin ekkert nýtt og var fyrst kynnt seint á áttunda áratugnum. Í þá daga voru gerðar miklar rannsóknir, þróun og tilraunir. En það var Docker sem aðlagaði þessa tækni og gerði hana aðgengilega fyrir fjöldann. Nú á dögum, þegar við tölum um gáma, er í flestum tilfellum átt við Docker. Þegar við tölum um Docker gáma er átt við Linux gáma. Við getum notað Windows og macOS kerfi til að keyra gáma, en það er mikilvægt að skilja að í þessu tilfelli birtist viðbótarlag. Til dæmis, Docker á Mac keyrir gáma hljóðlaust inni í léttu Linux VM. Við munum snúa aftur að þessu efni þegar við ræðum um að keyra Android keppinauta inni í gámum, svo hér er mjög mikilvægur blær sem þarf að ræða nánar.
Gildi fyrir innviði sjálfvirkni
Við komumst að því að gámavæðing og Docker eru flott. Við skulum skoða þetta í samhengi við sjálfvirkni, því hvert tæki eða tækni þarf að leysa vandamál. Við skulum gera grein fyrir augljósum vandamálum við sjálfvirkni prófa í samhengi við HÍ próf:
- gríðarlegur fjöldi ósjálfstæðis þegar selen er sett upp og sérstaklega Appium;
- samhæfnisvandamál milli útgáfur vafra, herma og rekla;
- skortur á einangruðu plássi fyrir vafra/herma, sem er sérstaklega mikilvægt fyrir samhliða keyrslu;
- erfitt að stjórna og viðhalda ef þú þarft að keyra 10, 50, 100 eða jafnvel 1000 vafra á sama tíma.
En þar sem Selen er vinsælasta sjálfvirkniverkfærið og Docker er vinsælasta gámavæðingartækið ætti það ekki að koma á óvart að einhver hafi reynt að sameina þau til að búa til öflugt tól til að leysa ofangreind vandamál. Við skulum íhuga slíkar lausnir nánar.
Selen rist í docker
Þetta tól er það vinsælasta í Selenium heiminum til að keyra marga vafra á mörgum vélum og stjórna þeim frá miðlægri miðstöð. Til að byrja þarftu að skrá að minnsta kosti 2 hluta: Hub og Node(s). Hub er miðlægur hnútur sem tekur við öllum beiðnum úr prófunum og dreifir þeim til viðeigandi hnúta. Fyrir hvern hnút getum við stillt ákveðna stillingu, til dæmis með því að tilgreina viðkomandi vafra og útgáfu hans. Hins vegar þurfum við samt að sjá um samhæfa vafrarekla sjálf og setja þá upp á viðkomandi hnúta. Af þessum sökum er Selenium grid ekki notað í sinni hreinu mynd, nema þegar við þurfum að vinna með vafra sem ekki er hægt að setja upp á Linux OS. Í öllum öðrum tilvikum væri verulega sveigjanleg og rétt lausn að nota Docker myndir til að keyra Selenium grid Hub og Nodes. Þessi nálgun einfaldar mjög hnútastjórnun, þar sem við getum valið myndina sem við þurfum með samhæfum útgáfum af vöfrum og rekla sem þegar eru uppsettar.
Þrátt fyrir neikvæðar umsagnir um stöðugleika, sérstaklega þegar verið er að keyra mikinn fjölda hnúta samhliða, er selennet enn vinsælasta tækið til að keyra selenpróf samhliða. Það er mikilvægt að hafa í huga að ýmsar endurbætur og breytingar á þessu tóli eru stöðugt að birtast í opnum hugbúnaði, sem berjast gegn ýmsum flöskuhálsum.
Selenoid fyrir vefinn
Þetta tól er bylting í heimi Selen þar sem það virkar beint úr kassanum og hefur gert líf margra sjálfvirkniverkfræðinga miklu auðveldara. Í fyrsta lagi er þetta ekki önnur breyting á selenneti. Þess í stað bjuggu verktakarnir til alveg nýja útgáfu af Selenium Hub í Golang, sem ásamt léttum Docker myndum fyrir ýmsa vafra ýtti undir þróun sjálfvirkni prófunar. Þar að auki, þegar um Selenium Grid er að ræða, verðum við að ákvarða alla nauðsynlega vafra og útgáfur þeirra fyrirfram, sem er ekki vandamál þegar unnið er með aðeins einn vafra. En þegar kemur að mörgum studdum vöfrum, er Selenoid lausn númer eitt þökk sé „vafra á eftirspurn“ eiginleikanum. Allt sem þarf af okkur er að hlaða niður nauðsynlegum myndum með vöfrum fyrirfram og uppfæra stillingarskrána sem Selenoid hefur samskipti við. Eftir að Selenoid hefur fengið beiðni frá prófunum mun það sjálfkrafa ræsa viðkomandi ílát með viðkomandi vafra. Þegar prófinu lýkur mun Selenoid hætta ílátinu og þar með losa um fjármagn fyrir framtíðarbeiðnir. Þessi nálgun útrýmir algjörlega hinu vel þekkta vandamáli við „hnútsrýrnun“ sem við lendum oft í selenneti.
En, því miður, Selenoid er samt ekki silfurkúla. Við fengum „vafra á eftirspurn“ eiginleikann, en „tilföng á eftirspurn“ eiginleikinn er enn ekki tiltækur. Til að nota Selenoid verðum við að dreifa því á líkamlegan vélbúnað eða á VM, sem þýðir að við verðum að vita fyrirfram hversu mörgum tilföngum þarf að úthluta. Ég býst við að þetta sé ekki vandamál fyrir lítil verkefni sem keyra 10, 20 eða jafnvel 30 vafra samhliða. En hvað ef við þurfum 100, 500, 1000 eða meira? Það þýðir ekkert að viðhalda og borga fyrir svo mikið fjármagn allan tímann. Í köflum 5 og 6 í þessari grein munum við fjalla um lausnir sem gera þér kleift að stækka og draga þannig verulega úr kostnaði fyrirtækisins.
Selenoid fyrir Android
Eftir velgengni Selenoid sem sjálfvirkni á vefnum vildu fólk fá eitthvað svipað fyrir Android. Og það gerðist - Selenoid var gefið út með Android stuðningi. Frá sjónarhóli notenda á háu stigi er aðgerðareglan svipuð og sjálfvirkni vefsins. Eini munurinn er sá að í stað vafraíláta keyrir Selenoid Android hermiílát. Að mínu mati er þetta öflugasta ókeypis tólið til að keyra Android próf samhliða.
Ég myndi ekki vilja tala um neikvæðu hliðarnar á þessu tóli, þar sem mér líkar það mjög vel. En samt eru sömu ókostir og eiga við um sjálfvirkni á vefnum og tengjast skala. Í viðbót við þetta þurfum við að tala um eina takmörkun í viðbót sem gæti komið á óvart ef við erum að setja upp tólið í fyrsta skipti. Til að keyra Android myndir þurfum við líkamlega vél eða VM með hreiðri sýndarvirkni. Í leiðbeiningunum sýni ég hvernig á að virkja þetta á Linux VM. Hins vegar, ef þú ert macOS notandi og vilt nota Selenoid á staðnum, þá verður þetta ekki hægt að keyra Android próf. En þú getur alltaf keyrt Linux VM á staðnum með 'nested virtualization' stillt og sett inn Selenoid inni.
Mynd af núverandi stöðu innviða
Í tengslum við þessa grein munum við bæta við 2 verkfærum til að sýna innviðina. Þetta eru Selenium grid fyrir vefpróf og Selenoid fyrir Android próf. Í GitHub kennslunni mun ég líka sýna þér hvernig á að nota Selenoid til að keyra vefpróf.
Tenglar til að skoða
Svipuð verkfæri
- Það eru önnur gámaverkfæri, en Docker er vinsælast. Ef þú vilt prófa eitthvað annað, hafðu í huga að verkfærin sem við höfum fjallað um til að keyra selenpróf samhliða virka ekki út úr kassanum.
- Eins og áður hefur komið fram eru margar breytingar á selenneti, til dæmis,.
4.CI/CD
Stutt lýsing á tækninni
Ástundun stöðugrar samþættingar er nokkuð vinsæl í þróun og er á pari við útgáfustýringarkerfi. Þrátt fyrir þetta finnst mér vera rugl í hugtökum. Í þessari málsgrein langar mig að lýsa 3 breytingum á þessari tækni frá mínu sjónarhorni. Á netinu finnur þú margar greinar með mismunandi túlkun og það er alveg eðlilegt ef skoðun þín er ólík. Það mikilvægasta er að þú sért á sömu blaðsíðu með samstarfsfólki þínu.
Svo, það eru 3 hugtök: CI - Continuous Integration, CD - Continuous Delivery og aftur CD - Continuous Deployment. (Hér að neðan mun ég nota þessi hugtök á ensku). Hver breyting bætir nokkrum viðbótarskrefum við þróunarleiðsluna þína. En orðið samfelld (samfellt) er það mikilvægasta. Í þessu samhengi er átt við eitthvað sem gerist frá upphafi til enda, án truflana eða handvirkra inngripa. Skoðum CI & CD og CD í þessu samhengi.
- Stöðug samþætting þetta er fyrsta skref þróunar. Eftir að hafa sent inn nýjan kóða til þjónsins, gerum við ráð fyrir að fá skjót viðbrögð um að breytingar okkar séu í lagi. Venjulega inniheldur CI keyrslu á kyrrstæðum kóða greiningarverkfærum og eininga/innri API prófum. Þetta gerir okkur kleift að fá upplýsingar um kóðann okkar innan nokkurra sekúndna/mínútna.
- Stöðug Afhending er lengra skref þar sem við keyrum samþættingar/UI próf. Hins vegar, á þessu stigi, fáum við ekki niðurstöður eins fljótt og með CI. Í fyrsta lagi taka þessar tegundir prófa lengri tíma að ljúka. Í öðru lagi, áður en við hleypt af stokkunum, verðum við að setja breytingar okkar á prófunar-/sviðsetningarumhverfið. Þar að auki, ef við erum að tala um farsímaþróun, þá virðist viðbótarskref til að búa til smíði á forritinu okkar.
- Stöðug dreifing gerir ráð fyrir að við gefum breytingar okkar sjálfkrafa út í framleiðslu ef öll staðfestingarpróf hafa verið staðin á fyrri stigum. Að auki, eftir útgáfustigið, geturðu stillt ýmis stig, svo sem að keyra reykpróf á framleiðslu og safna mælingum sem vekja áhuga. Stöðug dreifing er aðeins möguleg með góðri umfjöllun með sjálfvirkum prófum. Ef þörf er á handvirkum inngripum, þar á meðal prófun, þá er þetta ekki lengur Stöðug (samfellt). Þá getum við sagt að leiðslan okkar samræmist aðeins venju um stöðuga afhendingu.
Gildi fyrir innviði sjálfvirkni
Í þessum kafla ætti ég að skýra að þegar við tölum um end-to-end UI próf þýðir það að við ættum að dreifa breytingum okkar og tengdri þjónustu til að prófa umhverfi. Stöðug samþætting - ferlið á ekki við um þetta verkefni og við verðum að sjá um að innleiða að minnsta kosti Stöðugar skilaaðferðir. Continuous Deployment er líka skynsamlegt í samhengi við HÍ próf ef við ætlum að keyra þau í framleiðslu.
Og áður en við skoðum lýsinguna á arkitektúrbreytingunni vil ég segja nokkur orð um GitLab CI. Ólíkt öðrum CI/CD verkfærum, býður GitLab upp á fjargeymslu og marga aðra viðbótareiginleika. Þannig er GitLab meira en CI. Það felur í sér frumkóðastjórnun, lipur stjórnun, CI/CD leiðslur, skógarhöggverkfæri og mælikvarðasöfnun úr kassanum. GitLab arkitektúrinn samanstendur af Gitlab CI/CD og GitLab Runner. Hér er stutt lýsing frá opinberu vefsíðunni:
Gitlab CI/CD er vefforrit með API sem geymir ástand sitt í gagnagrunni, stjórnar verkefnum/smíðum og veitir notendaviðmót. GitLab Runner er forrit sem vinnur úr smíðum. Það er hægt að nota það sérstaklega og virkar með GitLab CI/CD í gegnum API. Fyrir próf í gangi þarftu bæði Gitlab dæmi og Runner.
Mynd af núverandi stöðu innviða
Tenglar til að skoða
Svipuð verkfæri
- Og margir aðrir
5. Skýjapallar
Stutt lýsing á tækninni
Í þessum hluta munum við tala um vinsæla þróun sem kallast „opinber ský“. Þrátt fyrir gífurlegan ávinning sem sýndarvæðingar- og gámatæknin sem lýst er hér að ofan veita, þurfum við samt tölvuauðlindir. Fyrirtæki kaupa dýra netþjóna eða leigja gagnaver, en í þessu tilviki þarf að gera útreikninga (stundum óraunhæfa) á hversu mikið fjármagn við munum þurfa, hvort við notum þau allan sólarhringinn og í hvaða tilgangi. Til dæmis, framleiðsla krefst netþjóns sem keyrir 24/7, en þurfum við svipað úrræði til að prófa utan vinnutíma? Það fer líka eftir því hvers konar prófun er gerð. Sem dæmi má nefna álags-/álagspróf sem við ætlum að framkvæma á óvinnutíma til að fá niðurstöður daginn eftir. En vissulega er ekki þörf á aðgengi að netþjóni allan sólarhringinn fyrir sjálfvirk próf frá enda til enda og sérstaklega ekki fyrir handvirkt prófunarumhverfi. Við slíkar aðstæður væri gott að fá eins mikið úrræði og þörf krefur, nota þau og hætta að borga þegar þeirra er ekki lengur þörf. Þar að auki væri frábært að taka á móti þeim samstundis með því að smella með nokkrum músum eða keyra nokkrar forskriftir. Þetta er það sem opinber ský eru notuð til. Við skulum skoða skilgreininguna:
„Almenna skýið er skilgreint sem tölvuþjónusta sem þriðju aðila bjóða upp á á internetinu, sem gerir hana aðgengilega öllum sem vilja nota eða kaupa hana. Þeir geta verið ókeypis eða seldir á eftirspurn, sem gerir viðskiptavinum kleift að borga aðeins fyrir hverja notkun fyrir örgjörvaloturnar, geymsluna eða bandbreiddina sem þeir neyta.“
Það er skoðun að almenningsský séu dýr. En lykilhugmynd þeirra er að draga úr kostnaði fyrirtækisins. Eins og fyrr segir gera opinber ský þér kleift að fá auðlindir á eftirspurn og borga aðeins fyrir þann tíma sem þú notar þau. Einnig gleymum við stundum að starfsmenn fá laun og sérfræðingar eru líka dýr auðlind. Það verður að taka með í reikninginn að opinber ský gera stuðning innviða mun auðveldari, sem gerir verkfræðingum kleift að einbeita sér að mikilvægari verkefnum.
Gildi fyrir innviði sjálfvirkni
Hvaða sértæka úrræði þurfum við fyrir end-to-end UI próf? Í grundvallaratriðum eru þetta sýndarvélar eða klasar (við munum tala um Kubernetes í næsta kafla) til að keyra vafra og keppinauta. Því fleiri vafra og keppinauta sem við viljum keyra samtímis, því meiri örgjörva og minni þarf og því meiri pening þurfum við að borga fyrir það. Þannig gera opinber ský í samhengi við sjálfvirkni prófunar okkur kleift að keyra mikinn fjölda (100, 200, 1000...) vafra/herma eftir beiðni, fá prófunarniðurstöður eins fljótt og auðið er og hætta að borga fyrir svona brjálæðislega auðlindafrekt krafti.
Vinsælustu skýjaveiturnar eru Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Leiðbeiningin gefur dæmi um hvernig á að nota GCP, en almennt skiptir ekki máli hvað þú notar fyrir sjálfvirkni. Þeir veita allir um það bil sömu virkni. Venjulega, til að velja þjónustuaðila, einbeita stjórnendur sér að heildarinnviðum og viðskiptakröfum fyrirtækisins, sem er utan gildissviðs þessarar greinar. Fyrir sjálfvirkniverkfræðinga verður áhugaverðara að bera saman notkun skýjaveitna við notkun skýjapalla sérstaklega í prófunartilgangi, svo sem Sauce Labs, BrowserStack, BitBar, og svo framvegis. Svo við skulum gera það líka! Að mínu mati er Sauce Labs frægasta skýprófunarbúið, þess vegna notaði ég það til samanburðar.
GCP vs Sauce Labs í sjálfvirkni tilgangi:
Ímyndum okkur að við þurfum að keyra 8 vefpróf og 8 Android próf samtímis. Til þess munum við nota GCP og keyra 2 sýndarvélar með Selenoid. Á þeim fyrri munum við hækka 8 gáma með vöfrum. Á þeim seinni eru 8 ílát með hermi. Við skulum skoða verðið:
Til að keyra einn gám með Chrome þurfum við n1-staðall-1 bíll. Í tilviki Android mun það vera n1-staðall-4 fyrir einn keppinaut. Reyndar er sveigjanlegri og ódýrari leið að setja ákveðin notendagildi fyrir CPU/Minni, en í augnablikinu er þetta ekki mikilvægt til samanburðar við Sauce Labs.
Og hér eru gjaldskrár fyrir notkun Sauce Labs:
Ég tel að þú hafir þegar tekið eftir muninum, en ég mun samt gefa töflu með útreikningum fyrir verkefni okkar:
Nauðsynleg úrræði
Mánaðarlega
Vinnutími(8:8 - XNUMX:XNUMX)
Vinnutími+ Forystan
GCP fyrir vefinn
n1-staðall-1 x 8 = n1-staðall-8
$194.18
23 dagar * 12 klst * 0.38 = $104.88
23 dagar * 12 klst * 0.08 = $22.08
Sauce Labs fyrir vefinn
Sýndarskýja8 samhliða próf
$1.559
-
-
GCP fyrir Android
n1-staðall-4 x 8: n1-staðall-16
$776.72
23 dagar * 12 klst * 1.52 = $419.52
23 dagar * 12 klst * 0.32 = $88.32
Sauce Labs fyrir Android
Real Device Cloud 8 samhliða próf
$1.999
-
-
Eins og þú sérð er munurinn á kostnaði gríðarlegur, sérstaklega ef þú keyrir próf aðeins á tólf klukkustunda vinnutímabili. En þú getur dregið úr kostnaði enn frekar ef þú notar forgangsvélar. Hvað er það?
Fortakanleg VM er tilvik sem þú getur búið til og keyrt á mun lægra verði en venjuleg tilvik. Hins vegar gæti Compute Engine hætt (koma í veg fyrir) þessi tilvik ef hún krefst aðgangs að þessum auðlindum fyrir önnur verkefni. Fordæmanleg tilvik eru umfram Compute Engine getu, þannig að framboð þeirra er mismunandi eftir notkun.
Ef forritin þín eru bilunarþolin og þola hugsanlegar undantekningar á tilvikum, þá geta forfallanleg tilvik dregið verulega úr Compute Engine kostnaðinum þínum. Til dæmis geta runuvinnslur keyrt á fordæmanlegum tilvikum. Ef sumum þessara tilvika lýkur meðan á vinnslu stendur hægir á verkinu en hættir ekki alveg. Fordæmanleg tilvik ljúka lotuvinnsluverkefnum þínum án þess að leggja aukið vinnuálag á núverandi tilvik og án þess að þú þurfir að greiða fullt verð fyrir venjuleg tilvik til viðbótar.
Og það er enn ekki búið! Í raun og veru er ég viss um að enginn keyrir próf í 12 tíma án hlés. Og ef svo er, þá geturðu sjálfkrafa ræst og stöðvað sýndarvélar þegar þeirra er ekki þörf. Raunverulegur notkunartími getur minnkað í 6 klukkustundir á dag. Þá mun greiðslan í tengslum við verkefni okkar lækka í $11 á mánuði fyrir 8 vafra. Er þetta ekki dásamlegt? En með útfellanlegum vélum verðum við að vera varkár og viðbúin truflunum og óstöðugleika, þó að hægt sé að sjá um þessar aðstæður og meðhöndla þær í hugbúnaði. Það er þess virði!
En ég er alls ekki að segja „notaðu aldrei skýjaprófunarbæi“. Þeir hafa ýmsa kosti. Í fyrsta lagi er þetta ekki bara sýndarvél, heldur fullgild prófunarlausn fyrir sjálfvirkni með virkni úr kassanum: fjaraðgangur, annálar, skjámyndir, myndbandsupptaka, ýmsa vafra og líkamlega farsíma. Í mörgum aðstæðum getur þetta verið ómissandi flottur valkostur. Prófunarvettvangar eru sérstaklega gagnlegir fyrir IOS sjálfvirkni, þegar opinber ský geta aðeins boðið upp á Linux/Windows kerfi. En við munum tala um iOS í eftirfarandi greinum. Ég mæli með því að horfa alltaf á stöðuna og byrja á verkefnunum: í sumum tilfellum er ódýrara og skilvirkara að nota almenningsský og í öðrum eru prófunarpallarnir svo sannarlega peninganna virði.
Mynd af núverandi stöðu innviða
Tenglar til að skoða
Svipuð verkfæri:
6. Hljómsveit
Stutt lýsing á tækninni
Ég hef góðar fréttir - við erum næstum á enda greinarinnar! Í augnablikinu samanstendur sjálfvirkniinnviði okkar af vef- og Android prófum, sem við keyrum í gegnum GitLab CI samhliða, með því að nota Docker-virkt verkfæri: Selenium grid og Selenoid. Þar að auki notum við sýndarvélar búnar til í gegnum GCP til að hýsa gáma með vöfrum og hermi. Til að draga úr kostnaði ræsum við þessar sýndarvélar aðeins eftir beiðni og hættum þeim þegar prófanir eru ekki gerðar. Er eitthvað annað sem getur bætt innviði okkar? Svarið er já! Hittu Kubernetes (K8s)!
Fyrst skulum við skoða hvernig orðin hljómsveit, þyrping og Kubernetes tengjast hvert öðru. Á háu stigi er hljómsveitarstjórn kerfið sem setur upp og stjórnar forritum. Fyrir sjálfvirkni prófunar eru slík gámaforrit Selenium grid og Selenoid. Docker og K8s bæta hvort annað upp. Sá fyrsti er notaður fyrir dreifingu forrita, sá síðari fyrir hljómsveitarsetningu. Aftur á móti er K8s klasi. Verkefni klasans er að nota VM sem hnúta, sem gerir þér kleift að setja upp ýmsa virkni, forrit og þjónustu innan eins netþjóns (klasa). Ef einhver af hnútunum mistakast munu aðrir hnútar taka upp, sem tryggir ótruflaðan rekstur forritsins okkar. Í viðbót við þetta hefur K8s mikilvæga virkni sem tengist stærðarstærð, þökk sé henni fáum við sjálfkrafa ákjósanlegasta magn af auðlindum miðað við álag og sett mörk.
Í sannleika sagt er það alls ekki léttvægt verkefni að dreifa Kubernetes handvirkt frá grunni. Ég skil eftir hlekk á fræga leiðarvísirinn „Kubernetes The Hard Way“ og ef þú hefur áhuga geturðu æft það. En sem betur fer eru aðrar aðferðir og verkfæri. Auðveldasta leiðin er að nota Google Kubernetes Engine (GKE) í GCP, sem gerir þér kleift að fá tilbúinn klasa með nokkrum smellum. Ég mæli með því að nota þessa nálgun til að byrja að læra, þar sem hún gerir þér kleift að einbeita þér að því að læra hvernig á að nota K8s fyrir verkefni þín í stað þess að læra hvernig innri hluti ætti að vera samþættur hver við annan.
Gildi fyrir innviði sjálfvirkni
Við skulum skoða nokkra mikilvæga eiginleika sem K8s býður upp á:
- dreifing forrita: með því að nota fjölhnútaþyrping í stað VM;
- kraftmikil mælikvarði: dregur úr kostnaði við auðlindir sem eru aðeins notaðar á eftirspurn;
- sjálfsheilun: sjálfvirk endurheimt fræbelgja (sem afleiðing þess að ílát eru einnig endurheimt);
- uppfærsla á uppfærslum og afturköllun breytinga án niður í miðbæ: uppfærsluverkfæri, vafrar og keppinautar trufla ekki vinnu núverandi notenda
En K8s er samt ekki silfurkúla. Til að skilja alla kosti og takmarkanir í samhengi við tækin sem við erum að íhuga (Selenium grid, Selenoid), munum við fjalla stuttlega um uppbyggingu K8s. Þyrping inniheldur tvær tegundir af hnútum: Master Nodes og Workers Nodes. Master Nodes eru ábyrgir fyrir stjórnun, dreifingu og tímasetningarákvörðunum. Starfsmannahnútar eru þar sem forrit eru ræst. Hnútar innihalda einnig gámakeyrsluumhverfi. Í okkar tilviki er þetta Docker, sem ber ábyrgð á gámatengdri starfsemi. En það eru líka aðrar lausnir, til dæmis. Mikilvægt er að skilja að hölkun eða sjálfsheilun á ekki beint við ílát. Þetta er útfært með því að bæta við/fækka belgjum, sem aftur innihalda ílát (venjulega eitt ílát á hvert belg, en eftir verkefninu geta þeir verið fleiri). Stigveldið á háu stigi samanstendur af starfsmannahnútum, inni í þeim eru belg, þar sem gámar eru hækkaðir.
Stærðareiginleikinn er lykillinn og hægt er að nota hann á bæði hnúta innan hnútahóps klasa og belg innan hnúts. Það eru 2 tegundir af mælikvarða sem eiga við um bæði hnúta og fræbelg. Fyrsta tegundin er lárétt - mælikvarði á sér stað með því að fjölga hnútum/belgjum. Þessi tegund er æskilegri. Önnur gerð er því lóðrétt. Kvörðun er framkvæmd með því að auka stærð hnúta/belgja, en ekki fjölda þeirra.
Nú skulum við líta á verkfæri okkar í samhengi við ofangreind skilmála.
Selen rist
Eins og fyrr segir er selennet mjög vinsælt tæki og það kemur ekki á óvart að það hafi verið sett í gáma. Þess vegna kemur það ekki á óvart að hægt sé að nota selennet í K8s. Dæmi um hvernig á að gera þetta er að finna í opinberu K8s geymslunni. Eins og venjulega læt ég tengla fylgja í lok kaflans. Að auki sýnir leiðarvísirinn hvernig á að gera þetta í Terraform. Það eru líka leiðbeiningar um hvernig á að skala fjölda belg sem innihalda vafraílát. En sjálfvirka skalunaraðgerðin í samhengi við K8s er samt ekki alveg augljóst verkefni. Þegar ég byrjaði að læra fann ég engar hagnýtar leiðbeiningar eða ráðleggingar. Eftir nokkrar rannsóknir og tilraunir með stuðningi DevOps teymisins völdum við þá nálgun að hækka ílát með nauðsynlegum vöfrum inni í einum belg, sem er staðsettur inni í einum starfshnút. Þessi aðferð gerir okkur kleift að beita stefnunni um lárétta skala hnúta með því að fjölga þeim. Ég vona að þetta breytist í framtíðinni og við munum sjá fleiri og fleiri lýsingar á betri aðferðum og tilbúnum lausnum, sérstaklega eftir útgáfu Selenium grid 4 með breyttum innri arkitektúr.
Selenoid:
Selenoid dreifing í K8s er nú mestu vonbrigðin. Þau eru ekki samhæf. Fræðilega séð getum við hækkað Selenoid gám inni í belg, en þegar Selenoid byrjar að ræsa gáma með vöfrum verða þeir samt inni í sama belg. Þetta gerir mælikvarða ómögulega og þar af leiðandi mun vinna Selenoid inni í klasa ekki vera frábrugðin vinnu í sýndarvél. Sögulok.
Moon:
Með því að þekkja þennan flöskuháls þegar þeir vinna með Selenoid gáfu verktaki út öflugra tól sem heitir Moon. Þetta tól var upphaflega hannað til að vinna með Kubernetes og þar af leiðandi er hægt og ætti að nota sjálfvirka stærðaraðgerðina. Þar að auki myndi ég segja að eins og er einn tól í selenheiminum, sem hefur innfæddan K8s klasastuðning úr kassanum (ekki lengur í boði, sjá næsta tól ). Helstu eiginleikar Moon sem veita þennan stuðning eru:
Alveg ríkisfangslaus. Selenoid geymir í minni upplýsingar um núverandi vafralotur. Ef ferlið þess hrynur af einhverjum ástæðum - þá tapast allar keyrslulotur. Moon hefur hins vegar ekkert innra ástand og hægt er að endurtaka það í gagnaverum. Vafralotur haldast lifandi jafnvel þó að ein eða fleiri eftirlíkingar fari niður.
Svo, Moon er frábær lausn, en það er eitt vandamál: það er ekki ókeypis. Verðið fer eftir fjölda lota. Þú getur aðeins keyrt 0-4 lotur ókeypis, sem er ekki sérstaklega gagnlegt. En frá og með fimmtu lotunni þarftu að borga $5 fyrir hvern. Staðan getur verið mismunandi eftir fyrirtækjum, en í okkar tilviki er tilgangslaust að nota Moon. Eins og ég lýsti hér að ofan getum við keyrt VMs með Selenium Grid á eftirspurn eða aukið fjölda hnúta í klasanum. Fyrir um það bil eina leiðslu ræsum við 500 vafra og stöðvum öll tilföng eftir að prófunum er lokið. Ef við notuðum Moon þyrftum við að borga aukalega 500 x 5 = $2500 á mánuði, sama hversu oft við keyrum próf. Aftur, ég er ekki að segja að þú notir ekki Moon. Fyrir verkefni þín getur þetta verið ómissandi lausn, til dæmis ef þú ert með mörg verkefni/teymi í fyrirtækinu þínu og þú þarft risastóran sameiginlegan klasa fyrir alla. Eins og alltaf skil ég eftir tengil í lokin og mæli með að gera alla nauðsynlega útreikninga í tengslum við verkefnið þitt.
Callisto: (Athugið! Þetta er ekki í upprunalegu greininni og er aðeins að finna í rússnesku þýðingunni)
Eins og ég sagði, Selen er mjög vinsælt tól og upplýsingatæknisviðið er að þróast mjög hratt. Á meðan ég var að vinna að þýðingunni birtist nýtt efnilegt tól sem heitir Callisto á vefnum (sæll Cypress og aðrir Selenium killers). Það virkar innbyggt með K8s og gerir þér kleift að keyra Selenoid ílát í belg, dreift yfir hnúta. Allt virkar beint úr kassanum, þar á meðal sjálfvirk stærð. Frábært, en þarf að prófa. Mér hefur þegar tekist að dreifa þessu tóli og keyra nokkrar tilraunir. En það er of snemmt að draga ályktanir, eftir að hafa fengið niðurstöður yfir langa vegalengd, kannski mun ég gera endurskoðun í framtíðargreinum. Í bili skil ég aðeins eftir tengla fyrir óháða rannsóknir.
Mynd af núverandi stöðu innviða
Tenglar til að skoða
Svipuð verkfæri
7. Innviði sem kóða (IAC)
Stutt lýsing á tækninni
Og nú komum við að síðasta kaflanum. Venjulega er þessi tækni og tengd verkefni ekki á ábyrgð sjálfvirkniverkfræðinga. Og það eru ástæður fyrir þessu. Í fyrsta lagi, í mörgum stofnunum, eru innviðamál undir stjórn DevOps deildarinnar og þróunarteymin eru ekki alveg sama um hvað fær leiðsluna til að virka og hvernig þarf að styðja allt sem tengist henni. Í öðru lagi, við skulum vera heiðarleg, er iðkun Infrastructure as Code (IaC) enn ekki tekin upp í mörgum fyrirtækjum. En það er svo sannarlega orðið vinsæl stefna og það er mikilvægt að reyna að taka þátt í ferlum, nálgun og verkfærum sem tengjast því. Eða að minnsta kosti vera uppfærður.
Við skulum byrja á hvatanum til að nota þessa aðferð. Við höfum þegar rætt um að til að keyra próf í GitlabCI þurfum við að minnsta kosti fjármagn til að keyra Gitlab Runner. Og til að keyra gáma með vöfrum/hermi þurfum við að panta VM eða klasa. Auk þess að prófa auðlindir þurfum við umtalsvert magn af getu til að styðja við þróun, sviðsetningu, framleiðsluumhverfi, sem inniheldur einnig gagnagrunna, sjálfvirkar áætlanir, netstillingar, álagsjafnara, notendaréttindi og svo framvegis. Lykilatriðið er átakið sem þarf til að standa undir þessu öllu. Það eru nokkrar leiðir sem við getum gert breytingar og sett upp uppfærslur. Til dæmis, í tengslum við GCP, getum við notað notendaviðmótið í vafranum og framkvæmt allar aðgerðir með því að smella á hnappa. Annar valkostur væri að nota API símtöl til að hafa samskipti við skýjaeiningar, eða nota gcloud skipanalínuforritið til að framkvæma viðeigandi meðhöndlun. En með mjög miklum fjölda mismunandi eininga og innviðaþátta verður erfitt eða jafnvel ómögulegt að framkvæma allar aðgerðir handvirkt. Þar að auki eru allar þessar handvirku aðgerðir óviðráðanlegar. Við getum ekki sent þær til skoðunar áður en þær eru framkvæmdar, notað útgáfustýringarkerfi og snúið fljótt til baka breytingarnar sem leiddu til atviksins. Til að leysa slík vandamál, bjuggu verkfræðingar til og bjuggu til sjálfvirk bash/skel forskriftir, sem eru ekki mikið betri en fyrri aðferðir, þar sem það er ekki svo auðvelt að lesa, skilja, viðhalda og breyta þeim í verklagsstíl.
Í þessari grein og leiðbeiningum nota ég 2 verkfæri sem tengjast IaC æfingum. Þetta eru Terraform og Ansible. Sumir telja að það sé ekkert vit í að nota þau á sama tíma, þar sem virkni þeirra er svipuð og þau eru skiptanleg. En staðreyndin er sú að í upphafi fá þeir allt önnur verkefni. Og sú staðreynd að þessi verkfæri ættu að bæta hvert annað var staðfest á sameiginlegri kynningu af hönnuðum sem eru fulltrúar HashiCorp og RedHat. Hugmyndalegi munurinn er sá að Terraform er úthlutunartæki til að stjórna netþjónunum sjálfum. Þó Ansible sé stillingarstjórnunartæki sem hefur það hlutverk að setja upp, stilla og stjórna hugbúnaði á þessum netþjónum.
Annar lykileinkenni þessara verkfæra er kóðunarstíll. Ólíkt bash og Ansible, notar Terraform yfirlýsingarstíl sem byggist á lýsingu á því lokaástandi sem óskað er eftir sem framkvæmd er. Til dæmis, ef við ætlum að búa til 10 VM og nota breytingarnar í gegnum Terraform, þá fáum við 10 VM. Ef við keyrum skriftuna aftur mun ekkert gerast þar sem við erum nú þegar með 10 VMs og Terraform veit um þetta vegna þess að það geymir núverandi stöðu innviða í ástandsskrá. En Ansible notar málsmeðferðaraðferð og ef þú biður hana um að búa til 10 VM, þá fáum við 10 VM, svipað og Terraform, við fyrstu kynningu. En eftir endurræsingu munum við nú þegar hafa 20 VM. Þetta er mikilvægi munurinn. Í málsmeðferðarstíl geymum við ekki núverandi ástand og lýsum einfaldlega röð skrefa sem þarf að framkvæma. Auðvitað getum við tekist á við ýmsar aðstæður, bætt við nokkrum athugunum á tilvist auðlinda og núverandi ástandi, en það þýðir ekkert að sóa tíma okkar og leggja okkur fram við að hafa stjórn á þessari rökfræði. Auk þess eykur þetta hættuna á mistökum.
Með því að draga saman allt ofangreint getum við ályktað að Terraform og yfirlýsingagerð séu hentugra tæki til að útvega netþjóna. En það er betra að fela Ansible vinnu við stillingarstjórnun. Með það úr vegi skulum við skoða notkunartilvik í samhengi við sjálfvirkni.
Gildi fyrir innviði sjálfvirkni
Það eina sem er mikilvægt að skilja hér er að líta á sjálfvirkniprófunarinnviðina sem hluta af öllu innviði fyrirtækisins. Þetta þýðir að öllum IaC starfsháttum verður að beita á heimsvísu fyrir auðlindir allrar stofnunarinnar. Hver ber ábyrgð á þessu fer eftir ferlum þínum. DevOps teymið er reyndari í þessum málum, það sér heildarmyndina af því sem er að gerast. Hins vegar eru QA verkfræðingar meira þátttakendur í ferli sjálfvirkni byggingar og uppbyggingu leiðslunnar, sem gerir þeim kleift að sjá betur allar nauðsynlegar breytingar og tækifæri til umbóta. Besti kosturinn er að vinna saman, skiptast á þekkingu og hugmyndum til að ná tilætluðum árangri.
Hér eru nokkur dæmi um notkun Terraform og Ansible í samhengi við sjálfvirkni prófunar og verkfærin sem við ræddum áður:
1. Lýstu nauðsynlegum eiginleikum og færibreytum VM og klasa sem nota Terraform.
2. Notaðu Ansible til að setja upp nauðsynleg verkfæri til að prófa: docker, Selenoid, Selenium Grid og hlaða niður nauðsynlegum útgáfum af vöfrum/hermi.
3. Notaðu Terraform til að lýsa eiginleikum VM þar sem GitLab Runner verður hleypt af stokkunum.
4. Settu upp GitLab Runner og nauðsynleg meðfylgjandi verkfæri með því að nota Ansible, stilltu stillingar og stillingar.
Mynd af núverandi stöðu innviða
Tenglar til að skoða:
Svipuð verkfæri
Við skulum draga það saman!
Skref
Tækni
Verkfæri
Gildi fyrir innviði sjálfvirkni
1
Staðbundið hlaup
Node.js, Selen, Appium
- Vinsælustu verkfærin fyrir vef og farsíma
- Styður mörg tungumál og vettvang (þar á meðal Node.js)
2
Útgáfustýringarkerfi
fara
- Svipaðir kostir með þróunarkóða
3
Gámavæðing
Docker, Selenium grid, Selenoid (vefur, Android)
- Að keyra próf samhliða
- Einangrað umhverfi
- Einfaldar, sveigjanlegar útgáfuuppfærslur
- Að stöðva ónotaðar auðlindir á virkan hátt
- Auðvelt að setja upp
4
CI/CD
Gitlab CI
- Prófar hluta leiðslunnar
- Fljótleg endurgjöf
- Sýnileiki fyrir allt fyrirtækið/liðið
5
Skýpallar
Google Cloud Platform
- Auðlindir á eftirspurn (við borgum aðeins þegar þörf krefur)
- Auðvelt að stjórna og uppfæra
- Sýnileiki og stjórn á öllum auðlindum
6
Útfærsla
Kubernetes
Í samhengi við ílát með vöfrum/hermi í belgjum:
- Skala/sjálfvirk stærð
- Sjálfslækning
- Uppfærslur og afturköllun án truflana
7
Innviði sem kóða (IaC)
Terraform, Ansible
- Svipaðir kostir með þróunarinnviði
- Allir kostir kóðaútgáfu
- Auðvelt að gera breytingar og viðhalda
- Alveg sjálfvirkt
Hugarkort skýringarmyndir: þróun innviða
skref 1: Staðbundið
skref 2: VCS
skref 3: Gámavæðing
skref 4: CI/CD
skref 5: Skýjapallar
skref 6: Hljómsveit
skref 7: IaC
Hvað er næst?
Svo, þetta er endirinn á greininni. En að lokum langar mig að gera nokkra samninga við þig.
Frá þinni hlið
Eins og ég sagði í upphafi myndi ég vilja að greinin nýtist vel og hjálpi þér að beita þekkingunni sem aflað er í raunverulegu starfi. Ég bæti aftur við.
En jafnvel eftir það skaltu ekki hætta, æfa þig, kynna þér viðeigandi tengla og bækur, finna út hvernig það virkar í fyrirtækinu þínu, finna staði sem hægt er að bæta og taka þátt í því. Gangi þér vel!
Frá minni hlið
Af titlinum má sjá að þetta var aðeins fyrsti hlutinn. Þrátt fyrir að það hafi reynst nokkuð stórt er enn ekki farið yfir mikilvæg efni hér. Í seinni hlutanum ætla ég að skoða sjálfvirkniinnviði í samhengi við IOS. Vegna takmarkana Apple á því að keyra iOS herma eingöngu á macOS kerfum er úrval lausna okkar þrengst. Til dæmis getum við ekki notað Docker til að keyra herminn eða opinber ský til að keyra sýndarvélar. En þetta þýðir ekki að það séu engir aðrir kostir. Ég mun reyna að halda þér uppfærðum með háþróaðar lausnir og nútímaleg verkfæri!
Einnig hef ég ekki nefnt mjög stór efni sem tengjast eftirliti. Í 3. hluta ætla ég að skoða vinsælustu innviðaeftirlitstækin og hvaða gögn og mælikvarðar þarf að hafa í huga.
Og að lokum. Í framtíðinni ætla ég að gefa út myndbandsnámskeið um að byggja upp prófunarinnviði og vinsæl verkfæri. Eins og er eru nokkur námskeið og fyrirlestrar um DevOps á netinu, en allt efni er sett fram í samhengi við þróun, ekki próf sjálfvirkni. Um þetta mál þarf ég virkilega álit á því hvort slíkt námskeið verði áhugavert og dýrmætt fyrir samfélag prófunaraðila og sjálfvirkniverkfræðinga. Með fyrirfram þökk!
Heimild: www.habr.com