Pjesa 1: Web / Android
Shënim: ky artikull është përkthim në shqip i artikullit origjinal Megjithatë, të gjitha ilustrimet, lidhjet, citatet dhe terma janë ruajtur në gjuhën origjinale për të shmangur shkeljen e kuptimit gjatë përkthimit në shqip. Ju uroj një studim të këndshëm!
Aktualisht, specializimi DevOps Ă«shtĂ« njĂ« nga mĂ« tĂ« kĂ«rkuarat nĂ« industrinĂ« e IT. NĂ«se hapni faqet e njohura pĂ«r kĂ«rkimin e punĂ«s dhe vendosni filtrin pĂ«r pagat, do tĂ« shihni se ofertat e punĂ«s lidhur me DevOps janĂ« nĂ« fillim tĂ« listĂ«s. MegjithatĂ«, Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« kuptohet se kjo lidhet kryesisht me pozitat âSeniorâ, gjĂ« qĂ« nĂ«nkupton se kandidati ka njĂ« nivel tĂ« lartĂ« aftĂ«sish, njohuri pĂ«r teknologji dhe mjete. Kjo gjithashtu vjen me njĂ« shkallĂ« tĂ« lartĂ« pĂ«rgjegjĂ«sie lidhur me funksionimin e vazhdueshĂ«m tĂ« production. MegjithatĂ«, kemi filluar tĂ« harrojmĂ« se çfarĂ« Ă«shtĂ« realisht DevOps. Fillimisht, kjo nuk ishte njĂ« person ose departament specifik. NĂ«se kĂ«rkojmĂ« definicione tĂ« kĂ«tij termi, do tĂ« gjejmĂ« shumĂ« substanca dhe tĂ« sakta, si metodologji, praktika, filozofi kulturore, grup koncepcionesh dhe kĂ«shtu me radhĂ«.
Specializimi im Ă«shtĂ« inxhinier i automatizimit tĂ« testeve (QA automation engineer), por unĂ« besoj se kjo nuk duhet tĂ« lidhet vetĂ«m me shkrimin e testeve automatike ose zhvillimin e arkitekturĂ«s sĂ« framework-ut pĂ«r teste. NĂ« vitin 2020, njohuritĂ« mbi infrastrukturĂ«n e automatizimit gjithashtu janĂ« tĂ« nevojshme. Kjo lejon qĂ« procesi i automatizimit tĂ« organizohet vetĂ«, duke filluar nga ekzekutimi i testeve dhe duke pĂ«rfunduar me ofrimin e rezultateve pĂ«r tĂ« gjithĂ« personat e interesuar nĂ« pĂ«rputhje me objektivat e vendosura. Si rezultat, aftĂ«sitĂ« DevOps janĂ« njĂ« faktor i domosdoshĂ«m pĂ«r kryerjen e kĂ«saj pune. Dhe gjithĂ« kjo Ă«shtĂ« e bukur, por fatkeqĂ«sisht, ka njĂ« problem (spoiler: ky artikull bĂ«n pĂ«rpjekje pĂ«r ta thjeshtuar kĂ«tĂ« problem). Ai qĂ«ndron nĂ« faktin se DevOps Ă«shtĂ« i komplikuar. Dhe kjo Ă«shtĂ« e qartĂ«, pasi kompanitĂ« nuk do tĂ« paguajnĂ« shumĂ« pĂ«r atĂ« qĂ« Ă«shtĂ« e lehtĂ« pĂ«r t'u bĂ«rë⊠NĂ« botĂ«n e DevOps ekziston njĂ« numĂ«r i madh mjetesh, termash, praktikash, qĂ« duhen zotĂ«ruar. Sidomos kjo Ă«shtĂ« e vĂ«shtirĂ« nĂ« fillim tĂ« karrierĂ«s dhe varet nga doĆwiadcja teknike e mbledhur.
Burimi:
KĂ«tu, mendoj se do ta pĂ«rfundojmĂ« me pjesĂ«n hyrĂ«se dhe do tĂ« fokusohemi nĂ« qĂ«llimin e kĂ«tij artikulli.Â
Për çfarë ka të bëjë ky artikull
NĂ« kĂ«tĂ« artikull, do tĂ« ndaj pĂ«rvojĂ«n time nĂ« ndĂ«rtimin e infrastrukturĂ«s pĂ«r automatizimin e testimit. NĂ« internet mund tĂ« gjeni shumĂ« burime informacioni rreth veglave tĂ« ndryshme dhe si t'i pĂ«rdorni ato, por do doja t'i shqyrtoja ato ekskluzivisht nĂ« kontekstin e automatizimit. Besoj se shumĂ« inxhinierĂ« tĂ« automatizimit e njohin situatĂ«n kur testet e zhvilluara, pĂ«rveç vetes, askush nuk i ekzekuton dhe nuk kujdeset pĂ«r mbĂ«shtetje. Si rezultat, testet bĂ«hen tĂ« tejkaluara dhe duhet tĂ« shpenzohet kohĂ« pĂ«r tâi aktualizuar. NĂ« fillim tĂ« karrierĂ«s, kjo mund tĂ« jetĂ« njĂ« detyrĂ« mjaft e vĂ«shtirĂ«: tĂ« zgjidhni nĂ« mĂ«nyrĂ« tĂ« mençur se cilat vegla duhet tĂ« ndihmojnĂ« pĂ«r t'u zbuluar kjo problematikĂ«, si t'i zgjidhni, konfiguroni dhe mbani. Disa testues kĂ«rkojnĂ« ndihmĂ« nga DevOps (individĂ«), dhe po tĂ« jemi tĂ« sinqertĂ«, njĂ« qasje e tillĂ« funksionon. NĂ« shumĂ« raste, kjo mund tĂ« jetĂ« opsioni i vetĂ«m, pasi na mungon transparenca mbi tĂ« gjitha varĂ«sitĂ«. Por, siç e dimĂ«, DevOps janĂ« djem tĂ« zĂ«nĂ«, sepse ata duhet tĂ« mendojnĂ« pĂ«r infrastrukturĂ«n e tĂ«rĂ« kompanisĂ«, implementimin, monitorimin, mikroshĂ«rbimet dhe detyra tĂ« tjera tĂ« ngjashme nĂ« varĂ«si tĂ« organizatĂ«s/faqes. Siç ndodh zakonisht, automatizimi nuk Ă«shtĂ« prioritet. NĂ« kĂ«to raste, duhet tĂ« pĂ«rpiqemi tĂ« bĂ«jmĂ« gjithçka nĂ« anĂ«n tonĂ« nga fillimi deri nĂ« fund. Kjo do ta reduktojĂ« varĂ«sinĂ«, do tĂ« pĂ«rshpejtojĂ« procesin e punĂ«s, do tĂ« pĂ«rmirĂ«sojĂ« aftĂ«sitĂ« tona dhe do tĂ« na lejojĂ« tĂ« shohim njĂ« pamje mĂ« tĂ« gjerĂ« tĂ« asaj qĂ« ndodh.
NĂ« kĂ«tĂ« artikull, paraqiten mjetet mĂ« tĂ« kĂ«rkuara dhe mĂ« tĂ« njohura, sĂ« bashku me mĂ«nyrĂ«n se si tĂ« pĂ«rdoren ato pĂ«r ndĂ«rtimin hap pas hapi tĂ« infrastrukturĂ«s sĂ« automatizimit. Ădo grup paraqitet me mjete qĂ« janĂ« verifikuar pĂ«rmes pĂ«rvojĂ«s 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Ă« tejkalueshme. Detyra jonĂ« inxhinierike Ă«shtĂ« tĂ« kuptojmĂ« parimet bazĂ«: pĂ«rse na nevojitet ky grup mjete dhe cilat detyra punĂ«s mund tĂ« zgjidhim me ndihmĂ«n e tyre. Prandaj, nĂ« fund tĂ« secilĂ«s seksioni, lĂ« lidhje pĂ«r mjete tĂ« ngjashme qĂ« ndoshta pĂ«rdoren nĂ« organizatĂ«n tuaj.
ĂfarĂ« nuk ka nĂ« kĂ«tĂ« artikull
Përsëris për të disatën herë, artikulli nuk është për mjete specifike, prandaj këtu nuk do të ketë fragmentesh kode nga dokumentacioni dhe përshkrime të komandave specifike. Por në fund të secilës seksion, lë lidhje për studim më të detajuar.
Kjo Ă«shtĂ« bĂ«rĂ« pĂ«r shkak se:Â
- këtë material është shumë e lehtë ta gjeni në burime të ndryshme (dokumentacion, libra, kurse video);
- nëse fillojmë të thellohemi, do të duhet të shkruajmë 10, 20, 30 pjesë të këtij artikulli (ndërsa planet janë 2-3);
- Thjesht nuk dua të humbas kohën tuaj, sepse ndoshta dëshironi të përdorni mjete të tjera për të arritur të njëjtat qëllime.
Praktika
Do të doja shumë që ky material të ishte i dobishëm për çdo lexues, dhe jo thjesht të lexohej dhe të harrohej. Në çdo studim, praktika është një komponent shumë i rëndësishëm. Për këtë, kam përgatitur. Po ashtu, do të keni detyra për të qenë të sigurt se nuk keni kopjuar verbërisht rreshtat e komandave të ekzekutimit.
Plani
Hapi
Teknologjia
Mjetet
1
Ekzekutimi lokal (pĂ«rgatitni teste demo web / android dhe ekzekutoni ato lokalmente)Â
Node.js, Selenium, Appium
2
Sistemet e kontrollit tĂ« versioneveÂ
Git
3
Containerizimi
Docker, Selenium grid, Selenoid (Web, Android)
4
CI / CD
Gitlab CI
5
Platforma në cloud
Google Cloud Platform
6
Orkestrimi
Kubernetes
7
Infrastruktura si kod (IaC)
Terraform, Ansible
Struktura e çdo seksioni
Për të mbajtur narrativin në një pamje të qartë, çdo seksion përshkruhet sipas skemës së mëposhtme:
- përshkrim të shkurtër të teknologjisë,
- vlera për infrastrukturën e automatizimit,
- ilustrimi i gjendjes aktuale të infrastrukturës,
- linket për studim,
- mjetet e ngjashme.
1. Ekzekutimi lokal i testeve
Përshkrim i shkurtër i teknologjisë
Ky Ă«shtĂ« thjesht njĂ« hap pĂ«rgatitor pĂ«r tĂ« nisur testet demonstrative nĂ« mĂ«nyrĂ« lokale dhe pĂ«r tĂ« verifikuar qĂ« 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Ă«rdoren ato qĂ« pĂ«rdoren nĂ« kompaninĂ« tuaj.Â
Megjithatë, si mjete automatizimi rekomandoj të përdorni Selenium WebDriver për platformat web dhe Appium për platformën Android, pasi në hapat e ardhshëm do të përdorim imazhe Docker që janë optimizuar për të punuar me këto mjete. Për më tepër, duke iu referuar kërkesave në shpalljet e punës, këto mjete janë më të kërkuara në treg.
Siç mund ta keni vënë re, ne po shqyrtojmë vetëm testet web dhe Android. Fatkeqësisht, IOS është një histori krejt e ndryshme (faleminderit Apple). Planifikoj të ilustroj zgjidhje dhe praktika të lidhura me IOS në pjesët e ardhshme.
Vlera për infrastrukturën e automatizimit
Nga këndvështrimi i infrastrukturës, nisja lokale nuk ka asnjë vlerë. Ju thjesht po kontrolloni nëse testet funksionojnë në makinën lokale në shfletuesit dhe simulatorët lokalë. Por megjithatë, kjo është një pikë fillestare e nevojshme.
Ilustrimi i gjendjes aktuale të infrastrukturës
Linket për studim
Vegla të ngjashme
- cdo gjuhë programuese që ju pëlqen, në bashkëpunim me Selenium/Appium - testet;
- çdo test;
- cdo test-runners.
2. Sistemet e kontrollit të versioneve (Git)
Përshkrim i shkurtër i teknologjisë
Nuk e ka të vështirë të themi se sistemi i kontrollit të versioneve është një pjesë jashtëzakonisht e rëndësishme e zhvillimit, si në ekip ashtu edhe individualisht. Duke u mbështetur në burime të ndryshme, mund të themi me siguri se Git është përfaqësuesi më i njohur. Sistemi i kontrollit të versioneve ofron shumë avantazhe, si shkëmbimi i kodit, ruajtja e versioneve, rikuperimi në degët e mëparshme, monitorimi i historisë së projektit, dhe kopjet rezervë. Nuk do t'i diskutojmë çdo pikë në detaje, pasi jam i sigurt se jeni të njohur me to dhe i përdorni në punën tuaj të përditshme. Por nëse ndodhemi në rastin tjetër, ju rekomandoj të ndaloni leximin e këtij artikulli dhe të plotësoni sa më shpejt këtë boshllëk.
Vlera për infrastrukturën e automatizimit
Dhe këtu mund të bëni një pyetje të arsyeshme: «Përse po na flet për Git? Të gjithë e dinë dhe e përdorin për kodin e zhvillimit, si dhe për kodin e testeve automatike». Do të jeni plotësisht të drejtë, por në këtë artikull po flasim për infrastrukturën dhe kjo seksion ka rol si një parashikim për seksionin 7: «Infrastruktura si kod (IaC)». Për ne, kjo do të thotë që e gjithë infrastruktura, duke përfshirë atë të testimit, përshkruhet në formë kode, për rrjedhojë mund t'i aplikojmë sisteme versionimi dhe të përfitojmë përfitime të ngjashme si për kodin e zhvillimit dhe automatizimin.
Do ta shqyrtojmë IaC më në detaje në hapin 7, por edhe tani mund të filloni të përdorni Git lokalisht duke krijuar një repository lokal. Pamja e përgjithshme do të jetë më e gjerë kur të shtojmë në infrastrukturë një repository të largët.
Ilustrimi i gjendjes aktuale të infrastrukturës
Linket për studim
Vegla të ngjashme
- Â
3. Kontenjerizimi (Docker)
Përshkrim i shkurtër i teknologjisë
Për të demonstruar se si containerizimi ka ndryshuar rregullat e lojës, le të kthehemi disa dekada mbrapa. Në ato kohë, njerëzit blinin dhe përdornin serverë për të drejtuar aplikacione. Por në shumicën e rasteve, resurset e nevojshme për funksionimin nuk njiheshin paraprakisht. Si rezultat, kompanitë shpenzonin para për të blerë serverë të fuqishëm dhe të shtrenjtë, por një pjesë e këtyre kapaciteteve nuk përdorej plotësisht.
Hapi tjetër i evolucionit ishin makinat virtuale (VM), që zgjidhën problemin e shpenzimeve për burime të papërdorura. Kjo teknologji lejonte që aplikacionet të funksiononin të pavarura nga njëra-tjetra brenda një serveri, duke ndarë hapësirë plotësisht të izoluar. Por, fatkeqësisht, çdo teknologji ka disavantazhet e saj. Funksionimi i VM kërkon një sistem operativ të plotë, i cili konsumon CPU, RAM, ruajtje dhe, varësisht nga sistemi operativ, duhet marrë parasysh edhe kostoja e licencës. Këta faktorë ndikojnë në shpejtësinë e ngarkesës dhe e komplikojnë portabilitetin.
Dhe ja, kemi arritur te kontenjerizimi. Përsëri, kjo teknologji zgjidhi problemin e mëparshëm, sepse kontenjerët nuk përdorin një OS të plotë, duke çliruar kështu një sasi të madhe burimesh dhe ofruar një zgjidhje të shpejtë dhe fleksibile për portabilitetin.
Sigurisht, teknologjia e kontenjerizimit nuk është diçka e re dhe u prezantua për herë të parë në fund të viteve '70. Në atë kohë, u zhvilluan shumë studime, përpjekje dhe eksperimente. Por pikërisht Docker adaptoi këtë teknologji dhe e bëri atë të lehtë për t'u aksesuar nga masa. Në ditët tona, kur flasim për kontenjerë, në shumicën e rasteve kemi parasysh Docker-in. Kur flasim për kontenjerët Docker, nënkuptojmë kontenjerët Linux. Mund të përdorim sisteme Windows dhe macOS për të ekzekutuar kontenjerë, por është e rëndësishme të kuptojmë se në këtë rast shfaqet një shtresë shtesë. Për shembull, Docker në Mac fshehurazi ekzekuton kontenjerë brenda një VM të lehtë Linux. Do të kthehemi përsëri te kjo temë kur të diskutojmë për ekranuarët Android brenda kontenjerëve, sepse këtu shfaqet një aspekt shumë i rëndësishëm që duhet të shqyrtohet më në detail.
Vlera për infrastrukturën e automatizimit
Ne kemi zbuluar se kontenizimi dhe Docker janë të shkëlqyera. Le të shohim këtë në kontekstin e automatizimit, sepse çdo mjet ose teknologji duhet të zgjidhë një problem. Le të përcaktojmë problemet e dukshme të automatizimit të testimit në kontekstin e testeve UI:
- numër i madh varësish gjatë instalimit të Selenium dhe veçanërisht të Appium;
- probleme pajtueshmërie midis versioneve të shfletuesve, simulatoreve dhe driverëve;
- mungesë e hapësirës së izoluar për shfletuesit/simulatoret, që është veçanërisht kritike për ekzekutimin paralel;
- është e vështirë të menaxhohet dhe të mbështetet, nëse duhet të ekzekutoni 10, 50, 100 ose madje 1000 shfletuesit njëkohësisht.
Por pasi qĂ« Selenium Ă«shtĂ« mjeti mĂ« popullor i automatizimit dhe Docker Ă«shtĂ« mjeti mĂ« popullor i kontenizimit, nuk duhet tĂ« jetĂ« befasi pĂ«r askĂ«nd qĂ« dikush pĂ«rpiqet t'i bashkojĂ« kĂ«to dy pĂ«r tĂ« krijuar njĂ« mjet tĂ« fuqishĂ«m pĂ«r zgjidhjen e problemeve tĂ« mĂ«sipĂ«rme. Le tĂ« shqyrtojmĂ« zgjidhjet e tilla mĂ« nĂ« detaje.Â
Selenium grid në docker
Ky kyç është mjeti më i njohur në botë për Selenium për të drejtuar disa shfletues në disa makina dhe për t'i menaxhuar ato nga një qendër. Për të drejtuar të paktën 2 komponentë: Hub dhe Node(s) duhet të regjistrohemi. Hub është qendra që merr të gjitha kërkesat nga testet dhe i shpërndan ato në Nodes përkatëse. Për çdo Node mund të konfiguroni specifikime konkrete, si për shembull të tregoni shfletuesin dhe versionin e tij të dëshiruar. Megjithatë, na nevojitet ende të sigurohemi për shoferët 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ë formën e tij të pastër, përveç rasteve kur na nevojitet të punojmë me shfletues që nuk mund të instalohen në sistemi operacional Linux. Për të gjitha rastet e tjera, një zgjidhje shumë fleksibël dhe e përshtatshme do të ishte përdorimi i imazheve Docker për të drejtuar Selenium grid Hub dhe Nodes. Ky qasje shumë e lehtëson menaxhimin e nodëve, pasi mund të zgjedhim imazhin e dëshiruar me versionet e shfletuesve dhe shoferëve të përputhshëm tashmë të instaluara.
MegjithĂ«se ka komente negative mbi stabilitetin e operimit, veçanĂ«risht kur ekzekutohen njĂ« numĂ«r i madh Nodes paralelisht, Selenium grid vazhdon tĂ« mbetet mjeti mĂ« i njohur pĂ«r ekzekutimin paralel tĂ« testeve Selenium. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se nĂ« open-source po shfaqen vazhdimisht pĂ«rmirĂ«sime dhe modifikime tĂ« ndryshme tĂ« kĂ«tij mjeti, tĂ« cilat pĂ«rballen me ngushticat e ndryshme.
Selenoid për Web
Kyta mjet është një revolucion në botën e Selenium, pasi funksionon menjëherë nga kutia dhe ka bërë jetën e shumë inxhinierëve të automatizimit ndjeshëm më të lehtë. Së pari, kjo nuk është thjesht një modifikim tjetër i Selenium grid. Në vend të kësaj, zhvilluesit kanë krijuar një version krejtësisht të ri të Selenium Hub në gjuhën Golang, e cila, në lidhje me imazhet e lehta Docker për shfletues të ndryshëm, ka dhënë një nxitje në zhvillimin e automatizimit të testeve. Për më tepër, në rastin e Selenium Grid, ne duhet të përcaktojmë të gjithë shfletuesit dhe versionet e tyre të kërkuara paraprakisht, ç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ë, falë funksionit 'shfletues sipas kërkesës'. Të gjitha që na nevojitet është të shkarkojmë paraprakisht imazhet e nevojshme të shfletuesve dhe të azhurnojmë skedarin e konfigurimit me të cilin ndërvepron Selenoid. Pas kërkesës nga testet, Selenoid automatikisht do të nisë kontejnerin e nevojshëm me shfletuesin përkatës. Pas përfundimit të testit, Selenoid do të heqë kontejnerin, duke e liruar kështu burimin për kërkesa të ardhshme. Ky qasje eliminon plotësisht problemin e njohur të 'degradimit të nyjave', të cilin shpesh e hasim në Selenium grid.
Megjithatë, Selenoid nuk është ende një zgjidhje magjike. 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 angazhojmë atë në harduerin fizik ose në VM, që do të thotë se duhet të dimë paraprakisht sa burime na nevojiten. Mendoj se kjo nuk është një problem për projektet e vogla që ekzekutojnë 10, 20 ose madje 30 shfletues paralelisht. Por çfarë ndodh nëse na duhen 100, 500, 1000 e më shumë? Nuk ka kuptim të mbash dhe të paguash për një numër kaq të madh burimesh vazhdimisht. Në seksionet 5 dhe 6 të këtij artikulli, ne do të diskutojmë zgjidhjet që lejojnë të shkallëzohen, duke ulur ndjeshëm kostot për kompaninë.
Selenoid për Android
Pas suksesit tĂ« Selenoid si njĂ« instrument pĂ«r automatizimin web, njerĂ«zit dĂ«shironin tĂ« kishin diçka tĂ« ngjashme pĂ«r Android. Dhe kjo ndodhi â Selenoid u lançua me mbĂ«shtetje pĂ«r Android. Nga pikĂ«pamja e pĂ«rdoruesit, principi i funksionimit Ă«shtĂ« i ngjashĂ«m me automatizimin web. Dallimi i vetĂ«m Ă«shtĂ« se, nĂ« vend tĂ« kontejnerĂ«ve me shfletues, Selenoid nis kontejnerĂ« me emulatorĂ« Android. Sipas mendimit tim, deri mĂ« sot, ky Ă«shtĂ« instrumenti mĂ« i fuqishĂ«m falas pĂ«r tĂ« executuar teste Android nĂ« paralel.
Nuk doja tĂ« flas pĂ«r anĂ«t negative tĂ« kĂ«tij instrumenti, pasi mĂ« pĂ«lqen shumĂ«. MegjithatĂ«, ka disa tĂ« njĂ«jtat kufizime si nĂ« web-automatikĂ«n e lidhur me shkallĂ«zimin. PĂ«rveç kĂ«saj, Ă«shtĂ« e nevojshme tĂ« pĂ«rmendim njĂ« kufizim tjetĂ«r qĂ« mund tĂ« jetĂ« befasues nĂ«se po e konfiguroni kĂ«tĂ« instrument pĂ«r herĂ« tĂ« parĂ«. PĂ«r tĂ« nisur imazhet Android na nevojitet njĂ« makinĂ« fizike ose VM me mbĂ«shtetje pĂ«r virtualizimin nĂ« nivele tĂ« thella. NĂ« udhĂ«zimin praktik, tregoj si ta aktivizoni kĂ«tĂ« nĂ« njĂ« VM Linux. MegjithatĂ«, nĂ«se jeni pĂ«rdorues i macOS dhe dĂ«shironi tĂ« shkoni nĂ« Selenoid lokal, do tĂ« jetĂ« e pamundur tĂ« ekzekutoni testet Android. Por gjithmonĂ« mund tĂ« nisni njĂ« VM Linux lokal me âvirtualizimin nĂ« nivele tĂ« thellaâ tĂ« aktivizuar dhe tĂ« vendosni Selenoid brenda.
Ilustrimi i gjendjes aktuale të infrastrukturës
NĂ« kontekstin e kĂ«tij artikulli, 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, do tĂ« tregoj gjithashtu si tĂ« pĂ«rdorni Selenoid pĂ«r tĂ« ekzekutuar testet web.Â
Linket për studim
Vegla të ngjashme
- EkzistojnĂ« mjete tĂ« tjera tĂ« konteinerizimit, 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ç është thënë tashmë, ekzistojnë shumë modifikime të Selenium grid, për shembull,.
4. CI / CD
Përshkrim 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ë, ndiej se ekziston konfuzion në terminologji. Në këtë paragraf, dëshiroj të përshkruaj 3 modifikime të kësaj teknologjie nga pikëpamja ime. Në internet mund të gjeni shumë artikuj me interpretime të ndryshme, dhe është plotësisht normale nëse mendimi juaj ndryshon. Më e rëndësishmja, është që të jeni në të njëjtën valë me kolegët tuaj.
Pra, ekzistojnĂ« 3 terma: CI â Integrimi i VazhdushĂ«m (Continuous Integration), CD â DorĂ«zimi i VazhdushĂ«m (Continuous Delivery) dhe sĂ«rish CD â Zbatimi i VazhdushĂ«m (Continuous Deployment). (MĂ« tutje, do tĂ« pĂ«rdor kĂ«ta terma nĂ« anglisht). Ădo modifikim shton disa etapa tĂ« tjera nĂ« procesin tuaj tĂ« zhvillimit. Por fjala e vazhdueshme Ă«shtĂ« mĂ« e rĂ«ndĂ«sishmja. NĂ« kĂ«tĂ« kontekst, ne ĐżĐŸĐŽŃĐ°Đ·ŃĐŒĐ”ĐČĐ°ŃŃ diçka qĂ« ndodh nga fillimi deri nĂ« fund, pa ndĂ«rprerje apo ndĂ«rhyrje manuale. Le tĂ« shohim CI & CD dhe CD nĂ« kĂ«tĂ« kontekst.
- Integrimi i vazhdueshĂ«m â Ă«shtĂ« hapi fillestar i evolucionit. Pas dĂ«rgimit tĂ« kodit tĂ« ri nĂ« server, ne presim tĂ« marrim njĂ« pĂ«rgjigje tĂ« shpejtĂ«, qĂ« ndryshimet tona janĂ« nĂ« rregull. Zakonisht, CI pĂ«rfshin ekzekutimin e mjeteve pĂ«r analizimin statik tĂ« kodit dhe teste tĂ« brendshme tĂ« API-ve modulare. Kjo lejon tĂ« marrim informacion nĂ« lidhje me kodin tonĂ« vetĂ«m disa sekonda/mĂ« vonĂ«.
- Continuous Delivery është një hap më i avancuar, ku ne nisnim testet integruese/UI. Megjithatë, në këtë fazë ne nuk marrim rezultate aq shpejt si në rastin e CI. Në radhë të parë, këto lloje testesh kërkojnë më shumë kohë për t'u realizuar. Në të dytën, para se të nisnim, duhet të implementojmë ndryshimet tona në ambientin test/staging. Më shumë se kaq, nëse flasim për zhvillimin e aplikacioneve mobile, do të ketë një hap shtesë për krijimin e versionit të aplikacionit tonë.
- Continuous Deployment parashikon që ne automatikisht lëshojmë (release) ndryshimet tona në production, nëse të gjitha testet e pranuara janë kaluar në fazat e mëparshme. Përveç kësaj, pas fazës release mund të konfigurohen faza të ndryshme, siç është ekzekutimi i testeve smoke në production dhe mbledhja e metrikeve të interesit. Continuous Deployment është e mundur vetëm me një mbulueshmëri të mirë nga testet automatike. Nëse kërkohen ndërhyrje manuale, duke përfshirë testimin, atëherë kjo nuk është më Continuous (pa ndërprerje). Atëherë ne mund të flasim që kona i ynë përputhet vetëm me praktikën e Continuous Delivery.
Vlera për infrastrukturën e automatizimit
NĂ« kĂ«tĂ« seksion, dua tĂ« theksoj se kur flasim pĂ«r testet UI end-to-end, kjo do tĂ« thotĂ« se duhet tĂ« deploy-nĂ« ndryshimet tona dhe shĂ«rbimet lidhĂ«se nĂ« ambientet testuese. Continuous Integration â procesi nuk aplikohet pĂ«r kĂ«tĂ« detyrĂ« dhe duhet tĂ« kujdesemi pĂ«r tĂ« implementuar praktikĂ«n e paktĂ«n tĂ« Continuous Delivery. Continuous Deployment ka gjithashtu kuptim nĂ« kontekstin e testeve UI, nĂ«se planifikojmĂ« t'i ekzekutojmĂ« ato nĂ« production.
Dhe para se të shohim ilustrimin e ndryshimit të arkitekturës, dua të them disa fjalë për GitLab CI. Ndryshe nga mjetet e tjera CI/CD, GitLab ofron një depo të largët dhe shumë funksione të tjera shtesë. Prandaj, GitLab është më shumë se CI. Ai përfshin nga kutia menaxhimin e kodit burimor, menaxhimin Agile, CI/CD pipelines, mjetet e logimit 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 në internet me një API që ruan gjendjen e tij në një bazë të dhënash, menaxhon projektet/build-et dhe ofron një ndërfaqe përdoruesi. GitLab Runner është një aplikacion që proceson build-et. Ai mund të deploy-het veçmas dhe punon me GitLab CI/CD përmes një API. Për ekzekutimin e testeve, ju nevojiten si instanca e GitLab ashtu edhe Runner-i.
Ilustrimi i gjendjes aktuale të infrastrukturës
Linket për studim
Vegla të ngjashme
- Â
- Dhe shumë të tjera
5. Platforma të cloud
Përshkrim i shkurtër i teknologjisë
Në këtë seksion, do të flasim për një trend të njohur që quhet 'rrjetet publike të reja'. Pavarësisht nga përfitimet e mëdha që ofrojnë teknologjitë e përshkruara më sipër për virtualizimin dhe kontejnerizimin, ne ende kemi nevojë për burime kompjuterike. Kompanitë blejnë servera të shtrenjtë ose paguajnë për qendrat e të dhënave, por në këtë rast, është e nevojshme të bëhen kalkulime (ndonjëherë të paarsyeshme) për 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 produksi, na nevojitet një server aktiv 24 orë, por a na duhen burime të ngjashme për testimin jashtë orarit të punës? Kjo varet gjithashtu nga lloji i testimit që po bëjmë. Një shembull mund të jenë testet e ngarkesës/stresit, të cilat planifikojmë t'i realizojmë jashtë orareve të punës për të marrë rezultate për ditën tjetër. Por, patjetër, qasja 24-orëshe në servera nuk është e nevojshme për testet automatike end-to-end dhe sidomos për ambientet e testimit manual. Për këto situata do të ishte mirë të merrnim aq burime sa na nevojiten në kërkesë, t'i përdorim dhe të ndalojmë pagesat kur ato nuk janë më të nevojshme. Më tej, do të ishte e mrekullueshme t'i merrnim ato menjëherë, duke bërë disa klikime ose duke nisur disa skripta. Për këtë qëllim përdoren rrjetet publike. Le të shohim përkufizimin:
«Ndexhi i publike përkufizohet si shërbime kompjuterike të ofruara nga ofrues të jashtëm përmes Internetit publik, duke i bërë ato të disponueshme për këdo që dëshiron t'i përdorë ose t'i blejë. Ato mund të jenë falas ose të shiten sipas kërkesës, duke i lejuar klientët të paguajnë vetëm për përdorimin për ciklet e CPU, ruajtjen ose bandwidth-in që konsumojnë».
Ekziston njĂ« mendim i zakonshĂ«m se re tĂ« publikut janĂ« tĂ« shtrenjta. Por ideja kryesore e tyre Ă«shtĂ« ulja e shpenzimeve pĂ«r kompaninĂ«. Siç u pĂ«rmend mĂ« parĂ«, re tĂ« publikut lejojnĂ« qĂ« tĂ« merren burime sipas kĂ«rkesĂ«s dhe tĂ« paguhet 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Ă« merret nĂ« konsideratĂ« se re tĂ« publikut ndihmojnĂ« shumĂ« nĂ« mbĂ«shtetje tĂ« infrastrukturĂ«s, çka i lejon inxhinierĂ«t tĂ« pĂ«rqendrohen nĂ« detyra mĂ« tĂ« rĂ«ndĂ«sishme.Â
Vlera për infrastrukturën e automatizimit
Cilat burime konkretisht na nevojiten pĂ«r testimi UI end-to-end? Kryesisht, kĂ«to janĂ« makina virtuale ose klastere (do tĂ« flasim pĂ«r Kubernetes nĂ« seksionin e ardhshĂ«m) pĂ«r tĂ« nisur shfletuesit dhe emuluesit. MĂ« shumĂ« shfletues dhe emulues qĂ« dĂ«shirojmĂ« tĂ« nisim njĂ«kohĂ«sisht, aq mĂ« shumĂ« CPU dhe memorie na nevojitet dhe aq mĂ« shumĂ« do tĂ« duhet tĂ« paguajmĂ« pĂ«r kĂ«tĂ«. NĂ« kĂ«tĂ« mĂ«nyrĂ«, cloud-et publike nĂ« kontekstin e automatizimit tĂ« testimit na lejojnĂ« tĂ« nisnim njĂ« numĂ«r tĂ« madh (100, 200, 1000 âŠ) shfletuesish/emuluesish sipas kĂ«rkesĂ«s, tĂ« marrim rezultatet e testimit sa mĂ« shpejt tĂ« jetĂ« e mundur dhe tĂ« ndalojmĂ« sĂ« paguari pĂ«r kĂ«to kapacitete jashtĂ«zakonisht tĂ« shpenzuara me burime.Â
Ofertat mĂ« tĂ« njohura tĂ« shĂ«rbimeve nĂ« re janĂ« Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). NĂ« udhĂ«zuesin praktik, paraqiten 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Ă« funksionalitete tĂ« ngjashme. Zgjedhja e ofruesit zakonisht fokusohet nĂ« infrastrukturĂ«n e tĂ«rĂ« tĂ« kompanisĂ« dhe kĂ«rkesat e biznesit, qĂ« Ă«shtĂ« jashtĂ« kĂ«tij artikulli. PĂ«r inxhinierĂ«t e automatizimit, do tĂ« ishte mĂ« interesante tĂ« krahasohej pĂ«rdorimi i ofruesve tĂ« shĂ«rbimeve nĂ« re me pĂ«rdorimin e platformave specifike pĂ«r qĂ«llime testi, siç janĂ« Sauce Labs, BrowserStack, BitBar dhe kĂ«shtu me radhĂ«. Pra, le tĂ« bĂ«jmĂ« kĂ«tĂ«! NĂ« mendimin tim, Sauce Labs Ă«shtĂ« fermĂ« mĂ« e njohur e testeve nĂ« re, prandaj e kam zgjedhur atĂ« pĂ«r krahasim.Â
GCP kundër Sauce Labs për qëllime automatizimi:
Imagjinoni se na nevojitet tĂ« kryejmĂ« njĂ«kohĂ«sisht 8 teste web dhe 8 teste Android. PĂ«r kĂ«tĂ«, do tĂ« pĂ«rdorim GCP dhe do tĂ« nisim 2 makina virtuale me Selenoid. NĂ« tĂ« parĂ«n, do tĂ« ngremĂ« 8 kontejnerĂ« me shfletues. NĂ« tĂ« dytĂ«n â 8 kontejnerĂ« me emulues. Le tĂ« shikojmĂ« çmimet: Â
Për të nisur një kontejner me Chrome, na nevojitet n1-standard-1 makina. Në rastin e Android, kjo do të jetë n1-standard-4 për një emulator. Në të vërtetë, një mënyrë më fleksibël dhe më e lirë është përcaktimi i vlerave specifike për CPU/Memorie, por aktualisht për krahasim me Sauce Labs, kjo nuk është thelbësore.
Këtu janë tarifat për përdorimin e Sauce Labs:
Mendoj se e keni vënë re ndryshimin, por përsëri do të sjell 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Ă« * 12h * 0.38 = 104.88$Â
23 ditë * 12h * 0.08 = 22.08$
Sauce Labs për Web
Virtual Cloud 8 teste paralele
$1.559
â
â
GCP për Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 ditĂ« * 12h * 1.52 = 419.52$Â
23 ditë * 12h * 0.32 = 88.32$
Sauce Labs për Android
Real Device Cloud 8 teste paralele
$1.999
â
â
Siç duket, ndryshimi nĂ« kostot Ă«shtĂ« i madh, veçanĂ«risht nĂ«se ekzekutoni testet vetĂ«m gjatĂ« orarit tĂ« punĂ«s dymbĂ«dhjetĂ« orĂ«. Por mund tĂ« reduktoni kostot edhe mĂ« shumĂ« nĂ«se pĂ«rdorni makinat preemptible. ĂfarĂ« Ă«shtĂ« kjo?
Një VM preemptible është një instancë që mund të krijoni dhe ekzekutoni me një çmim shumë më të ulët se instancat normale. Megjithatë, Motorri i Llogaritjes mund t'i ndalë (preempt) këto instanca nëse ka nevojë për qasje në ato burime për detyra të tjera. Instancat preemptible janë kapacitet i tepruar i Motorit të Llogaritjes, kështu që disponibiliteti i tyre variacion me përdorimin.
Nëse aplikacionet tuaja janë të qëndrueshme ndaj defekteve dhe mund të përballojnë mundësitë e mundshme të ndërprerjes së instanceve, atëherë instancat e ndërprershme mund të ulin ndjeshëm kostot tuaja të Compute Engine. Për shembull, punët e përpunimit të grumbujve mund të ekzekutohen në instanca të ndërprershme. Nëse disa nga këto instance ndalen gjatë përpunimit, puna ngadalësohet, por nuk ndalon krejtësisht. Instancat e ndërprershme përfundojnë detyrat tuaja të përpunimit të grumbujve pa vendosur një ngarkesë shtesë mbi instancat tuaja ekzistuese dhe pa e bërë të nevojshme të paguani çmimin e plotë për instance normale shtesë.
Dhe kjo nuk është akoma fundi! Në të vërtetë, jam i sigurt që askush nuk bën testet për 12 orë pa pushim. Dhe nëse është kështu, atëherë mund të nisni dhe ndaloni automatikisht makinat virtuale kur ato nuk janë të nevojshme. Koha reale e përdorimit mund të ulet në 6 orë në ditë. Atëherë pagesa në kontekstin e detyrës tonë do të ulet deri në 11$ në muaj për 8 shfletues. A nuk është kjo e mrekullueshme? Por me makinat e ndërprershme duhet të jemi të kujdesshëm dhe të përgatitur për ndërprerje dhe funksionim të paqëndrueshëm, edhe pse këto situata mund të parashikohen dhe trajtohen programatikisht. Vlen!
Por tĂ« qenit tĂ« qartĂ«, unĂ« nuk po thĂ«mĂ« âkurrĂ« mos pĂ«rdorni ferma testimi nĂ« reâ. Ato kanĂ« disa pĂ«rfitime. Para sĂ« gjithash, nuk janĂ« vetĂ«m makina virtuale, por njĂ« zgjidhje e plotĂ« pĂ«r automatizimin e testimit me njĂ« paketĂ« funksionalitetesh qĂ« vijnĂ« nga kutia: akses nĂ« distancĂ«, regjistrime, skrinshot, videoincizime, shfletues tĂ« ndryshĂ«m dhe pajisje mobile fizike. NĂ« shumĂ« raste, kjo mund tĂ« jetĂ« njĂ« alternativĂ« e shkĂ«lqyer. Sidomos platformat e testimit janĂ« tĂ« dobishme pĂ«r automatizimin e IOS-it, kur reja publike ofron vetĂ«m sisteme Linux/Windows. Por biseda pĂ«r IOS-in do tĂ« jetĂ« nĂ« artikujt e ardhshĂ«m. UnĂ« rekomandoj qĂ« gjithmonĂ« tĂ« vlerĂ«soni situatĂ«n dhe tĂ« bazoheni nĂ« detyrat: ndonjĂ«herĂ« Ă«shtĂ« mĂ« e lirĂ« dhe efektive tĂ« pĂ«rdorni re publike, ndĂ«rsa nĂ« disa raste platformat e testimit padyshim qĂ« meritojnĂ« paratĂ« e shpenzuara.
Ilustrimi i gjendjes aktuale të infrastrukturës
Linket për studim
Mjete të ngjashme:
- Â
6. Orkestrimi
Përshkrim i shkurtër i teknologjisë
Kam njĂ« lajmi tĂ« mirĂ« â pothuajse arritĂ«m nĂ« fund tĂ« artikullit! Aktualisht, infrastruktura jonĂ« e automatizimit pĂ«rbĂ«het nga teste web dhe Android, tĂ« cilat i kryejmĂ« pĂ«rmes GitLab CI nĂ« mĂ«nyrĂ« paralelisht, duke pĂ«rdorur mjete me mbĂ«shtetje Docker: Selenium grid dhe Selenoid. PĂ«r mĂ« tepĂ«r, ne pĂ«rdorim makinat virtuale tĂ« krijuara pĂ«rmes GCP pĂ«r tĂ« ngritur nĂ« to kontejnerĂ« me shfletues dhe emulatorĂ«. PĂ«r tĂ« reduktuar shpenzimet, i aktivizojmĂ« kĂ«to makina virtuale vetĂ«m kur Ă«shtĂ« e nevojshme dhe i ndalojmĂ« kur testingu nuk Ă«shtĂ« nĂ« zhvillim. A ka diçka tjetĂ«r qĂ« mund tĂ« pĂ«rmirĂ«sojĂ« infrastrukturĂ«n tonĂ«? PĂ«rgjigjja Ă«shtĂ« po! MirĂ« se erdhi Kubernetes (K8s)!
SĂ« pari, le tĂ« shqyrtojmĂ« se si fjalĂ«t orkestrim, grumbull dhe Kubernetes janĂ« tĂ« lidhura me njĂ«ra-tjetrĂ«n. NĂ« njĂ« nivel tĂ« lartĂ«, orkestrimi Ă«shtĂ« njĂ« sistem qĂ« dislokon dhe menaxhon aplikacionet. PĂ«r automatizimin e testimit, aplikacionet e containerizuara janĂ« Selenium grid dhe Selenoid. Docker dhe K8s plotĂ«sojnĂ« njĂ«ri-tjetrin. I pari pĂ«rdoret pĂ«r dislokimin e aplikacioneve, i dyti â pĂ«r orkestrimin. Nga ana tjetĂ«r, K8s Ă«shtĂ« njĂ« grumbull. Detyra e grumbullit Ă«shtĂ« tĂ« pĂ«rdorĂ« VM-tĂ« si Node, qĂ« lejon instalimin e funksionaliteteve tĂ« ndryshme, programeve dhe shĂ«rbimeve brenda njĂ« serveri (grumbulli). NĂ«se ndonjĂ« Node rrĂ«zohet, atĂ«herĂ« Nodes tĂ« tjera do ta marrin pĂ«rsipĂ«r, duke garantuar funksionimin pa ndĂ«rprerje tĂ« aplikacionit tonĂ«. PĂ«rveç kĂ«saj, K8s ka njĂ« funksionalitet tĂ« rĂ«ndĂ«sishĂ«m qĂ« lidhet me shkallĂ«zimin (scaling), duke na ofruar automatikisht numrin optimal tĂ« burimeve, nĂ« bazĂ« tĂ« ngarkesĂ«s dhe kufizimeve tĂ« caktuara.
Sipas tĂ« vĂ«rtetĂ«, konfigurimi manual i Kubernetes nga zero Ă«shtĂ« njĂ« detyrĂ« mjaft e ndĂ«rlikuar. Do tĂ« lĂ« njĂ« lidhje me udhĂ«zimin e njohur praktik "Kubernetes The Hard Way", dhe nĂ«se jeni tĂ« interesuar, mund tĂ« praktikoni. Por, pĂ«r fat tĂ« mirĂ«, ekzistojnĂ« mĂ«nyra dhe mjete alternative. MĂ« i lehti prej tyre Ă«shtĂ« tĂ« pĂ«rdorni Google Kubernetes Engine (GKE) nĂ« GCP, i cili do tĂ« sigurojĂ« njĂ« klaster tĂ« gatshĂ«m pas disa klikimeve. PĂ«r fillimin e studimeve, rekomandoj tĂ« pĂ«rdorni kĂ«tĂ« qasje, pasi do t'ju lejojĂ« tĂ« pĂ«rqendroheni nĂ« mĂ«nyrĂ«n se si tĂ« pĂ«rdorni K8s pĂ«r nevojat tuaja nĂ« vend tĂ« eksplorimit tĂ« mĂ«nyrĂ«s se si komponentĂ«t e brendshĂ«m duhet tĂ« integrohen me njĂ«ri-tjetrin.Â
Vlera për infrastrukturën e automatizimit
Le të shqyrtojmë disa karakteristika të rëndësishme që ofron K8s:
- në shpërndarjen e aplikacioneve: përdorimi i një klasteri multi-nodes, në vend të VM-ve;
- shkallëzim dinamik: redukton shpenzimet për burimet, të cilat përdoren vetëm sipas kërkesës;
- riparimi automat (Self-healing): rikthimi automatik i pods (duke rikthyer gjithashtu dhe kontejnerët);
- rilizimi i përditësimeve dhe rikthimeve të ndryshimeve pa ndalje: përditësimi i mjeteve, shfletuesve dhe emulatorëve nuk e ndërpret punën e përdoruesve aktualë
Por K8s â ende nuk Ă«shtĂ« njĂ« plumb argjendi. PĂ«r tĂ« kuptuar tĂ« gjithĂ« pĂ«rfitimet dhe kufizimet nĂ« kontekstin e mjeteve qĂ« po shqyrtojmĂ« (Selenium grid, Selenoid), le tĂ« diskutojmĂ« shkurtimisht ndĂ«rtimin e K8s. Klasteri pĂ«rmban dy lloje nodash: Master Nodes dhe Workers Nodes. Master Nodes janĂ« pĂ«rgjegjĂ«s pĂ«r menaxhimin, shpĂ«rndarjen dhe vendimet e grafikut. Workers nodes â kĂ«tu janĂ« aplikaçionet qĂ« janĂ« tĂ« laufruara. Nodes gjithashtu pĂ«rmbajnĂ« mjedisin e ekzekutimit tĂ« kontejnerĂ«ve. NĂ« rastin tonĂ«, ky Ă«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 vetĂ«-riparimi nuk i referohet drejtpĂ«rdrejt kontejnerĂ«ve. Kjo realizohet pĂ«rmes shtimit/redukimit tĂ« numrit tĂ« pods, tĂ« cilat nga ana e tyre pĂ«rmbajnĂ« kontejnerĂ« (zakonisht njĂ« kontejner nĂ« pod, por nĂ« varĂ«si tĂ« detyrĂ«s mund tĂ« ketĂ« edhe mĂ« shumĂ«). Hierarkia nĂ« nivel tĂ« lartĂ« pĂ«rbĂ«n nodet e punĂ«s, brenda tĂ« cilave ndodhen pods, brenda tĂ« cilave ngrihen 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Ă« i pĂ«rkasin si nodes, ashtu edhe pods. Lloji i parĂ« â horizontal â shkallĂ«zimi ndodh pĂ«rmes rritjes sĂ« numrit tĂ« nodes/pods. Ky lloj Ă«shtĂ« mĂ« i preferuar. Lloji i dytĂ«, pĂ«rkatĂ«sisht, vertikal. ShkallĂ«zimi bĂ«het pĂ«rmes rritjes sĂ« dimensioneve tĂ« nodes/pods, jo tĂ« numrit tĂ« tyre.
Tani le të shqyrtojmë mjetet tona në kontekstin e termave të përmendur më sipër.
Selenium grid
Siç është përmendur më parë, Selenium grid është një mjet shumë i njohur, dhe nuk është befasi që ai është containerizuar. Prandaj, nuk është çudi që Selenium grid mund të implementohet në K8s. Një shembull se si ta bëni këtë mund të gjeni në depot zyrtare të K8s. Si zakonisht, po bashkangjisë lidhjet në fund të seksionit. Përveç kësaj, në udhëzimin praktik tregohet si ta realizoni këtë nëpërmjet Terraform. Ka gjithashtu një udhëzues se si të shkallëzoni numrin e pods që përmbajnë kontejnerë me shfletues. Por, funksioni i shkallëzimit automatizuar në kontekstin e K8s mbetet ende një detyrë jo plotësisht e qartë. Kur fillova studimin, nuk gjeta asnjë udhëzim praktik ose rekomandime. Pas disa kërkimeve dhe eksperimentesh me mbështetje nga ekipi DevOps, ne zgjodhëm qasjen e ngritjes së kontejnerëve me shfletuesit e nevojshëm brenda një pod-i që ndodhet brenda një node punues. Kjo qasje na lejon të aplikojmë strategjinë e shkallëzimit horizontal të nodes duke rritur numrin e tyre. Shpresoj që në të ardhmen situata të ndryshojë, dhe të shohim gjithnjë e më shumë përshkrime të metodave më të mira dhe zgjidhjeve të gatshme, veçanërisht pas lëshimit të Selenium grid 4 me arkitekturën e brendshme të ndryshuar.
Selenoid:
Aktualisht, shpërndarja e Selenoid në K8s është zhgënjimi më i madh. Ata nuk janë të kompatibilshëm. Teorikisht, mund të ngremë kontejnerin Selenoid brenda pod-it, por kur Selenoid fillon të nisë kontejnerët me shfletues, ata ende do të jenë brenda të njëjtit pod. Kjo bën që shkallëzimi të jetë e pamundur dhe, si rezultat, funksionimi i Selenoid brenda klasterit nuk do të jetë i ndryshëm nga funksionimi brenda një makine virtuale. Fundi i historisë.
Moon:
Duke e ditur kĂ«tĂ« ngushticĂ« kur punoni me Selenoid, zhvilluesit lĂ«shuan njĂ« mjet mĂ« tĂ« fuqishĂ«m, tĂ« cilin e quajtĂ«n Moon. Ky mjet ishte fillimisht konceptuar pĂ«r tĂ« punuar me Kubernetes dhe, si rezultat, mund dhe duhet tĂ« pĂ«rdoret funksioni i skalimit automatik. MĂ« shumĂ« se kaq, do tĂ« thosha se aktualisht Ă«shtĂ« i vetmi mĂ« i miri mjet nĂ« botĂ« pĂ«r Selenium, qĂ« nga arka vjen me mbĂ«shtetje native pĂ«r klasterin K8s (nuk ka mĂ«, shih mjetin e ardhshĂ«m ). Karakteristika kryesore e Moon, qĂ« siguron kĂ«tĂ« mbĂ«shtetje, Ă«shtĂ«:Â
PlotĂ«sisht pa gjendje. Selenoid ruan nĂ« memorje informacionin rreth sesioneve aktuale tĂ« shfletuesit. NĂ«se pĂ«r njĂ« arsye procesi i tij rrĂ«zohet â atĂ«herĂ« tĂ« gjitha sesionet nĂ« punĂ« humbasin. Moon, nga ana tjetĂ«r, nuk ka gjendje tĂ« brendshme dhe mund tĂ« riprodhohet nĂ«pĂ«r qendra tĂ« tĂ« dhĂ«nave. Sesionet e shfletuesit mbeten aktive edhe nĂ«se njĂ« ose mĂ« shumĂ« kopje bien.
Pra ndaj, Moon Ă«shtĂ« njĂ« zgjidhje e shkĂ«lqyer, por ka njĂ« problem: nuk Ă«shtĂ« falas. Ămimi varet nga numri i seancave. Mund tĂ« aktivizoni pa pagesĂ« vetĂ«m 0-4 seanca, qĂ« nuk Ă«shtĂ« shumĂ« e dobishme. MegjithatĂ«, duke filluar nga seanca e pestĂ«, do tĂ« duhet tĂ« paguani 5$ pĂ«r secilĂ«n. Situata mund tĂ« ndryshojĂ« nga kompanitĂ« e ndryshme, por nĂ« rastin tonĂ«, pĂ«rdorimi i Moon Ă«shtĂ« pa kuptim. Siç e pĂ«rshkrova mĂ« sipĂ«r, mund tĂ« aktivizojmĂ« VMs me Selenium Grid sipas kĂ«rkesĂ«s ose tĂ« rrisim numrin e Nodes nĂ« klaster. NĂ« mĂ«nyrĂ« aproximative, pĂ«r njĂ« pipeline aktivizojmĂ« 500 shfletues dhe ndalojmĂ« tĂ« gjitha burimet pas pĂ«rfundimit tĂ« testeve. Po tĂ« ishim pĂ«rdorur Moon, do tĂ« na duhej tĂ« paguanim 500 x 5 = 2500 $ nĂ« muaj, pavarĂ«sisht sa shpesh e aktivizojmĂ« testet. Dhe pĂ«rsĂ«ri, nuk po them "mos pĂ«rdorni Moon". PĂ«r nevojat tuaja, mund tĂ« jetĂ« njĂ« zgjidhje e pazĂ«vendĂ«sueshme, pĂ«r shembull, nĂ«se nĂ« organizatĂ«n tuaj ka shumĂ« projekte/equipe dhe ju nevojitet njĂ« klaster i madh pĂ«r tĂ« gjithĂ«. Si gjithmonĂ«, po lĂ« njĂ« lidhje nĂ« fund dhe rekomandoj tĂ« bĂ«ni tĂ« gjitha llogaritĂ« e nevojshme nĂ« kontekstin e detyrave tuaja.
Callisto: (Kujdes! Kjo nuk është në artikullin origjinal dhe përfshihet vetëm në përkthimin në rusisht.)
Siç thashĂ«, Selenium Ă«shtĂ« njĂ« mjet shumĂ« i njohur, dhe fusha e IT po zhvillohet shumĂ« shpejt. NdĂ«rsa punoja mbi pĂ«rkthimin, nĂ« internet doli njĂ« mjet i ri premtues Callisto (pĂ«rshĂ«ndetje Cypress dhe vrasĂ«sve tĂ« tjerĂ« tĂ« Selenium). Ai punon natyrshĂ«m me K8s dhe lejon ekzekutimin e kontejnerĂ«ve Selenoid nĂ« pods, shpĂ«rndarĂ« nĂ« Nodes. E gjithĂ« kjo funksionon menjĂ«herĂ« nga kutia, duke pĂ«rfshirĂ« automatikisht shkallĂ«zimin. Fantastike, por duhet testuar. MĂ« Ă«shtĂ« arritur tĂ« vendos kĂ«tĂ« mjet dhe tĂ« realizoj disa eksperimente. Por Ă«shtĂ« ende herĂ«t pĂ«r tĂ« nxjerrĂ« pĂ«rfundime; pas marrjes sĂ« rezultateve nĂ« njĂ« distancĂ« tĂ« gjatĂ«, ndoshta do tĂ« bĂ«j njĂ« rishikim nĂ« artikujt e ardhshĂ«m. Deri atĂ«herĂ«, lĂ« vetĂ«m lidhjet pĂ«r hulumtime tĂ« pavarura. Â
Ilustrimi i gjendjes aktuale të infrastrukturës
Linket për studim
Linket për studim
Vegla të ngjashme
- Â
- Â
7. Infrastrukturë si kod (IaC)
Përshkrim i shkurtër i teknologjisë
Dhe ja, po arrijmë në seksionin e fundit. Zakonisht, kjo teknologji dhe detyrat e lidhura me të nuk janë brenda fushës së përgjegjësisë së inxhinierëve të automatizimit. Dhe ka arsye për këtë. Së pari, në shumë organizata, çështjet infrastrukturore janë nën kontrollin e departamentit DevOps dhe ekipi i zhvillimit nuk shqetësohet shumë për atë se çfarë mban në funksion pipeline dhe si duhet të mbahen të gjitha gjërat që lidhen me të. Së dyti, të jemi të sinqertë, praktika e "Infrastrukturës si Kod (IaC)" ende nuk është aplikuar në shumë kompani. Por padyshim që ka filluar të bëhet një trend i njohur dhe është e rëndësishme të përpiqemi të jemi të angazhuar në proceset, qasjet dhe mjetet që lidhen me të. Ose, të paktën, të jemi në dijeni të ngjarjeve.
Të fillojmë me motivimin për përdorimin e këtij qasjeje. Ne tashmë kemi diskutuar se për të nisur testet në GitlabCI, na nevojiten së paku burime për të nisur Gitlab Runner. Dhe për të nisur kontenierët me shfletues/emulatorë, na nevojitet të rezervojmë një VM ose një klaster. Përveç burimeve për testim, na nevojitet një numër të konsiderueshëm kapacitetesh për të mbështetur ambientet e zhvillimit, staging, dhe 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 qëndron te përpjekjet e nevojshme për të mbështetur gjithçka këtë. Ekzistojnë disa mënyra se si mund të bëjmë ndryshime dhe të publikojmë përditësime. Për shembull, në kontekstin e GCP, mund të përdorim konzolën UI në shfletues dhe të kryejmë të gjitha veprimet duke klikuar butona. Një mënyrë alternative mund të jetë përdorimi i thirrjeve API për të ndërvepruar me entitetet e mjeteve ose aplikimi i utilitarit të linjës së komandës gcloud për të kryer manipulimet e nevojshme. Por, me të vërtetë në një numër të madh entitetesh të ndryshme dhe elementëve të infrastrukturës, bëhet e vështirë ose madje e pamundur të kryhen të gjitha operacionet manualisht. Për më tepër, të gjitha këto veprime manuale janë të pakontrolluara. Ne nuk mund t'i dërgojmë ato për rishikim para se t'i ekzekutojmë, të përdorim një sistem kontrolli versioni dhe të rikthejmë shpejt ndryshimet që shkaktuan incidentin. Për të zgjidhur këto probleme, inxhinierët kanë krijuar dhe 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, kuptuar, mbajtur dhe modifikuar në stilin proceduror.
Në këtë artikull dhe udhëzues praktik, unë po përdor 2 mjete që i përkasin praktikës IaC. Këto janë Terraform dhe Ansible. Disa mendojnë se nuk ka kuptim t'i përdorësh ato njëkohësisht, pasi funksionalitetet e tyre janë shumë të ngjashme dhe ato ndërrueshëm. Por e vërteta është se fillimisht ato kanë detyra tërësisht të ndryshme. Dhe fakti që këto mjete duhet të plotësojnë njëra-tjetrën u konfirmua në një prezantim të përbashkët nga zhvilluesit që përfaqësonin kompanitë HashiCorp dhe RedHat. Diferenca konceptuale qëndron në atë se Terraform është një mjet provisioning për menaxhimin e serverëve të vetë. Ndërsa Ansible është një mjet për menaxhimin e konfiguracioneve, detyra e të cilit është instalimi, konfigurimi dhe menaxhimi i softuerit në këta servera.
NjĂ« veçori tjetĂ«r kryesore dalluese e kĂ«tyre mjeteve Ă«shtĂ« stili i shkrimit tĂ« kodit. Ndryshe nga bash dhe Ansible, Terraform pĂ«rdor njĂ« stil deklarativ, tĂ« bazuar nĂ« pĂ«rshkrimin e gjendjes pĂ«rfundimtare tĂ« dĂ«shiruar qĂ« duhet arritur si rezultat i ekzekutimit. PĂ«r shembull, nĂ«se kemi ndĂ«rmend tĂ« krijojmĂ« 10 VM dhe tĂ« aplikojmĂ« ndryshimet pĂ«rmes Terraform, do tĂ« marrim 10 VM. NĂ«se ekzekutimi bĂ«het pĂ«rsĂ«ri, nuk do tĂ« ndodhi asgjĂ«, pasi tashmĂ« kemi 10 VM, dhe Terraform e di kĂ«tĂ« sepse ruan gjendjen aktuale tĂ« infrastrukturĂ«s nĂ« skedarin e gjendjes. NdĂ«rsa Ansible pĂ«rdor njĂ« qasje procedurale dhe, nĂ«se i kĂ«rkojmĂ« tĂ« krijojĂ« 10 VM, nĂ« ekzekutimin e parĂ« do tĂ« marrim 10 VM, si me Terraform. Por pas ekzekutimit tĂ« dytĂ«, do tĂ« kemi tashmĂ« 20 VM. Kjo Ă«shtĂ« dallimi i rĂ«ndĂ«sishĂ«m. NĂ« stilin procedurial, ne nuk ruajmĂ« gjendjen aktuale dhe thjesht pĂ«rshkruajmĂ« sekuencĂ«n e hapave qĂ« duhet tĂ« kryhen. Sigurisht, mund tĂ« pĂ«rballojmĂ« situata tĂ« ndryshme, tĂ« shtojmĂ« disa kontrollime pĂ«r 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Ă« kontroluar kĂ«tĂ« logjikĂ«. Po ashtu, kjo rrit riskun e kryerjes sĂ« gabimeve.Â
Duke përmbledhur gjithçka më sipër, mund të nxjerrim përfundimin se mjeti më i përshtatshëm për provisioning e serverëve është Terraform dhe nota deklarative. Ndërsa, punën për menaxhimin e konfigurimeve është më mirë ta delegojmë tek Ansible. Pas këtij sqarimi, le të shohim disa shembuj përdorimi 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 gjithĂ« infrastrukturĂ«s sĂ« kompanisĂ«. Kjo do tĂ« thotĂ« se tĂ« gjitha praktikat IaC duhet tĂ« aplikohen nĂ« mĂ«nyrĂ« globale mbi resurset e gjithĂ« organizatĂ«s. Kush Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r kĂ«tĂ« varet nga proceset tuaja. Ekipa DevOps Ă«shtĂ« mĂ« e eksperiencuar nĂ« kĂ«to çështje, ata shohin gjithĂ« pamjen e asaj qĂ« ndodh. MegjithatĂ«, inxhinierĂ«t QA janĂ« mĂ« tepĂ«r tĂ« pĂ«rfshirĂ« nĂ« procesin e ndĂ«rtimit tĂ« automatizimit dhe strukturĂ«s sĂ« pipeline, gjĂ« qĂ« u lejon atyre tĂ« shohin mĂ« mirĂ« tĂ« gjitha ndryshimet e nevojshme dhe mundĂ«sitĂ« pĂ«r pĂ«rmirĂ«sim. Zgjedhja mĂ« e mirĂ« Ă«shtĂ« tĂ« punoni sĂ« bashku, tĂ« shkĂ«mbeni dije dhe ide pĂ«r tĂ« arritur rezultatin e pritur.Â
Do t'i jap disa shembuj të përdorimit të Terraform dhe Ansible në kontekstin e automatizimit të testeve dhe mjeteve që kemi diskutuar deri tani:
1. Të përshkruajmë nëpërmjet Terraform karakteristikat e nevojshme dhe parametrat e VM-ve dhe klasterëve.
2. Të instalojmë me Ansible mjetet e nevojshme për testim: docker, Selenoid, Selenium Grid dhe të ngarkojmë versionet e duhura të shfletuesve/emulatorëve.
3. Të përshkruajmë nëpërmjet Terraform karakteristikat e VM-së ku do të ekzekutohet GitLab Runner.
4. Të instalojmë me Ansible GitLab Runner dhe mjetet përkatëse, të caktrojmë konfigurimet dhe cilësimet.
Ilustrimi i gjendjes aktuale të infrastrukturës
Linke për studim:
Vegla të ngjashme
Të përmbledhim!
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 (duke përfshirë Node.js)
2
Sistemet e kontrollit tĂ« versioneveÂ
Git
- Avantazhe të ngjashme me kodin e zhvillimit
3
Containerizimi
Docker, Selenium grid, Selenoid (Web, Android)
- Ekzekutimi paralel i testeve
- Mjedise të izoluar
- Përditësime të thjeshta dhe fleksibël të versioneve
- NDinimizimi i resurseve të papërdorura
- E lehtë për t'u konfiguruar
4
CI / CD
Gitlab CI
- Testet pjesë e konvejerit
- Feedback i shpejtë
- Dukshmëri për të gjithë kompaninë / ekipin
5
Platforma në cloud
Google Cloud Platform
- Burime sipas kërkesës (paguajmë vetëm kur janë të nevojshme)
- Lehtë për t'u menaxhuar dhe përditësuar
- Dukshmëria dhe kontrolli i të gjitha burimeve
6
Orkestrimi
Kubernetes
Në kontekstin e kontejnerëve me shfletues/emulatorë brenda pods:
- Shkallëzimi / automatik i shkallëzimit
- Rimëkëmbje e vetë-automatuar
- Përditësime dhe rikthime pa ndërprerje
7
Infrastruktura si kod (IaC)
Terraform, Ansible
- Përfitime të ngjashme me infrastrukturën e zhvillimit
- Të gjitha përfitimet e versionimit të kodit
- Lehtë për të bërë ndryshime dhe për të mbajtur
- Plotësisht i automatizuar
Diagramet e hartës mendore: evolucioni i infrastrukturës
hapi1: Lokal
hapi2: VCS
hapi3: KonteinerizimiÂ
hapi4: CI/CDÂ
hapi5: Platformat e Cloud
hapi6: Orkestrimi
hapi7: IaC
ĂfarĂ« ndodh mĂ« tej?
Kështu, kjo ë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ë kishte një dobi praktike dhe të ndihmonte në aplikimin e njohurive të marra në punën reale. Po shtoj përsëri.
Por edhe pas kësaj, mos u ndalni, stërvituni, studiojini lidhjet përkatëse dhe librat, merrni vesh si funksionon tek ju në kompani, gjeni vende që mund të përmirësohen dhe merrni pjesë në këtë. Suksese!
Nga ana ime
Nga titulli duket se kjo ishte vetëm pjesa e parë. Edhe pse doli mjaft e gjatë, këtu ende nuk janë zbuluar tema të rëndësishme. Në pjesën e dytë planifikoj të shqyrtoj infrastrukturën e automatizimit në kontekstin e IOS. Për shkak të kufizimeve të Apple që lidhen me ekzekutimin e simulatorëve të IOS vetëm në sistemet macOS, seti ynë i zgjidhjeve është ngushtuar. Për shembull, ne nuk kemi mundësinë të përdorim Docker për të ekzekutuar simulatorin ose cloud publik për të nisur makina virtuale. Por kjo nuk do të thotë se nuk ka alternativa të tjera. Do të përpiqem t'ju mbaj në dijeni për zgjidhjet më të avancuara dhe mjetet moderne!
Po ashtu, nuk e përmenda temën e rëndësishme lidhur 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 duhet të kemi parasysh.
Dhe përfundimisht. Në të ardhmen, planifikoj të publikoj një kurs video mbi ndërtimin e infrastrukturës së testimit dhe mjetet e njohura. Aktualisht, në internet ka shumë kurse dhe ligjërata për DevOps, por të gjitha materialet janë paraqitur në kontekstin e zhvillimit, jo të automatizimit të testimit. Në këtë çështje, kam nevojë për reagime; nëse një kurs i tillë do të ishte i dobishëm dhe i vlefshëm për komunitetin e testuesve dhe automatizuesve. Faleminderit paraprakisht!
Burimi: habr.com
