Pjesa 1: Web / Android
Shënim: ky artikull është përkthim në shqip i artikullit origjinal Megjithatë, të gjitha ilustarimet, lidhjet, citimet dhe terminologjia janë ruajtur në gjuhën origjinale, për të shmangur ndonjë keqinterpretim gjatë përkthimit në shqip. Ju uroj një studim të këndshëm!
Aktualisht, ŃпДŃОалŃĐœĐŸŃŃŃĐ° DevOps Ă«shtĂ« njĂ« prej mĂ« tĂ« kĂ«rkuarave nĂ« industrinĂ« IT. NĂ«se hapni faqet e njohura pĂ«r kĂ«rkimin e punĂ«s dhe vendosni filtrin sipas pagave, do tĂ« shihni se ofertat e punĂ«s qĂ« lidhen me DevOps janĂ« nĂ« krye tĂ« listĂ«s. MegjithatĂ«, Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« kuptoni se kjo kryesisht i referohet pozites âSeniorâ, e cila nĂ«nkupton se kandidati ka njĂ« nivel tĂ« lartĂ« aftĂ«sish, njohuri pĂ«r teknologjitĂ« dhe mjetet. Kjo gjithashtu vjen me njĂ« shkallĂ« tĂ« lartĂ« pĂ«rgjegjĂ«sie, e lidhur me funksionimin pa ndĂ«rprerje tĂ« production. MegjithatĂ«, po harrojmĂ« çfarĂ« Ă«shtĂ« DevOps. Fillimisht nuk ishte ndonjĂ« person ose departament specifik. NĂ«se kĂ«rkojmĂ« pĂ«rkufizimet e kĂ«tij termi, do tĂ« gjejmĂ« shumĂ« emra tĂ« bukur dhe tĂ« saktĂ«, si metodologji, praktika, filozofia kulturore, grup konceputesh dhe kĂ«shtu me radhĂ«.
Specializimi im është inxhinier i automatizimit të testimit (QA automation engineer), por unë mendoj se ai nuk duhet të lidhet vetëm me shkruarjen e testeve automatike ose zhvillimin e arkitekturës së framework-ut për testim. Në vitin 2020, njohuritë për infrastrukturën e automatizimit gjithashtu janë të nevojshme. Kjo lejon organizimin e procesit të automatizimit vetë, duke filluar nga ekzekutimi i testeve dhe përfunduar me ofrimin e rezultateve për të gjithë palët e interesuara në përputhje me objektivat e caktuara. Si pasoje, aftësitë DevOps janë faktor të domosdoshëm për kryerjen e kësaj pune. Dhe gjithçka është mirë, por, fatkeqësisht, ka një problem (spoiler: ky artikull bën përpjekje për të thjeshtuar këtë problem). Ai lidhet me faktin se DevOps është e komplikuar. Dhe kjo është e dukshme, sepse kompanitë nuk do të paguajnë shumë për diçka që është e lehtë për t'u bërë... Në botën DevOps ka një numër të madh mjetesh, termash dhe praktikash që duhet të zotërohen. Sidomos është e vështirë në fillim të karrierës dhe varet nga përvoja teknike e grumbulluar.
Burimi:
KĂ«tu ndoshta do ta pĂ«rmbyllim pjesĂ«n hyrĂ«se dhe do tĂ« fokusohemi nĂ« qĂ«llimin e kĂ«tij artikulli.Â
Për çfarë është ky artikull
Në këtë artikull do të ndaj përvojën time në ndërtimin e infrastrukturës së automatizimit të testeve. Në internet mund të gjenden shumë burime informacioni në lidhje me mjete të ndryshme dhe si t'i përdorim ato, por do të donja t'i shqyrtoja ato ekskluzivisht në kontekstin e automatizimit. Besoj se shumica e inxhinierëve të automatizimit e njohin situatën kur testet e zhvilluara nuk janë ekzekutuar dhe nuk janë mbajtur përveçse nga vetë ju. Si rezultat, testet bëhen të vjetra dhe duhet të harxhohet kohë për t'i përditësuar. Edhe një herë, në fillim të karrierës, kjo mund të jetë një detyrë e vështirë: të vendosni se cilat mjete duhet të ndihmojnë për të zgjidhur këtë problem, si t'i zgjidhni ato, t'i konfiguroni dhe t'i mbani. Disa testues kërkojnë ndihmë nga DevOps (njerëzit) dhe, le të jemi të sinqertë, kjo qasje funksionon. Në shumë raste, kjo mund të jetë opsioni i vetëm, sepse na mungon pamja e të gjitha varësive. Por, siç e dimë, DevOps janë djem shumë të zënë, sepse ata duhet të mendojnë për infrastrukturën e gjithë kompanisë, për shpërndarjen, monitorimin, mikroshërbimet dhe detyra të tjera të ngjashme në varësi të organizatës/ekipit. Si zakonisht, automatizimi nuk është prioritet. Në këtë rast, duhet të përpiqemi të bëjmë gjithçka që është e mundur nga ana jonë nga fillimi deri në fund. Kjo do të zvogëlojë varësitë, do të përshpejtojë procesin e punës, do të përmirësojë aftësitë tona dhe do të na lejojë të shikojmë një pamje më të gjerë të asaj që po ndodh.
NĂ« artikull janĂ« paraqitur mjetet mĂ« tĂ« kĂ«rkuara dhe tĂ« njohura dhe tregohet si t'i pĂ«rdorni ato pĂ«r ndĂ«rtimin hap pas hapi tĂ« infrastrukturĂ«s sĂ« automatizimit. Ădo grup Ă«shtĂ« pĂ«rfaqĂ«suar me mjete qĂ« janĂ« provuar me pĂ«rvojĂ«n personale. Por kjo nuk do tĂ« thotĂ« se ju duhet tĂ« pĂ«rdorni tĂ« njĂ«jtat. VetĂ«m mjetet nuk janĂ« tĂ« rĂ«ndĂ«sishme, ato shfaqen dhe bĂ«hen tĂ« vjetra. Detyra jonĂ« inxhinierike Ă«shtĂ« tĂ« kuptojmĂ« parimet bazĂ«: pĂ«rse na nevojitet ky grup mjetesh dhe cilat detyra pune mund tĂ« zgjidhim me to. Prandaj, nĂ« pĂ«rfundim tĂ« çdo seksioni, lĂ« lidhje me mjete tĂ« ngjashme, qĂ« ndoshta pĂ«rdoren nĂ« organizatĂ«n tuaj.
ĂfarĂ« nuk ka nĂ« kĂ«tĂ« artikull
Rikuj për herë të dytë se artikulli nuk është për mjete specifike, prandaj nuk do të ketë inserte kodesh nga dokumentacioni dhe përshkrime të komandeve të caktuara. Por në fund të çdo seksioni, do të lë lidhje për studim më të hollësishëm.
Kjo Ă«shtĂ« bĂ«rĂ« pĂ«r shkak se:Â
- ky material është shumë lehtë për t'u gjetur në burime të ndryshme (dokumentacion, libra, kurse video);
- nëse fillojmë të thelloheni, do të duhet të shkruajmë 10, 20, 30 pjesë të këtij artikulli (kur në planet janë 2-3);
- unë thjesht nuk dua të shpenzoj kohën tuaj, pasi ndoshta dëshironi të përdorni mjete të tjera për të arritur të njëjtat qëllime.
Praktika
Më pëlqen shumë që ky material të jetë i dobishëm për çdo lexues, jo thjesht të lexohet dhe të harrohet. Në çdo studim, praktikën e rëndësishme. Për këtë, kam përgatitur. Gjithashtu do t'ju presë një detyrë shtëpie, në mënyrë që të siguroheni se nuk keni kopjuar në mënyrë pa mend komanda të ekzekutueshme.
Plani
Hapi
Teknologjia
Mjetet
1
Ekzekutimi lokal (pĂ«rgatitni web / android teste demo dhe ekzekutoni ato lokalmente)Â
Node.js, Selenium, Appium
2
Sistemet e kontrollit tĂ« versioneveÂ
Git
3
Kontraktimi
Docker, Selenium grid, Selenoid (Web, Android)
4
CI / CD
Gitlab CI
5
Platformat e cloud
Google Cloud Platform
6
Orkestrimi
Kubernetes
7
Infrastrukturë si kod (IaC)
Terraform, Ansible
Struktura e çdo seksioni
Për të mbajtur narracionin në një mënyrë të qartë, çdo seksion përshkruhet sipas planit të mëposhtëm:
- përshkrim i shkurtër i teknologjisë,
- vlera për infrastrukturën e automatizimit,
- ilustrimi i gjendjes aktuale të infrastrukturës,
- lidhje për studim,
- mjete të ngjashme.
1. Ekzekutimi lokal i testeve
Përshkrimi i shkurtër i teknologjisë
Ky Ă«shtĂ« thjesht njĂ« hap pĂ«rgatitor pĂ«r tĂ« ekzekutuar testet demo lokalmente dhe pĂ«r tĂ« verifikuar se ato kalojnĂ« me sukses. NĂ« pjesĂ«n praktike pĂ«rdoret Node.js por gjuha e programimit dhe platforma gjithashtu nuk janĂ« tĂ« rĂ«ndĂ«sishme dhe mund tĂ« pĂ«rdorni ato qĂ« pĂ«rdoren nĂ« kompaninĂ« tuaj.Â
Megjithatë, si mjete automatizimi rekomandoj të përdorni Selenium WebDriver për platforma web dhe Appium për platformën Android përkatësisht, pasi në hapat e ardhshëm do të përdorim imazhe Docker, të cilat janë përgatitur për të punuar saktësisht me këto mjete. Për më tepër, duke u referuar kërkesave në ofertat e punës, këto mjete janë më të kërkuarat në treg.
Si mund të keni vënë re, ne po shqyrtojmë vetëm testet për web dhe Android. Fatkeqësisht, IOS është një histori krejt tjetër (faleminderit Apple). Kam për qëllim të demonstroj zgjidhje dhe praktika të lidhura me IOS në pjesët në vazhdim.
Vlera për infrastrukturën e automatizimit
Nga këndvështrimi i infrastrukturës, ekzekutimi lokal nuk ka asnjë vlerë. Ju thjesht po kontrolloni nëse testet funksionojnë në makinat lokale në shfletuesit lokalë dhe simuluesit. Por, në çdo rast, kjo është një pikë e nevojshme fillestare.
Ilustrimi i gjendjes aktuale të infrastrukturës
Linket për studim
Mjetet e ngjashme
- çdo gjuhĂ« programimi, qĂ« ju pĂ«lqen, nĂ« lidhje me Selenium/Appium â testet;
- çdo test;
- çdo ekzekutues të testeve.
2. Sistemet e kontrollit të versioneve (Git)
Përshkrimi i shkurtër i teknologjisë
Nuk do të jetë një zbulesë për askënd nëse them se sistemi i kontrollit të versioneve është një pjesë jashtëzakonisht e rëndësishme e zhvillimit, si në ekip ashtu edhe individualisht. Duke iu referuar burimeve të ndryshme, mund të themi me siguri që Git është përfaqësuesi më i popullarizuar. Sistemi i kontrollit të versioneve ofron shumë përfitime, si shkëmbimi i kodit, ruajtja e versioneve, rikuperimi në degët e mëparshme, monitorimi i historisë së projektit, kopjet rezervë. Nuk do të diskutojmë çdo pikë në detaje, pasi jam i sigurt që ju e njihni mirë dhe e përdorni në punën tuaj të përditshme. Por nëse ndonjëherë nuk e njihni, unë rekomandoj të ndaloni leximin e këtij artikulli dhe sa më shpejt të plotësoni këtë boshllëk.
Vlera për infrastrukturën e automatizimit
Dhe këtu mund të bëni një pyetje të arsyeshme: "Pse na flet ai për Git? Të gjithë e dinë dhe e përdorin atë si për kodin e zhvillimit ashtu edhe për kodin e testeve automatike". Do të keni plotësisht të drejtë, por në këtë artikull po flasim për infrastrukturën dhe këtë seksion luan një rol paraqitës për seksionin 7: "Infrastruktura si Kod (IaC)". Për ne kjo do të thotë se e gjithë infrastruktura, përfshirë atë testuese, përshkruhet në formë kodi, përkatësisht ne mund t'ua aplikojmë sistemet e versionimit dhe të marrim përfitime të ngjashme si për kodin e zhvillimit dhe automatizimin.
Ne do ta shqyrtojmë IaC më në detaje në hapin 7, por mund të filloni ta përdorni Git lokalisht tani, duke krijuar një depo lokale. Pamja e përgjithshme do të zgjerodheshin kur të shtojmë një depo të largët në infrastrukturë.
Ilustrimi i gjendjes aktuale të infrastrukturës
Linket për studim
Mjetet e ngjashme
- Â
3. Kontenjerizimi (Docker)
Përshkrimi i shkurtër i teknologjisë
Për të demonstruar se si kontenjerizimi ndryshoi rregullat e lojës, le të kthehemi disa dekada në të kaluarën. Në ato kohëra, njerëzit blinin dhe përdornin makina server për të ekzekutuar aplikacione. Por, në shumicën e rasteve, burimet e nevojshme për ekzekutimin e tyre nuk ishin të njohura paraprakisht. Si rezultat, kompanitë shpenzonin para për blerjen e serverëve të fuqishëm të shtrenjtë, por një pjesë e këtyre kapaciteteve nuk ishin përdorur plotësisht.
Hapi tjetër në evolucionin ishin makinat virtuale (VM), të cilat zgjidhën problemin e shpenzimeve për burimet e papërdorura. Kjo teknologji lejoi ekzekutimin e aplikacioneve të pavarura ndërsjelltas brenda një serveri, duke ndarë një hapësirë të plotë të izoluara. Por, fatkeqësisht, çdo teknologji ka disavantazhet e saj. Ekzekutimi i VM kërkon një sistem operativ të plotë, i cili konsumon CPU, RAM, ruajtje dhe, varësisht nga OS, është e nevojshme të merren parasysh kostot e licencës. Këto faktorë ndikojnë në shpejtësinë e ngarkesës dhe e komplikuar portabilitetin.
Dhe tani kemi ardhur te kontenjerizimi. Përsëri, kjo teknologji zgjidhi problemin e mëparshëm, pasi kontenjerët nuk përdorin një OS të plotë, duke lejuar kështu të çlirohen shumë burime dhe ofrojnë një zgjidhje të shpejtë dhe të fleksibël për portabilitetin.
Sigurisht, teknologjia e kontejnerizimit nuk është diçka e re dhe u prezantua për herë të parë në fund të viteve '70. Në ato kohë, u bënë shumë kërkime, zhvillime dhe përpjekje. Por ishte pikërisht Docker që e përshtati këtë teknologji dhe e bëri të lehtë për masat. Në kohët tona, kur flasim për kontejnerë, në shumicën e rasteve kemi parasysh Docker. Kur flasim për kontejnerët Docker, nënkuptojmë kontejnerë Linux. Ne mund të përdorim sisteme Windows dhe macOS për të drejtuar kontejnerë, por është e rëndësishme të kuptojmë se në këtë rast shfaqet një shtresë e shtuar. Për shembull, Docker në Mac fshehurazi drejton kontejnerët brenda një VM të lehtë Linux. Ne do të kthehemi në këtë temë kur të diskutojmë për drejtuar emulatorët Android brenda kontejnerëve, pasi ka një nuancë shumë të rëndësishme që duhet shqyrtuar më në detaje.
Vlera për infrastrukturën e automatizimit
Ne zbuluam se kontejnerizimi dhe Docker janë të shkëlqyera. Le të shikojmë këtë në kontekstin e automatizimit, sepse çdo mjet ose teknologji duhet të zgjidhë një problem. Të identifikojmë problemet e dukshme të automatizimit të testimit në kontekstin e testeve UI:
- një numër i madh varësish gjatë instalimit të Selenium dhe veçanërisht të Appium;
- probleme përshtatjeje mes versioneve të shfletuesve, simulatorëve dhe drejtuesve;
- mungesa e një hapësire të izoluar për shfletuesit/simulatorët, që është veçanërisht kritike për ekzekutimin paralel;
- është e vështirë të menaxhohet dhe të mbahen, nëse duhen drejtuar 10, 50, 100 ose madje 1000 shfletues njëherazi.
Por, pasi Selenium Ă«shtĂ« mjeti mĂ« i njohur pĂ«r automatizim dhe Docker Ă«shtĂ« mjeti mĂ« i njohur pĂ«r kontejnerizim, askush nuk duhet tĂ« befasohet qĂ« dikush pĂ«rpiqet t'i bashkojĂ« ato pĂ«r tĂ« krijuar njĂ« mjet tĂ« fuqishĂ«m pĂ«r tĂ« zgjidhur problemet e pĂ«rmendura mĂ« lart. Le tĂ« shqyrtojmĂ« kĂ«to zgjidhje mĂ« nĂ« detaje.Â
Selenium grid në docker
Ky kyç kyç kyç kyç populare në botë Selenium për të drejtuar disa shfletues në disa makina dhe për t'i menaxhuar ato nga një trung qendror. Për të nisur, ne duhet të regjistrojmë të paktën 2 pjesë: Hub dhe Node(s). Hub është trung qendror që merr të gjitha kërkesat nga provat dhe i shpërndan ato në Nodes përkatëse. Për çdo Node, ne mund të konfigurojmë një konfigurim specifik, për shembull, duke treguar shfletuesin e nevojshëm dhe versionin e tij. Megjithatë, ne ende kemi nevojë të kujdesemi për drejtuesit e përputhshëm për shfletuesit dhe t'i instalojmë ato në Nodes përkatëse. Për këtë arsye, Selenium grid nuk përdoret në mënyrë të pastër, përveç se në ato raste kur kemi nevojë të punojmë me shfletuesit që nuk mund të instalohen në Linux OS. Për të gjitha rastet e tjera, një zgjidhje shumë fleksibile dhe e saktë do të ishte përdorimi i imazheve Docker për të nisur Hub dhe Nodes të Selenium grid. Ky qasje ndihmon shumë në menaxhimin e nyjeve, pasi ne mund të zgjedhim imazhin që na nevojitet me versionet përkatëse të shfletuesve dhe drejtuesve tashmë të instaluar.
MegjithĂ«se ka komente negative pĂ«r stabilitetin e funksionimit, veçanĂ«risht kur ekzekutohen njĂ« numĂ«r tĂ« madh Node-esh paralelisht, Selenium grid ende mbetet mjeti mĂ« i popullarizuar pĂ«r ekzekutimin paralel tĂ« testeve Selenium. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se nĂ« open-source vazhdimisht shfaqen pĂ«rditĂ«sime dhe modifikime tĂ« ndryshme tĂ« kĂ«tij instrumenti, tĂ« cilat luftojnĂ« kundĂ«r ngushticave tĂ« ndryshme.
Selenoid për Web
Ky kyç Ă«shtĂ« njĂ« hap pĂ«rpara nĂ« botĂ«n e Selenium, pasi funksionon menjĂ«herĂ« nga kutia dhe ka bĂ«rĂ« jetĂ«n e shumĂ« inxhinierĂ«ve tĂ« automatizimit shumĂ« mĂ« tĂ« thjeshtĂ«. Para sĂ« gjithash, nuk Ă«shtĂ« njĂ« modifikim tjetĂ«r i Selenium grid. NĂ« vend tĂ« kĂ«saj, zhvilluesit krijuan njĂ« version tĂ« entirely tĂ« ri tĂ« Selenium Hub nĂ« gjuhĂ«n Golang, e cila, nĂ« lidhje me imazhet e lehta Docker pĂ«r shfletues tĂ« ndryshĂ«m, e dha njĂ« nxitje nĂ« zhvillimin e automatizimit tĂ« testimeve. PĂ«r mĂ« tepĂ«r, nĂ« rastin e Selenium Grid ne duhet tĂ« pĂ«rcaktojmĂ« tĂ« gjitha shfletuesit dhe versionet e tyre tĂ« kĂ«rkuara pĂ«rpara, çka nuk Ă«shtĂ« problem kur punojmĂ« vetĂ«m me njĂ« shfletues. Por kur flasim pĂ«r disa shfletues tĂ« mbĂ«shtetur, Selenoid Ă«shtĂ« zgjidhja numĂ«r njĂ«, pĂ«r shkak tĂ« funksionit âshfletues nĂ« kĂ«rkesĂ«â. E gjithĂ« çfarĂ« na duhet Ă«shtĂ« tĂ« shkarkojmĂ« paraprakisht imazhet e nevojshme me shfletues dhe tĂ« pĂ«rditĂ«sojmĂ« skedarin e konfigurimit me tĂ« cilin Selenoid ndĂ«rvepron. Pas kĂ«rkesĂ«s nga testet, Selenoid automatikisht do tĂ« nisĂ« kontejnerin e nevojshĂ«m me shfletuesin e nevojshĂ«m. Pasi testi tĂ« pĂ«rfundojĂ«, Selenoid do ta heqĂ« kontejnerin, duke liruar kĂ«shtu burimet pĂ«r kĂ«rkesat e tjera. Ky qasje eliminon plotĂ«sisht problemin e njohur tĂ« âdegradimit tĂ« nyjaveâ, qĂ« shpesh e hasim nĂ« Selenium grid.
Por, fatkeqĂ«sisht, Selenoid ende nuk Ă«shtĂ« plumbi i argjendtĂ«. Ne morĂ«m funksionin âshfletues nĂ« kĂ«rkesĂ«â, por funksioni âburime nĂ« kĂ«rkesĂ«â ende nuk Ă«shtĂ« i disponueshĂ«m. PĂ«r tĂ« pĂ«rdorur Selenoid, ne duhet ta instalojmĂ« atĂ« nĂ« hardware fizik ose nĂ« VM, çka do tĂ« thotĂ« se duhet tĂ« dimĂ« paraprakisht se sa burime tĂ« nevojshme duhet tĂ« dedikojmĂ«. UnĂ« mendoj se kjo nuk Ă«shtĂ« njĂ« problem pĂ«r projektet e vogla qĂ« ekzekutojnĂ« 10, 20 ose madje 30 shfletues paralelisht. Por çfarĂ« nĂ«se na duhen 100, 500, 1000 ose mĂ« shumĂ«? Nuk ka asnjĂ« kuptim tĂ« mbĂ«shtesim dhe paguajmĂ« njĂ« sasi tĂ« tillĂ« burimesh vazhdimisht. NĂ« seksionet 5 dhe 6 tĂ« kĂ«tij artikulli, ne do tĂ« diskutojmĂ« zgjidhjet qĂ« lejojnĂ« shkallĂ«zim, duke reduktuar ndjeshĂ«m shpenzimet e kompanisĂ«.
Selenoid për Android
Pas suksesit tĂ« Selenoid si njĂ« mjet pĂ«r automatizimin e web-it, njerĂ«zit donin tĂ« kishin diçka tĂ« ngjashme pĂ«r Android. Dhe kjo ndodhi â Selenoid u lançua me mbĂ«shtetje pĂ«r Android. Nga njĂ« pikĂ«pamje e nivelit tĂ« lartĂ« tĂ« pĂ«rdoruesit, parimi i funksionimit Ă«shtĂ« i ngjashĂ«m me automatizimin e web-it. Dallimi i vetĂ«m Ă«shtĂ« se, pĂ«rveç kontejnerĂ«ve me shfletues, Selenoid lançon kontejnerĂ« me emulatorĂ« tĂ« Android. Sipas mendimit tim, nĂ« kĂ«tĂ« moment, ky Ă«shtĂ« mjeti mĂ« i fuqishĂ«m falas pĂ«r tĂ« ekzekutuar teste Android paralelisht.
Më vjen keq të flas për anët negative të këtij mjeti, pasi ai më pëlqen vërtet shumë. Por megjithatë, këtu janë të pranishme të njëjtat disavantazhe që i përkasin edhe automatizimit të web-it, të lidhura me shkallëzimin. Përveç kësaj, duhet të flas për një kufizim tjetër, i cili mund të bëhet një surprizë, nëse e konfigurojmë mjetin për herë të parë. Për të ekzekutuar imazhet e Android, na nevojitet një makinë fizike ose VM me mbështetje për virtualizim të ngjitur. Në udhëzimin praktik do të demonstroj si ta aktivizoj këtë në një VM Linux. Megjithatë, nëse jeni përdorues i macOS dhe dëshironi të vendosni Selenoid lokal, atëherë për të ekzekutuar testet Android do të jetë e pamundur. Por gjithmonë mund të lançoni një VM Linux lokal me 'nested virtualization' të konfiguruar dhe të vendosni Selenoid brenda.
Ilustrimi i gjendjes aktuale të infrastrukturës
NĂ« kontekstin e kĂ«tij artikulli, ne do tĂ« shtojmĂ« 2 mjete pĂ«r tĂ« ilustruar infrastrukturĂ«n. KĂ«to janĂ« Selenium grid pĂ«r testet web dhe Selenoid pĂ«r testet Android. NĂ« udhĂ«zimin nĂ« GitHub unĂ« gjithashtu do tĂ« tregoj si tĂ« pĂ«rdor Selenoid pĂ«r tĂ« ekzekutuar testet web.Â
Linket për studim
Mjetet e ngjashme
- Ka mjete tĂ« tjera tĂ« kontenierizimit, por Docker Ă«shtĂ« mĂ« i popullarizuari. NĂ«se dĂ«shironi tĂ« provoni diçka tjetĂ«r, mbani parasysh se ato mjete qĂ« shqyrtuam pĂ«r ekzekutimin paralel tĂ« testeve Selenium nuk do tĂ« funksionojnĂ« nga kutia. Â
- Siç u tha më parë, ekzistojnë shumë modifikime të Selenium grid, për shembull,.
4. CI / CD
Përshkrimi i shkurtër i teknologjisë
Praktika e integrimit të vazhdueshëm është mjaft e njohur në zhvillim dhe qëndron në të njëjtin nivel me sistemet e kontrollit të versioneve. Megjithatë, ndjej se ekziston një konfuzion në terminologji. Në këtë paragraf, do doja të përshkruaja 3 modifikime të kësaj teknologjie nga pikëpamja ime. Në internet, do të gjeni shumë artikuj me interpretime të ndryshme, dhe kjo është plotësisht normale nëse mendimi juaj ndryshon. Më e rëndësishmja, është që të jeni në të njëjtin valë me kolegët tuaj.
KĂ«shtu, ekzistojnĂ« 3 terma: CI â Continuous Integration (Integrim tĂ« vazhdueshĂ«m), CD â Continuous Delivery (DorĂ«zim tĂ« vazhdueshĂ«m) dhe pĂ«rsĂ«ri CD â Continuous Deployment (Zhvillim tĂ« vazhdueshĂ«m). (MĂ« tej, do tĂ« pĂ«rdor kĂ«ta terma nĂ« anglisht). Ădo modifikim shton disa hapa tĂ« tjerĂ« nĂ« konvejurin tuaj tĂ« zhvillimit. Por fjala continuous (tĂ« vazhdueshĂ«m) Ă«shtĂ« mĂ« e rĂ«ndĂ«sishmja. NĂ« kĂ«tĂ« kontekst, kuptojmĂ« diçka qĂ« ndodh nga fillimi deri nĂ« fund, pa ndĂ«rprerje ose ndĂ«rhyrje manuale. Le tĂ« shohim CI & CD dhe CD nĂ« kĂ«tĂ« kontekst.
- Continuous Integration â Ă«shtĂ« hapi fillestar i evolucionit. Pas dĂ«rgimit tĂ« kodit tĂ« ri nĂ« server, presim tĂ« marrim njĂ« reagim tĂ« shpejtĂ« se gjithçka Ă«shtĂ« nĂ« rregull me ndryshimet tona. Zakonisht, CI pĂ«rfshin fillimin e mjeteve tĂ« analizĂ«s sĂ« kodit nĂ« mĂ«nyrĂ« statike dhe teste module/shĂ«rbime interne API. Kjo na lejon tĂ« marrim informacion pĂ«r kodin tonĂ« vetĂ«m disa sekonda/minuta mĂ« vonĂ«.
- Dërgimi i Vazhdushëm është një hap më i avancuar, ku ne fillojmë të ekzekutojmë teste integrimi/UI. Megjithatë, në këtë fazë, nuk marrim rezultatet aq shpejt sa në rastin e CI. Së pari, këta lloje testesh kërkojnë më shumë kohë për të kaluar. Së dyti, përpara se të fillojmë, duhet të zbatojmë ndryshimet tona në një ambient testimi/staging. Për më tepër, nëse flasim për zhvillimin e aplikacioneve mobile, atëherë ndodhet një hap shtesë për të ndërtuar versionin e aplikacionit tonë.
- Continuous Deployment supozon se që ne automatikisht lëshojmë (release) ndryshimet tona në production, nëse të gjitha testet pranuese janë kaluar në hapat e mëparshëm. Përveç kësaj, pas hapit të release mund të konfigurohen faza të ndryshme, siç janë ekzekutimi i testeve smoke në production dhe mbledhja e metrikave të interesit. Continuous Deployment është e mundur vetëm me mbulim të mirë nga testet automatike. Nëse kërkohen ndihma manuale, përfshirë testimin, atëherë kjo nuk është më Continuous (e vazhdueshme). Atëherë mund të flasim që konvejeri ynë i përmbush vetëm praktikën e Continuous Delivery.
Vlera për infrastrukturën e automatizimit
NĂ« kĂ«tĂ« seksion duhet tĂ« sqaroj se, kur flasim pĂ«r testet UI end-to-end, nĂ«nkuptohet se ne duhet tĂ« deploymĂ« ndryshimet tona dhe shĂ«rbimet pĂ«rkatĂ«se nĂ« mjediset e testimit. Continuous Integration â procesi nuk Ă«shtĂ« i pĂ«rshtatshĂ«m pĂ«r kĂ«tĂ« detyrĂ« dhe ne duhet tĂ« kujdesemi pĂ«r implementimin e praktikave tĂ« paktĂ«n tĂ« Continuous Delivery. Continuous Deployment gjithashtu ka kuptim nĂ« kontekstin e testeve UI, nĂ«se ne planifikojmĂ« t'i ekzekutojmĂ« ato nĂ« production.
Dhe para se të shikojmë ilustrimin e ndryshimit në arkitekturë, dua të them disa fjalë për GitLab CI. Ndryshe nga mjetet e tjera CI/CD, GitLab ofron një repo të shkarkueshëm dhe shumë funksione të tjera shtesë. Kështu, GitLab është më shumë se CI. Ai përfshin nga kutia menaxhimin e burimeve të kodit, menaxhimin Agile, CI/CD pipelines, mjete për regjistrim dhe mbledhjen e metrikave. Arkitektura e GitLab përbëhet nga Gitlab CI/CD dhe GitLab Runner. Po sjell një përshkrim të shkurtër nga faqja zyrtare:
Gitlab CI/CD është një aplikacion web me një API që ruan gjendjen e tij në një bazë të dhënash, menaxhon projektet/ndërtimet dhe ofron një ndërfaqe përdoruesi. GitLab Runner është një aplikacion që përpunon ndërtimet. Ai mund të vendoset veçmas dhe punon me GitLab CI/CD përmes një API. Për ekzekutimin e testeve ju nevojiten si instance e Gitlab ashtu edhe Runner.
Ilustrimi i gjendjes aktuale të infrastrukturës
Linket për studim
Mjetet e ngjashme
- Â
- Dhe shumë të tjera
5. Platformat në re
Përshkrimi i shkurtër i teknologjisë
NĂ« kĂ«tĂ« seksion do tĂ« flasim pĂ«r njĂ« trend tĂ« njohur, i cili quhet âcloud publikâ. PavarĂ«sisht pĂ«rfitimeve tĂ« mĂ«dha qĂ« ofrojnĂ« teknologjitĂ« e pĂ«rshkruara mĂ« sipĂ«r, si virtualizimi dhe kontejnerizimi, ne akoma kemi nevojĂ« pĂ«r burime llogaritĂ«se. KompanitĂ« fitojnĂ« servera tĂ« shtrenjtĂ« apo qirajnĂ« qendrat e tĂ« dhĂ«nave, por nĂ« kĂ«tĂ« rast duhet tĂ« bĂ«jmĂ« llogaritje (ndonjĂ«herĂ« tĂ« pamundura) se sa burime do na nevojiten, nĂ«se do t'i pĂ«rdorim ato 24/7 dhe pĂ«r cilat qĂ«llime. PĂ«r shembull, pĂ«r prodhimin na nevojitet njĂ« server qĂ« funksionon gjatĂ« gjithĂ« kohĂ«s, por a na nevojiten burime tĂ« ngjashme pĂ«r testim jashtĂ« orarit tĂ« punĂ«s? Kjo gjithashtu varet nga lloji i testimit qĂ« po bĂ«het. NjĂ« shembull mund tĂ« jenĂ« testet e ngarkesĂ«s/stresit, qĂ« planifikojmĂ« t'i kryejmĂ« gjatĂ« orĂ«ve jopune, pĂ«r tĂ« marrĂ« rezultate nĂ« ditĂ«n tjetĂ«r. Por, pa dyshim, disponueshmĂ«ria 24/7 e serverĂ«ve nuk Ă«shtĂ« e nevojshme pĂ«r testet automatike end-to-end dhe veçanĂ«risht pĂ«r mjediset e testimit manual. PĂ«r situata tĂ« tilla, do tĂ« ishte mirĂ« tĂ« marrim aq burime sa na nevojiten sipas kĂ«rkesĂ«s, t'i pĂ«rdorim dhe tĂ« ndalojmĂ« sĂ« paguari kur ato nuk janĂ« mĂ« tĂ« nevojshme. PĂ«r mĂ« tepĂ«r, do tĂ« ishte shkĂ«lqyeshĂ«m tâi merrnim ato menjĂ«herĂ«, duke bĂ«rĂ« disa klikime me miun ose duke ekzekutuar disa skripte. KĂ«tĂ« qĂ«llim kanĂ« cloud-et publike. Le tĂ« shohim definicionin:
«Cloud publik Ă«shtĂ« pĂ«rcaktuar si shĂ«rbime llogaritĂ«se tĂ« ofruara nga ofrues tĂ« palĂ«ve tĂ« treta mbi internetin publik, duke i bĂ«rĂ« ato tĂ« disponueshme pĂ«r çdo kĂ«nd qĂ« dĂ«shiron tâi pĂ«rdorĂ« ose tâi blejĂ« ato. Ato mund tĂ« jenĂ« falas ose tĂ« shiten sipas kĂ«rkesĂ«s, duke lejuar klientĂ«t tĂ« paguajnĂ« vetĂ«m pĂ«r pĂ«rdorimin e cikleve tĂ« CPU, ruajtjes ose gjerĂ«sisĂ« sĂ« brezit qĂ« konsumojnë».
Ka njĂ« mendim tĂ« zakonshĂ«m se cloud-et publike janĂ« tĂ« shtrenjta. Por ideja e tyre kryesore Ă«shtĂ« reduktimi i shpenzimeve tĂ« kompanisĂ«. Siç u pĂ«rmend mĂ« parĂ«, cloud-et publike lejojnĂ« qĂ« tĂ« marresh burime sipas kĂ«rkesĂ«s dhe tĂ« paguash vetĂ«m pĂ«r kohĂ«n e pĂ«rdorimit tĂ« tyre. Gjithashtu, ndonjĂ«herĂ« harrojmĂ« se punonjĂ«sit marrin pagĂ« dhe specialistĂ«t gjithashtu janĂ« njĂ« burim i shtrenjtĂ«. Duhet tĂ« kemi parasysh se cloud-et publike lehtĂ«sojnĂ« ndjeshĂ«m mbĂ«shtetje infrastrukturore, duke lejuar inxhinierĂ«t tĂ« fokusohen nĂ« detyra mĂ« tĂ« rĂ«ndĂ«sishme.Â
Vlera për infrastrukturën e automatizimit
Cilat burime specifike na nevojiten pĂ«r teste UI end-to-end? Kryesisht janĂ« makina virtuale ose klasterĂ« (do tĂ« flasim pĂ«r Kubernetes nĂ« seksionin e ardhshĂ«m) pĂ«r tĂ« ekzekutuar shfletuesit dhe emulatorĂ«t. Sa mĂ« shumĂ« shfletues dhe emulatorĂ« dĂ«shirojmĂ« tĂ« ekzekutojmĂ« njĂ«kohĂ«sisht, aq mĂ« shumĂ« CPU dhe memorie na duhen dhe aq mĂ« shumĂ« para do tĂ« na duhet tĂ« paguajmĂ« pĂ«r kĂ«tĂ«. KĂ«shtu, cloud-et publike nĂ« kontekstin e automatizimit tĂ« testeve na lejojnĂ« tĂ« ekzekutojmĂ« njĂ« numĂ«r tĂ« madh (100, 200, 1000...) shfletuesish/emulatorĂ«sh sipas kĂ«rkesĂ«s, tĂ« marrim rezultatet e testimit sa mĂ« shpejt dhe tĂ« ndalojmĂ« sĂ« paguari pĂ«r kĂ«to kapacitete tĂ« jashtĂ«zakonshme dhe tĂ« shtrenjta.Â
Ofertuesit mĂ« tĂ« njohur tĂ« cloud-it janĂ« Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). NĂ« udhĂ«zimin praktik janĂ« pĂ«rfshirĂ« shembuj tĂ« pĂ«rdorimit tĂ« GCP, por nĂ« pĂ«rgjithĂ«si nuk ka rĂ«ndĂ«si se çfarĂ« do tĂ« pĂ«rdorni pĂ«r detyrat e automatizimit. TĂ« gjithĂ« ata ofrojnĂ« funksionalitet afĂ«rsisht tĂ« njĂ«jtĂ«. Zakonisht, pĂ«r tĂ« zgjedhur ofertuesin, udhĂ«zimi fokusohet nĂ« tĂ« gjithĂ« infrastrukturĂ«n e kompanisĂ« dhe kĂ«rkesat biznesore, qĂ« Ă«shtĂ« pĂ«rtej kĂ«tij artyku. PĂ«r inxhinierĂ«t e automatizimit, do tĂ« ishte mĂ« interesante tĂ« krahasohet pĂ«rdorimi i ofruesve tĂ« cloud-it me pĂ«rdorimin e platformave specifikisht pĂ«r qĂ«llimet e testimit, si Sauce Labs, BrowserStack, BitBar dhe tĂ« tjera. Pra, le tĂ« bĂ«jmĂ« tĂ« njĂ«jtĂ«n gjĂ«! Sipas mendimit tim, Sauce Labs Ă«shtĂ« fermĂ« e njohur pĂ«r testimin nĂ« cloud, prandaj e kam marrĂ« atĂ« pĂ«r krahasim.Â
GCP përballë Sauce Labs për qëllimet e automatizimit:
Le tĂ« imagjinojmĂ« se na nevojiten tĂ« ekzekutojmĂ« 8 teste web dhe 8 teste Android njĂ«kohĂ«sisht. PĂ«r kĂ«tĂ«, do tĂ« pĂ«rdorim GCP dhe do tĂ« ngrisim 2 makina virtuale me Selenoid. NĂ« tĂ« parĂ«n do tĂ« ngremĂ« 8 kontejnerĂ« me shfletues. NĂ« tĂ« dytĂ«n â 8 kontejnerĂ« me emulatorĂ«. Le tĂ« shikojmĂ« çmimet: Â
Për të ekzekutuar një kontejner me Chrome, na nevojitet n1-standard-1 makinë. Në rastin e Android do të jetë n1-standard-4 për një emulator. Në të vërtetë, një mënyrë më fleksibile dhe të përballueshme është përcaktimi i vlerave të caktuara për CPU/Memorie, por për momentin kjo nuk është thelbësore për krahasimin me Sauce Labs.
Ja çmimet për përdorimin e Sauce Labs:
Mendoj se tashmë e keni vënë re ndryshimin, por gjithsesi do të jap një tabelë me llogaritjet për detyrën tonë:
Burimet e nevojshme
Muajore
OrĂ«t e punĂ«s(8 a.m â 8 p.m)
Orët e punës+ Preemptible
GCP për Web
n1-standard-1 x 8 = n1-standard-8
$194.18
23 ditĂ« * 12 orĂ« * 0.38 = 104.88$Â
23 ditë * 12 orë * 0.08 = 22.08$
Sauce Labs për Ueb
Testet paralele Virtual Cloud8
$1.559
â
â
GCP për Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 ditĂ« * 12 orĂ« * 1.52 = 419.52$Â
23 ditë * 12 orë * 0.32 = 88.32$
Sauce Labs për Android
Testet paralele Cloud të Pajisjeve Reale
$1.999
â
â
Siç shihet, diferenca nĂ« kosto Ă«shtĂ« shumĂ« e madhe, sidomos nĂ«se ekzekutoni testet vetĂ«m nĂ« intervalin normal tĂ« punĂ«s prej 12 orĂ«sh. Por mund t'i zvogĂ«loni edhe mĂ« shumĂ« shpenzimet duke pĂ«rdorur makinat preemptible. ĂfarĂ« janĂ« ato?
Një VM preemptible është një instancë që mund ta krijoni dhe ta ekzekutoni me një çmim shumë më të ulët se instancat normale. Megjithatë, Motori i Llogarive mund t'i përfundojë këto instanca (preempt) nëse ka nevojë për qasje në këto burime për detyra tjera. Instancat preemptible janë kapacitete të tepërta të Motorit të Llogarive, kështu që disponibiliteti i tyre ndryshon me përdorimin.
Nëse aplikacionet tuaja janë të tolerante ndaj defekteve dhe mund të përballojnë mundësitë e përfundimit të instancave, atëherë instancat preemptible mund ta reduktojnë ndjeshëm koston tuaj në Motorin e Llogarive. Për shembull, punët e procesimit të grupeve mund të ekzekutohen në instancat preemptible. Nëse disa nga këto instanca përfundojnë gjatë procesimit, puna ngadalësohet por nuk ndalon krejtësisht. Instancat preemptible përfundojnë detyrat tuaja të procesimit të grupeve pa i ngarkuar më shumë instancat tuaja ekzistuese dhe pa kërkuar që të paguani çmim të plotë për instancat normale shtesë.
Dhe kjo ende nuk është fundi! Në të vërtetë, jam i sigurt se askush nuk ekzekuton teste për 12 orë pa ndalesa. Dhe nëse është kështu, mund të lançoni dhe ndaloni automatikisht makinat virtuale kur ato nuk kanë nevojë. Koha reale e përdorimit mund të ulet deri në 6 orë në ditë. Atëherë pagesa në kontekstin e problemit tonë do të ulet deri në 11$ në muaj për 8 shfletues. A nuk është kjo e shkëlqyer? Por me makinat preemptible duhet të jemi të kujdesshëm dhe të përgatitur për ndërprerje dhe nëngarkesa të paqëndrueshme, megjithatë këto situata mund të parashikohen dhe trajtohen në mënyrë programore. Vlen!
Por asnjĂ«herĂ« nuk po them âmos e pĂ«rdorni kurrĂ« fermat e testeve nĂ« cloudâ. Ato kanĂ« shumĂ« avantazhe. Para sĂ« gjithash, kjo nuk Ă«shtĂ« thjesht njĂ« makinĂ« virtuale, por njĂ« zgjidhje e plotĂ« pĂ«r automatizimin e testeve, me njĂ« grup funksionalitetesh nga kuti: qasje e largĂ«t, regjistrime, captura ekranesh, regjistrim video, shfletues tĂ« ndryshĂ«m dhe pajisje mobile reale. NĂ« shumĂ« situata, kjo mund tĂ« jetĂ« njĂ« alternativĂ« e pahershme. VeçanĂ«risht platformat e testeve janĂ« tĂ« dobishme pĂ«r automatizimin e IOS, kur cloud-et publike mund tĂ« ofrojnĂ« vetĂ«m sisteme Linux/Windos. Por diskutimi pĂ«r IOS do jetĂ« nĂ« artikujt e ardhshĂ«m. Rekomandoj gjithmonĂ« tĂ« shikoni situatĂ«n dhe tĂ« bazohemi nĂ« detyra: nĂ« disa raste, Ă«shtĂ« mĂ« e lirĂ« dhe mĂ« efikase tĂ« pĂ«rdorni cloud-et publike, ndĂ«rsa nĂ« disa raste, platformat e testeve patjetĂ«r meritojnĂ« paratĂ« e harxhuara.
Ilustrimi i gjendjes aktuale të infrastrukturës
Linket për studim
Mjetet e ngjashme:
- Â
6. Orkestrimi
Përshkrimi i shkurtër i teknologjisë
Kam disa lajme tĂ« mira â ne jemi pothuajse nĂ« fund tĂ« artikullit! Aktualisht, infrastruktura jonĂ« e automatizimit pĂ«rbĂ«het nga testet web dhe Android, tĂ« cilat i ekzekutojmĂ« pĂ«rmes GitLab CI nĂ« parallel, duke pĂ«rdorur mjete qĂ« mbĂ«shtesin Docker: Selenium grid dhe Selenoid. MĂ« shumĂ«, ne pĂ«rdorim makinat virtuale tĂ« krijuara pĂ«rmes GCP pĂ«r tĂ« ngritur nĂ« to kontejnerĂ« me shfletues dhe emulatorĂ«. PĂ«r tĂ« zvogĂ«luar shpenzimet, ne i aktivizojmĂ« kĂ«to makina virtuale vetĂ«m me kĂ«rkesĂ« dhe i ndalojmĂ« kur testimi nuk bĂ«het. A ka diçka tjetĂ«r qĂ« mund tĂ« pĂ«rmirĂ«sojĂ« infrastrukturĂ«n tonĂ«? PĂ«rgjigjja Ă«shtĂ« â po! MirĂ« se erdhĂ«t Kubernetes (K8s)!
SĂ« pari, le tĂ« shqyrtojmĂ« se si fjalĂ«t orkestrim, klaster dhe Kubernetes janĂ« tĂ« lidhura me njĂ«ra-tjetrĂ«n. NĂ« njĂ« nivel tĂ« lartĂ«, orkestrimi Ă«shtĂ« njĂ« sistem qĂ« shpĂ«rndan dhe menaxhon aplikacionet. PĂ«r automatizimin e testimit, aplikacionet e kontejnerizuara janĂ« Selenium grid dhe Selenoid. Docker dhe K8s plotĂ«sojnĂ« njĂ«ri-tjetrin. I pari pĂ«rdoret pĂ«r tĂ« shpĂ«rndarĂ« aplikacione, i dyti â pĂ«r orkestrimin. NĂ« anĂ«n tjetĂ«r, K8s Ă«shtĂ« njĂ« klaster. Detyra e klasterit Ă«shtĂ« tĂ« pĂ«rdorĂ« VMs si Nodes, duke lejuar qĂ« tĂ« instalohet funksionalitete, programe dhe shĂ«rbime brenda njĂ« serveri (klasteri). NĂ«se ndonjĂ« nga Node bie, atĂ«herĂ« ndihmohen Nodes tĂ« tjera, duke siguruar kĂ«shtu funksionimin e pandĂ«rprerĂ« tĂ« aplikacionit tonĂ«. PĂ«rveç kĂ«saj, K8s ka njĂ« funksionalitet tĂ« rĂ«ndĂ«sishĂ«m lidhur me shkallĂ«zimin (scaling), duke na ofruar automatikisht numrin optimal tĂ« burimeve, bazuar nĂ« ngarkesĂ«n dhe kufizimet e vendosura.
NĂ« tĂ« vĂ«rtetĂ«, shpĂ«rndarja manuale e Kubernetes nga zero Ă«shtĂ« njĂ« detyrĂ« shumĂ« e komplikuar. Do ta lĂ« njĂ« lidhje pĂ«r njĂ« udhĂ«zues praktik tĂ« njohur "Kubernetes The Hard Way", dhe nĂ«se jeni tĂ« interesuar, mund tĂ« praktikoni. Por, fatmirĂ«sisht, ekzistojnĂ« mĂ«nyra dhe mjete alternative. MĂ« e lehta prej tyre Ă«shtĂ« pĂ«rdorimi i Google Kubernetes Engine (GKE) nĂ« GCP, e cila do t'ju lejojĂ« tĂ« merrni njĂ« kluster tĂ« gatshĂ«m pas disa klikimesh. PĂ«r fillestarĂ«t, rekomandoj ta pĂ«rdorni kĂ«tĂ« qasje, pasi do t'ju lejojĂ« tĂ« pĂ«rqendroheni nĂ« mĂ«simin se si tĂ« pĂ«rdorni K8s pĂ«r detyrat tuaja, nĂ« vend qĂ« tĂ« hulumtoni se si komponentĂ«t e brendshĂ«m duhet tĂ« jenĂ« tĂ« integruar me njĂ«ri-tjetrin.Â
Vlera për infrastrukturën e automatizimit
Le të shqyrtojmë disa veçori të rëndësishme që ofron K8s:
- shpërthimin e aplikacioneve: përdorimi i një klasteri multi-node, në vend të VM-ve;
- shkallëzimi dinamik: redukton shpenzimet për burimet që përdoren vetëm sipas kërkesës;
- rindërtimin e vetë (Self-healing): rikthimi automatik i pods (duke rikthyer gjithashtu dhe kontejnerët);
- çakullin e përditësimit dhe rrotullimin e ndryshimeve pa ndërprerje: përditësimi i mjeteve, shfletuesve dhe emulatorëve nuk ndërpret punën e përdoruesve aktualë.
Por K8s ende nuk Ă«shtĂ« njĂ« plumb argjendi. PĂ«r tĂ« kuptuar tĂ« gjitha pĂ«rfitimet dhe kufizimet nĂ« kontekstin e mjeteve qĂ« po shqyrtojmĂ« (Selenium grid, Selenoid) le tĂ« diskutojmĂ« shkurtimisht ndĂ«rtimin e K8s. Klostri pĂ«rmban dy lloje nodash: Master Nodes dhe Workers Nodes. Master Nodes janĂ« pĂ«rgjegjĂ«s pĂ«r menaxhimin, shpĂ«rndarjen dhe vendimet e planifikimit. Nodet punuese janĂ« ato ku aplikacionet janĂ« tĂ« filluara. Nodet gjithashtu pĂ«rmbajnĂ« mjedisin e ekzekutimit tĂ« kontejnerĂ«ve. NĂ« rastin tonĂ«, kjo Ă«shtĂ« Docker, i cili Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r operacionet e lidhura me kontejnerĂ«t. Por ka edhe zgjidhje alternative, pĂ«r shembull. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« kuptohet se shkallĂ«zimi ose rindĂ«rtimi nuk iu referohet drejtpĂ«rdrejt kontejnerĂ«ve. Kjo realizohet pĂ«rmes shtimit/redukimit tĂ« numrit tĂ« pods, tĂ« cilat nga ana tjetĂ«r pĂ«rmbajnĂ« kontejnerĂ« (zakonisht njĂ« kontejner pĂ«r pod, por nĂ« varĂ«si tĂ« detyrĂ«s mund tĂ« ketĂ« edhe mĂ« shumĂ«). Hierarkia e nivelit tĂ« lartĂ« pĂ«rfaqĂ«son nodet punuese, brenda tĂ« cilave ndodhen pods, brenda tĂ« cilave janĂ« ngritur kontejnerĂ«t.
Funksioni i shkallĂ«zimit Ă«shtĂ« thelbĂ«sor dhe mund tĂ« aplikohet si pĂ«r nodes brenda cluster node-pool, ashtu edhe pĂ«r pods brenda node. EkzistojnĂ« 2 lloje shkallĂ«zimi, qĂ« pĂ«rshtaten si pĂ«r nodes ashtu edhe pĂ«r pods. Lloji i parĂ« â horizontal â Ă«shtĂ« njĂ« shkallĂ«zim qĂ« realizohet pĂ«rmes rritjes sĂ« numrit tĂ« nodes/pods. Ky tip Ă«shtĂ« mĂ« i preferuar. Lloji i dytĂ«, pĂ«rkatĂ«sisht, Ă«shtĂ« vertikal. ShkallĂ«zimi realizohet pĂ«rmes rritjes sĂ« pĂ«rmasave tĂ« nodes/pods, e jo tĂ« numrit tĂ« tyre.
Tani le të shqyrtojmë mjetet tona në kontekstin e termave të përmendur më parë.
Selenium grid
Siç u përmend më parë, Selenium grid është një mjet shumë i njohur, dhe nuk është befasi që ai është kontenizuar (containerised). Prandaj, nuk është e çuditshme që Selenium grid mund të implementohet në K8s. Një shembull se si të bëhet kjo mund të gjendet në depot zyrtare të K8s. Si zakonisht, po i bashkëngjit lidhjet në fund të seksionit. Përveç kësaj, në udhëzimin praktik tregohet si të realizohet kjo përmes Terraform. Po ashtu ekziston një udhëzues se si të shkallëzohet numri i pods që përmbajnë kontejnerët me shfletues. Por funksioni i shkallëzimit automatik në kontekstin e K8s mbetet ende një detyrë e paqartë. Kur fillova studimin, nuk gjeta asnjë udhëzim praktik ose rekomandime. Pas disa hulumtimesh dhe eksperimenti me mbështetje nga ekipi DevOps, ne zgjodhëm qasjen e ngritjes së kontejnerëve me shfletuesit e nevojshëm brenda një pod, i cili ndodhet brenda një worker node. Ky qasje na lejon të aplikojmë strategjinë e shkallëzimit horizontal të nodes përmes rritjes së numrit të tyre. Shpresoj që në të ardhmen situata të ndryshojë dhe të shohim gjithnjë e më shumë përshkrime të qasjeve më të mira dhe zgjidhjeve gati, veçanërisht pas lëshimit të Selenium grid 4 me arkitekturën e brendshme të ndryshuar.
Selenoid:
Aktualisht, implementimi i Selenoid në K8s është zhgënjimi më i madh. Ata nuk janë të përshtatshëm. Teorikisht mund të ngremë një kontejner Selenoid brenda një pod, por kur Selenoid fillon të ekzekutojë kontejnerët me shfletues, ata do të jenë ende brenda atij pod-i të njëjtë. Kjo e bën shkallëzimin të pamundur dhe, si rezultat, funksionimi i Selenoid brenda klasterit nuk do të ndryshojë nga funksionimi brenda një makine virtuale. Fundi i historisë.
Moon:
Duke e njohur kĂ«tĂ« ngushticĂ« kur punon me Selenoid, zhvilluesit lanĂ« nĂ« dispozicion njĂ« mjet mĂ« tĂ« fuqishĂ«m, tĂ« quajtur Moon. Ky mjet ishte fillimisht menduar pĂ«r tĂ« punuar me Kubernetes dhe, si rezultat, duhej dhe mund tĂ« pĂ«rdoret funksioni i autoskalimit. MĂ« shumĂ« se kaq, do tĂ« thoja se tani Ă«shtĂ« Ă«shtĂ« opsioni i vetĂ«m mjeti mĂ« i fuqishĂ«m nĂ« botĂ« pĂ«r Selenium, i cili ka mbĂ«shtetje natyrale pĂ«r klasterin K8s direkt nga kutia (nuk Ă«shtĂ« mĂ«, shih mjetin tjetĂ«r ). Karakteristika kryesore e Moon, e cila siguron kĂ«tĂ« mbĂ«shtetje, Ă«shtĂ«:Â
PlotĂ«sisht pa shtet. Selenoid ruan nĂ« memorie informacionin mbi seancat e browser-it qĂ« janĂ« aktualisht duke u ekzekutuar. NĂ«se pĂ«r ndonjĂ« arsye procesi i tij shembet â atĂ«herĂ« tĂ« gjitha seancat aktive humbasin. NĂ« tĂ« kundĂ«rt, Moon nuk ka asnjĂ« shtet tĂ« brendshĂ«m dhe mund tĂ« riprodhohet nĂ«pĂ«r tĂ« gjitha qendrat e tĂ« dhĂ«nave. Seancat e browser-it vazhdojnĂ« tĂ« jetojnĂ«, edhe nĂ«se njĂ« ose mĂ« shumĂ« replika bien.
Pra, Moon Ă«shtĂ« njĂ« zgjidhje fantastike, por me njĂ« problem: nuk Ă«shtĂ« falas. Ămimi varet nga numri i seancave. Mund tĂ« nisni falas vetĂ«m 0-4 seanca, qĂ« nuk Ă«shtĂ« shumĂ« e dobishme. Por, duke filluar nga seanca e pestĂ«, do tĂ« duhet tĂ« paguani 5$ pĂ«r secilĂ«n. Situata mund tĂ« ndryshojĂ« nga kompania nĂ« kompani, por nĂ« rastin tonĂ«, pĂ«rdorimi i Moon Ă«shtĂ« e padobishme. Siç pĂ«rshkrova mĂ« sipĂ«r, ne mund tĂ« nisim VMs me Selenium Grid sipas nevojĂ«s ose tĂ« rrisim numrin e Nodes nĂ« klaster. Rreth njĂ« pipeline ne nisim 500 browser-a dhe ndalojmĂ« tĂ« gjitha burimet pas pĂ«rfundimit tĂ« testeve. NĂ«se do tĂ« pĂ«rdornim Moon, do na duhej tĂ« paguanim 500 x 5 = 2500 $ nĂ« muaj, pa marrĂ« parasysh sa shpesh e nisim testimin. Dhe pĂ«rsĂ«ri, nuk po them "mos pĂ«rdorni Moon". PĂ«r detyrat tuaja, mund tĂ« jetĂ« njĂ« zgjidhje e paçmuar, pĂ«r shembull, nĂ«se keni shumĂ« projekte/ekipa nĂ« organizatĂ«n tuaj dhe ju nevojitet njĂ« klaster i madh i pĂ«rbashkĂ«t pĂ«r tĂ« gjithĂ«. Si gjithmonĂ«, do tĂ« lĂ« njĂ« lidhje nĂ« fund dhe rekomandoj tĂ« bĂ«ni tĂ« gjitha llogaritĂ« e nevojshme nĂ« kontekstin e detyrĂ«s tuaj.
Callisto: (Kujdes! Kjo nuk është në artikullin origjinal dhe ndodhet vetëm në përkthimin në rusisht)
Siç thashĂ«, Selenium Ă«shtĂ« njĂ« mjet shumĂ« i njohur dhe fusha e IT-sĂ« po zhvillohet shumĂ« shpejt. NdĂ«rsa punoja nĂ« pĂ«rkthim, nĂ« rrjet u shfaq njĂ« mjet i ri premtues, Callisto (pĂ«rshĂ«ndetje Cypress dhe vrasĂ«sve tĂ« tjerĂ« tĂ« Selenium). Ai punon nĂ« mĂ«nyrĂ« natyrale me K8s dhe lejon ekzekutimin e kontejnerĂ«ve Selenoid nĂ« pods, nĂ« mĂ«nyrĂ« tĂ« shpĂ«rndarĂ« nĂ« Nodes. Gjithçka funksionon menjĂ«herĂ« nga kutia, duke pĂ«rfshirĂ« automatikisht shkallĂ«zimin. Fantastic, por duhet testuar. Kam arritur tashmĂ« tĂ« zhvilloj kĂ«tĂ« mjet dhe tĂ« vendos disa eksperimente. Por Ă«shtĂ« herĂ«t pĂ«r tĂ« bĂ«rĂ« pĂ«rfundime. Pas marrjes sĂ« rezultateve nĂ« njĂ« distancĂ« tĂ« gjatĂ«, ndoshta do tĂ« bĂ«j njĂ« rishikim nĂ« artikujt e ardhshĂ«m. NdĂ«rkohĂ«, po lĂ« vetĂ«m lidhje pĂ«r hulumtime vetjake. Â
Ilustrimi i gjendjes aktuale të infrastrukturës
Linket për studim
Linket për studim
Mjetet e ngjashme
- Â
- Â
7. Infrastrukturë si kod (IaC)
Përshkrimi i shkurtër i teknologjisë
Dhe ja, arritëm në seksionin e fundit. Zakonisht, kjo teknologji dhe detyrat e lidhura me të nuk janë përgjegjësi e inxhinierëve të automatizimit. Dhe ka arsye të veta për këtë. Së pari, në shumë organizata, çështjet infrastrukturore janë nën kontrollin e departamentit DevOps dhe ekipet e zhvillimit nuk shqetësohen shumë për mënyrën se si funksionon pipeline dhe se si duhet mbajtur gjithçka që lidhet me të. Së dyti, qofshim të sinqertë, praktika e "Infrastrukturë si kod (IaC)" ende nuk aplikohet në shumë kompani. Por pa dyshim, kjo ka bërë për një trend të njohur dhe është e rëndësishme të përpiqesh të jesh i përfshirë në proceset, qasjet dhe mjetet që lidhen me të. Ose, së paku, të jesh në dijeni të ngjarjeve.
Le të fillojmë me motivimin për të përdorur këtë qasje. Ne e kemi diskutuar tashmë se për të nisur testet në GitlabCI, na nevojiten së paku burime për të ekzekutuar Gitlab Runner. Dhe për të ekzekutuar kontejnerët me shfletues/emulatorë, na nevojitet të rezervojmë një VM ose një klaster. Në përveç burimeve për testim, na nevojitet një numër i konsiderueshëm kapacitetesh për të mbështetur mjediset e zhvillimit, staging, production, që gjithashtu përfshin bazat e të dhënave, oraret automatike, konfigurimet e rrjetit, balancuesin e ngarkesës, të drejtat e përdoruesve dhe kështu me radhë. Problemi kryesor është në përpjekjet e kërkuara për të mbështetur të gjithë këtë. Ka disa mënyra si mund të bëjmë ndryshime dhe të publikojmë përditësime. Për shembull, në kontekstin e GCP, mund të përdorim UI-në e konsolës në shfletues dhe të kryejmë të gjitha veprimet me klikimin e butonave. Një mënyrë alternative mund të jetë përdorimi i thirrjeve API për t'u angazhuar me entitetet cloud ose aplikimi i utilitetit të linjës së komandave gcloud për të kryer manipulimet e nevojshme. Por me një numër të vërtetë të entiteteve dhe elementeve infrastrukturore, bëhet e vështirë ose madje edhe e pamundur të kryhen të gjitha operacionet manualisht. Për më tepër, të gjitha këto veprime manuale janë të pa kontrolluara. Ne nuk mund t'i dërgojmë ato në review para se t'i kryejmë, të përdorim një sistem kontrolli versioni dhe të rikthejmë shpejt ndryshimet që çuan në incident. Për të zgjidhur këto probleme, inxhinierët kanë krijuar dhe vazhdojnë të krijojnë skripte automatike bash/shell, që nuk janë shumë më të mira se metodat e mëparshme, pasi nuk janë aq të lehta për t'u lexuar shpejt, për t'u kuptuar, për t'u mbështetur dhe për t'u modifikuar në stilin procedural.
Në këtë artikull dhe udhëzues praktik, unë po përdor 2 mjetet që i përkasin praktikës së IaC. Këto janë Terraform dhe Ansible. Disa mendojnë se nuk ka kuptim të përdoren ato njëkohësisht, pasi funksionet e tyre janë të ngjashme dhe janë të ndërlidhura. Megjithatë, e vërteta është se fillimisht u jepen atyre detyra krejtësisht të ndryshme. Faktin se këto mjete duhet të plotësojnë njëri-tjetrin e konfirmuan në një prezantim të përbashkët zhvilluesit që përfaqësonin kompanitë HashiCorp dhe RedHat. Diferenca konceptuale qëndron në faktin se Terraform është një mjet provisioning për menaxhimin e vetë serverëve. Ndërsa Ansible është një mjet për menaxhimin e konfigurimeve, detyra e të cilit është instalimi, konfigurimi dhe menaxhimi i softuerit në këta serverë.
NjĂ« tjetĂ«r dallim i rĂ«ndĂ«sishĂ«m mes kĂ«tyre mjeteve Ă«shtĂ« stili i shkruarjes sĂ« kodit. Ndryshe nga bash dhe Ansible, Terraform pĂ«rdor njĂ« stil deklarativ, i bazuar nĂ« pĂ«rshkrimin e shtetit pĂ«rfundimtar tĂ« dĂ«shiruar qĂ« duhet arritur si rezultat i ekzekutimit. PĂ«r shembull, nĂ«se ne planifikojmĂ« tĂ« krijojmĂ« 10 VMs dhe tĂ« aplikojmĂ« ndryshimet pĂ«rmes Terraform, atĂ«herĂ« do tĂ« marrim 10 VMs. NĂ«se aplikojmĂ« skritpnin pĂ«rsĂ«ri, asgjĂ« nuk do tĂ« ndodhĂ«, pasi ne tashmĂ« kemi 10 VMs, dhe Terraform e di kĂ«tĂ«, pasi ruan gjendjen aktuale tĂ« infrastrukturĂ«s nĂ« njĂ« skedar state. NdĂ«rsa Ansible pĂ«rdor njĂ« qasje procedurale dhe, nĂ«se e kĂ«rkojmĂ« tĂ« krijojĂ« 10 VMs, atĂ«herĂ« nĂ« ekzekutimin e parĂ« do tĂ« marrim 10 VMs, njĂ«lloj si me Terraform. Por pas ekzekutimit tĂ« dytĂ«, do tĂ« kemi tashmĂ« 20 VMs. Kjo Ă«shtĂ« dallimi i rĂ«ndĂ«sishĂ«m. NĂ« stilin procedural ne nuk ruajmĂ« gjendjen aktuale dhe thjesht pĂ«rshkruajmĂ« sekuencĂ«n e hapave qĂ« duhet tĂ« kryhen. Sigurisht, ne mund tĂ« pĂ«rpunojmĂ« situata tĂ« ndryshme, tĂ« shtojmĂ« disa kontrolla mbi ekzistencĂ«n e burimeve dhe gjendjen aktuale, por nuk ka kuptim tĂ« harxhojmĂ« kohĂ«n tonĂ« dhe tĂ« bĂ«jmĂ« pĂ«rpjekje pĂ«r tĂ« kontrolluar kĂ«tĂ« logjikĂ«. PĂ«r mĂ« tepĂ«r, kjo rrit riskun pĂ«r tĂ« bĂ«rĂ« gabime.Â
Duke përmbledhur gjithçka të thënë më lart, mund të përfundojmë se për provisioning e serverëve, mjeti më i përshtatshëm është Terraform dhe notacioni deklarativ. Ndërsa punën për menaxhimin e konfigurimeve është më mirë ta delegojmë tek Ansible. Tani që e kuptuam këtë, le të shikojmë shembujt e përdorimit në kontekstin e automatizimit.
Vlera për infrastrukturën e automatizimit
ĂshtĂ« e rĂ«ndĂ«sishme tĂ« kuptohet se infrastruktura e automatizimit tĂ« testimit duhet tĂ« konsiderohet si njĂ« pjesĂ« e tĂ«rĂ« tĂ« infrastrukturĂ«s sĂ« kompanisĂ«. Kjo do tĂ« thotĂ« se tĂ« gjitha praktikat e IaC duhet tĂ« aplikohen globalisht nĂ« burimet e gjithĂ« organizatĂ«s. Kush Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r kĂ«tĂ« varet nga proceset tuaja. Ekipi DevOps Ă«shtĂ« mĂ« i pĂ«rgatitur nĂ« kĂ«to çështje, ata e shohin tĂ« gjithĂ« imazhin e situatĂ«s. MegjithatĂ«, inxhinierĂ«t e QA janĂ« mĂ« shumĂ« tĂ« angazhuar nĂ« procesin e ndĂ«rtimit tĂ« automatizimit dhe strukturĂ«n e pipeline, duke i lejuar ata tĂ« shohin mĂ« mirĂ« tĂ« gjitha ndryshimet e nevojshme dhe mundĂ«sitĂ« pĂ«r pĂ«rmirĂ«sim. Opsioni mĂ« i mirĂ« Ă«shtĂ« tĂ« punoni sĂ« bashku, tĂ« shkĂ«mbeni njohuri dhe ide pĂ«r tĂ« arritur rezultatet e pritura.Â
Le të jap disa shembuj të përdorimit të Terraform dhe Ansible në kontekstin e automatizimit të testimit dhe mjeteve që kemi diskutuar më parë:
1. Të përshkruajnë përmes Terraform karakteristikat dhe parametrat e nevojshëm për VMs dhe klasterët.
2. Të instalojnë me Ansible mjetet e nevojshme për testim: docker, Selenoid, Selenium Grid dhe të ngarkojnë versionet e nevojshme të shfletuesve/emulatorëve.
3. Të përshkruajnë përmes Terraform karakteristikat e VM ku do të nisë GitLab Runner.
4. Të instalojnë me Ansible GitLab Runner dhe mjetet përkatëse, të vendosin cilësimet dhe konfigurimet.
Ilustrimi i gjendjes aktuale të infrastrukturës
Linket për studim:
Mjetet e ngjashme
Të përmblidhemi!
Hapi
Teknologjia
Mjetet
Vlera për infrastrukturën e automatizimit
1
Ekzekutimi lokal
Node.js, Selenium, Appium
- Mjetet më të njohura për web dhe mobile
- Mbështetje për shumë gjuhë dhe platforma (përfshirë Node.js)
2
Sistemet e kontrollit tĂ« versioneveÂ
Git
- Avantazhe të ngjashme me kodin e zhvillimit
3
Kontraktimi
Docker, Selenium grid, Selenoid (Web, Android)
- Ekzekutimi paralel i testeve
- Mjedise të izoluara
- Përditësim të thjeshtë dhe fleksibël të versioneve
- Ndalesë dinamike e burimeve që nuk përdoren
- E lehtë për t'u konfigurim
4
CI / CD
Gitlab CI
- Testet pjesë e konvejnerit
- Feedback i shpejtë
- Dukshmëri për të gjithë kompaninë / ekipin
5
Platformat e cloud
Google Cloud Platform
- Burimet sipas kërkesës (paguajmë vetëm kur janë të nevojshme)
- E lehtë për t'u menaxhuar dhe për të përditësuar
- Dukshmëri dhe kontroll mbi të gjitha burimet
6
Orkestrimi
Kubernetes
Në kontekstin e konteinerëve me shfletues/emulatorë brenda pods:
- Shkallëzim / automatik-shkallëzim
- Vetë-riparim
- Përditësime dhe rikthime pa ndërprerje
7
Infrastrukturë si kod (IaC)
Terraform, Ansible
- Avantazhe të ngjashme me infrastruktura e zhvillimit
- Të gjitha avantazhet e versionimit të kodit
- E lehtë për të bërë ndryshime dhe për të mbajtur
- Krejtësisht e automatizuar
Diagramat e hartës mendore: evolucioni i infrastrukturës
hapi1: Lokal
hapi2: VCS
hapi3: KontejnerizimiÂ
hapi4: CI/CDÂ
hapi5: Platformat Cloud
hapi6: Orkestrimi
hapi7: IaC
ĂfarĂ« ndodh mĂ« tej?
Pra, ky është fundi i artikullit. Por në përfundim, do doja të vendosja disa marrëveshje me ju.
Nga ana juaj
Siç u tha në fillim, do doja që artikulli të ofronte përfitime praktike dhe t'ju ndihmojë të aplikoni njohuritë e fituara në punën reale. Po shtoj përsëri.
Por edhe pas kësaj, mos u ndalni, praktikoni, studioni lidhjet përkatëse dhe librat, merrni vesh se si funksionon në kompaninë tuaj, gjeni vende që mund të përmirësohen dhe merrni pjesë në këtë. Fat të mbarë!
Nga ana ime
Nga titulli duket se ishte vetëm pjesa e parë. Megjithëse ajo doli mjaft e gjatë, këtu ende nuk janë trajtuar tema të rëndësishme. Në pjesën e dytë planifikoj të shqyrtoj infrastrukturen e automatizimit në kontekstin e IOS. Për shkak të kufizimeve të Apple në lidhje me ekzekutimin e simulatorëve IOS vetëm në sistemet macOS, gamën tonë të zgjidhjeve e kemi të ngushtë. Për shembull, jemi të privuar nga mundësia për të përdorur Docker për të ekzekutuar simulatorin ose re të hapura për të ekzekutuar makina virtuale. Por kjo nuk do të thotë se nuk ka alternativa të tjera. Do përpiqem t'ju mbaj të informuar mbi zgjidhjet e avancuara dhe mjetet moderne!
Gjithashtu, nuk përmenda tema mjaft të mëdha që lidhen me monitorimin. Në pjesën 3 do të shqyrtoj mjetet më të njohura për monitorimin e infrastrukturës, si dhe cilat të dhëna dhe metrika duhen marrë parasysh.
Dhe përfundimisht. Në të ardhmen planifikoj të publikoj një kurs video për ndërtimin e infrastrukturës për testim dhe mjetet më të njohura. Aktualisht, në internet ka mjaft kurse dhe leksione në lidhje me DevOps, por të gjitha materialet janë paraqitur në kontekstin e zhvillimit, jo të automatizimit të testimit. Në këtë çështje më duhet shumë feedback, a do të ishte një kurs i tillë interesant dhe i vlefshëm për komunitetin e testuesve dhe automatizuesve? Faleminderit paraprakisht!
Burimi: habr.com
