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
