ProHoster > Blogs > Administrācija > DevOps rīki nav paredzēti tikai DevOps. Testa automatizācijas infrastruktūras izveides process no nulles

DevOps rīki nav paredzēti tikai DevOps. Testa automatizācijas infrastruktūras izveides process no nulles

1. daļa: tÄ«meklis/Android

PiezÄ«me: Å”is raksts ir oriÄ£inālraksta tulkojums krievu valodā ā€œDevOps rÄ«ki nav paredzēti tikai DevOps. "Ēkas testÄ“Å”anas automatizācijas infrastruktÅ«ras izveide no nulles." Tomēr visas ilustrācijas, saites, citāti un termini tiek saglabāti oriÄ£inālvalodā, lai izvairÄ«tos no nozÄ«mes izkropļojumiem, tulkojot krievu valodā. Es novēlu jums laimÄ«gu mācÄ«bas!

DevOps rīki nav paredzēti tikai DevOps. Testa automatizācijas infrastruktūras izveides process no nulles

Å obrÄ«d DevOps specialitāte ir viena no pieprasÄ«tākajām IT nozarē. Atverot populāras darba meklÄ“Å”anas vietnes un filtrējot pēc algas, redzēsit, ka ar DevOps saistÄ«tie darbi atrodas saraksta augÅ”galā. Tomēr ir svarÄ«gi saprast, ka tas galvenokārt attiecas uz ā€œvecākoā€ amatu, kas nozÄ«mē, ka kandidātam ir augsts prasmju lÄ«menis, zināŔanas par tehnoloÄ£ijām un instrumentiem. Tas ir saistÄ«ts arÄ« ar augstu atbildÄ«bas pakāpi, kas saistÄ«ta ar nepārtrauktu ražoÅ”anas darbÄ«bu. Tomēr mēs sākām aizmirst, kas ir DevOps. Sākotnēji tā nebija kāda konkrēta persona vai nodaļa. Ja mēs meklējam Ŕī termina definÄ«cijas, mēs atradÄ«sim daudz skaistu un pareizu lietvārdu, piemēram, metodoloÄ£iju, prakses, kultÅ«ras filozofiju, jēdzienu grupu utt.

Mana specializācija ir testÄ“Å”anas automatizācijas inženieris (QA automation engineer), taču uzskatu, ka to nevajadzētu saistÄ«t tikai ar automātisko testu rakstÄ«Å”anu vai testa ietvara arhitektÅ«ras izstrādi. 2020. gadā bÅ«tiskas ir arÄ« zināŔanas par automatizācijas infrastruktÅ«ru. Tas ļauj jums paÅ”am organizēt automatizācijas procesu, sākot no testu veikÅ”anas lÄ«dz rezultātu nodroÅ”ināŔanai visām ieinteresētajām pusēm atbilstoÅ”i jÅ«su mērÄ·iem. Rezultātā DevOps prasmes ir obligātas, lai paveiktu darbu. Un tas viss ir labi, bet diemžēl ir problēma (spoileris: Å”is raksts mēģina vienkārÅ”ot Å”o problēmu). Lieta ir tāda, ka DevOps ir grÅ«ts. Un tas ir acÄ«mredzami, jo uzņēmumi nemaksās daudz par kaut ko, kas ir viegli izdarāms... DevOps pasaulē ir ļoti daudz rÄ«ku, terminu un prakses, kas jāapgÅ«st. Tas ir Ä«paÅ”i grÅ«ti karjeras sākumā un ir atkarÄ«gs no uzkrātās tehniskās pieredzes.

DevOps rīki nav paredzēti tikai DevOps. Testa automatizācijas infrastruktūras izveides process no nulles
Avots: http://maximelanciauxbi.blogspot.com/2017/04/devops-tools.html

Å eit mēs, iespējams, pabeigsim ar ievaddaļu un koncentrēsimies uz Ŕī raksta mērÄ·i. 

Par ko ir Ŕis raksts?

Å ajā rakstā es dalÄ«Å”os pieredzē par testÄ“Å”anas automatizācijas infrastruktÅ«ras izveidi. Internetā ir daudz informācijas avotu par dažādiem rÄ«kiem un to lietoÅ”anu, bet es gribētu tos aplÅ«kot tÄ«ri automatizācijas kontekstā. Es uzskatu, ka daudzi automatizācijas inženieri ir pazÄ«stami ar situāciju, kad neviens, izņemot jÅ«s, neveic izstrādātos testus vai nerÅ«pējas par to uzturÄ“Å”anu. Tā rezultātā testi kļūst novecojuÅ”i, un jums ir jātērē laiks to atjaunināŔanai. Atkal, karjeras sākumā tas var bÅ«t diezgan grÅ«ts uzdevums: gudri izlemt, kuri rÄ«ki palÄ«dzēs novērst konkrēto problēmu, kā tos atlasÄ«t, konfigurēt un uzturēt. Daži testētāji vērÅ”as pēc palÄ«dzÄ«bas pie DevOps (cilvēkiem), un, bÅ«sim godÄ«gi, Ŕī pieeja darbojas. Daudzos gadÄ«jumos Ŕī var bÅ«t vienÄ«gā iespēja, jo mums nav redzamas visas atkarÄ«bas. Bet, kā zināms, DevOps ir ļoti aizņemti puiÅ”i, jo viņiem ir jādomā par visu uzņēmuma infrastruktÅ«ru, izvietoÅ”anu, uzraudzÄ«bu, mikropakalpojumiem un citiem lÄ«dzÄ«giem uzdevumiem atkarÄ«bā no organizācijas/komandas. Kā parasti, automatizācija nav prioritāte. Šādā gadÄ«jumā mums ir jācenÅ”as darÄ«t visu iespējamo no mÅ«su puses no sākuma lÄ«dz beigām. Tas samazinās atkarÄ«bas, paātrinās darbplÅ«smu, uzlabos mÅ«su prasmes un ļaus mums redzēt plaŔāku priekÅ”statu par notiekoÅ”o.

Rakstā ir parādÄ«ti populārākie un populārākie rÄ«ki un parādÄ«ts, kā tos izmantot, lai soli pa solim izveidotu automatizācijas infrastruktÅ«ru. Katra grupa ir pārstāvēta ar instrumentiem, kas ir pārbaudÄ«ti personÄ«gajā pieredzē. Bet tas nenozÄ«mē, ka jums ir jāizmanto viena un tā pati lieta. PaÅ”i instrumenti nav svarÄ«gi, tie parādās un noveco. MÅ«su inženieru uzdevums ir izprast pamatprincipus: kāpēc mums ir vajadzÄ«ga Ŕī instrumentu grupa un kādas darba problēmas mēs varam atrisināt ar to palÄ«dzÄ«bu. Tāpēc katras sadaļas beigās es atstāju saites uz lÄ«dzÄ«giem rÄ«kiem, kas var tikt izmantoti jÅ«su organizācijā.

Kas nav Ŕajā rakstā

Vēlreiz atkārtoju, ka raksts nav par konkrētiem rÄ«kiem, tāpēc nebÅ«s koda ievietoÅ”anas no dokumentācijas un konkrētu komandu aprakstiem. Bet katras sadaļas beigās es atstāju saites detalizētai izpētei.

Tas tiek darÄ«ts, jo: 

  • Å”is materiāls ir ļoti viegli atrodams dažādos avotos (dokumentācijā, grāmatās, video kursos);
  • ja sāksim iedziļināties, mums bÅ«s jāraksta 10, 20, 30 Ŕī raksta daļas (kamēr plāni ir 2-3);
  • Es vienkārÅ”i nevēlos tērēt jÅ«su laiku, jo jÅ«s varētu vēlēties izmantot citus rÄ«kus, lai sasniegtu tos paÅ”us mērÄ·us.

Prakse

Ä»oti gribētos, lai Å”is materiāls bÅ«tu noderÄ«gs ikvienam lasÄ«tājam, nevis vienkārÅ”i izlasÄ«tu un aizmirstu. Jebkurā pētÄ«jumā prakse ir ļoti svarÄ«ga sastāvdaļa. Tam esmu sagatavojies GitHub repozitorijs ar soli pa solim sniegtiem norādÄ«jumiem par to, kā visu izdarÄ«t no nulles. JÅ«s gaida arÄ« mājasdarbi, lai pārliecinātos, ka bez prāta nekopējat izpildāmo komandu rindas.

Plāns

Solis
Tehnoloģija
darbarīki

1
Vietējā darbÄ«ba (sagatavojiet tÄ«mekļa / Android demonstrācijas testus un palaidiet to lokāli) 
Node.js, Selēns, Appium

2
Versiju kontroles sistēmas 
Git

3
Konteinerizācija
Docker, Selēna režģis, Selenoid (tīmeklis, Android)

4
CI/CD
Gitlab CI

5
Mākoņu platformas
Google mākoņa platforma

6
Orķestrācija
Kubernetes

7
Infrastruktūra kā kods (IaC)
Terraforma, Ansible

Katras sadaļas struktūra

Lai stāstÄ«jums bÅ«tu skaidrs, katra sadaļa ir aprakstÄ«ta saskaņā ar Ŕādu izklāstu:

  • Ä«ss tehnoloÄ£ijas apraksts,
  • vērtÄ«ba automatizācijas infrastruktÅ«rai,
  • infrastruktÅ«ras paÅ”reizējā stāvokļa ilustrācija,
  • saites uz studijām,
  • lÄ«dzÄ«gi instrumenti.

1. Palaidiet testus lokāli

ÄŖss tehnoloÄ£ijas apraksts

Å is ir tikai sagatavoÅ”anās solis, lai veiktu demonstrācijas testus lokāli un pārbaudÄ«tu, vai tie ir izturēti. Praktiskajā daļā tiek izmantots Node.js, taču arÄ« programmÄ“Å”anas valodai un platformai nav nozÄ«mes un var izmantot tās, kuras tiek lietotas JÅ«su uzņēmumā. 

Tomēr kā automatizācijas rÄ«kus es iesaku izmantot attiecÄ«gi Selenium WebDriver tÄ«mekļa platformām un Appium Android platformai, jo turpmākajās darbÄ«bās mēs izmantosim Docker attēlus, kas ir pielāgoti darbam ar Å”iem rÄ«kiem. Turklāt, ņemot vērā darba prasÄ«bas, Å”ie rÄ«ki ir vispieprasÄ«tākie tirgÅ«.

Kā jūs, iespējams, pamanījāt, mēs ņemam vērā tikai tīmekļa un Android testus. Diemžēl iOS ir pavisam cits stāsts (paldies Apple). Es plānoju parādīt ar IOS saistītus risinājumus un praksi nākamajās daļās.

Vērtība automatizācijas infrastruktūrai

No infrastruktÅ«ras viedokļa lokāla darbÄ«ba nesniedz nekādu vērtÄ«bu. JÅ«s tikai pārbaudiet, vai testi tiek veikti vietējā datorā vietējās pārlÅ«kprogrammās un simulatoros. Bet jebkurā gadÄ«jumā tas ir nepiecieÅ”ams sākumpunkts.

PaÅ”reizējā infrastruktÅ«ras stāvokļa ilustrācija

DevOps rīki nav paredzēti tikai DevOps. Testa automatizācijas infrastruktūras izveides process no nulles

Saites izpētei

Līdzīgi rīki

  • jebkura programmÄ“Å”anas valoda, kas jums patÄ«k kopā ar Selenium/Appium testiem;
  • jebkuri testi;
  • jebkurÅ” testa skrējējs.

2. Versiju kontroles sistēmas (Git)

ÄŖss tehnoloÄ£ijas apraksts

Nevienam nebÅ«s liela atklāsme, ja teikÅ”u, ka versiju kontrole ir ārkārtÄ«gi svarÄ«ga attÄ«stÄ«bas sastāvdaļa gan komandā, gan individuāli. Pamatojoties uz dažādiem avotiem, var droÅ”i teikt, ka Git ir vispopulārākais pārstāvis. Versiju kontroles sistēma nodroÅ”ina daudzas priekÅ”rocÄ«bas, piemēram, koda koplietoÅ”anu, versiju glabāŔanu, iepriekŔējo atzaru atjaunoÅ”anu, projektu vēstures uzraudzÄ«bu un dublējumkopijas. Mēs neapspriedÄ«sim katru punktu sÄ«kāk, jo esmu pārliecināts, ka jÅ«s to labi pārzināt un izmantojat savā ikdienas darbā. Bet, ja pēkŔņi nē, tad iesaku pārtraukt Ŕī raksta lasÄ«Å”anu un pēc iespējas ātrāk aizpildÄ«t Å”o robu.

Vērtība automatizācijas infrastruktūrai

Un Å”eit jÅ«s varat uzdot pamatotu jautājumu: ā€œKāpēc viņŔ mums stāsta par Gitu? Ikviens to zina un izmanto gan izstrādes kodam, gan automātiskās pārbaudes kodam. Jums bÅ«s pilnÄ«ga taisnÄ«ba, taču Å”ajā rakstā mēs runājam par infrastruktÅ«ru, un Ŕī sadaļa darbojas kā priekÅ”skatÄ«jums 7. sadaļai: ā€œInfrastruktÅ«ra kā kods (IaC)ā€. Mums tas nozÄ«mē, ka visa infrastruktÅ«ra, ieskaitot testÄ“Å”anu, ir aprakstÄ«ta koda veidā, tāpēc varam tai pielietot arÄ« versiju veidoÅ”anas sistēmas un iegÅ«t lÄ«dzÄ«gas priekÅ”rocÄ«bas kā izstrādei un automatizācijas kodam.

Mēs sÄ«kāk aplÅ«kosim IaC 7. darbÄ«bā, taču pat tagad varat sākt lietot Git lokāli, izveidojot lokālo repozitoriju. Kopējais attēls tiks paplaÅ”ināts, kad infrastruktÅ«rai pievienosim attālo repozitoriju.

PaÅ”reizējā infrastruktÅ«ras stāvokļa ilustrācija

DevOps rīki nav paredzēti tikai DevOps. Testa automatizācijas infrastruktūras izveides process no nulles

Saites izpētei

Līdzīgi rīki

3. Konteiners (Docker)

ÄŖss tehnoloÄ£ijas apraksts

Lai parādÄ«tu, kā konteinerizācija ir mainÄ«jusi spēles noteikumus, atgriezÄ«simies laikā dažas desmitgades. Toreiz cilvēki iegādājās un izmantoja serveru iekārtas, lai palaistu lietojumprogrammas. Bet vairumā gadÄ«jumu nepiecieÅ”amie starta resursi nebija iepriekÅ” zināmi. Rezultātā uzņēmumi tērēja naudu dārgu, jaudÄ«gu serveru iegādei, taču daļa no Ŕīs jaudas netika pilnÄ«bā izmantota.

Nākamais evolÅ«cijas posms bija virtuālās maŔīnas (VM), kas atrisināja problēmu, kas saistÄ«ta ar naudas izŔķērdÄ“Å”anu uz neizmantotiem resursiem. Å Ä« tehnoloÄ£ija ļāva vienā serverÄ« darbināt lietojumprogrammas neatkarÄ«gi vienu no otras, pieŔķirot pilnÄ«bā izolētu vietu. Bet diemžēl jebkurai tehnoloÄ£ijai ir savi trÅ«kumi. Lai darbinātu virtuālo maŔīnu, ir nepiecieÅ”ama pilna operētājsistēma, kas patērē centrālo procesoru, operatÄ«vo atmiņu, krātuvi un, atkarÄ«bā no OS, jārēķinās ar licences izmaksām. Å ie faktori ietekmē iekrauÅ”anas ātrumu un apgrÅ«tina pārnesamÄ«bu.

Un tagad mēs nonākam pie konteinerizācijas. Kārtējo reizi Ŕī tehnoloÄ£ija atrisina iepriekŔējo problēmu, jo konteineros netiek izmantota pilna OS, kas atbrÄ«vo lielu daudzumu resursu un nodroÅ”ina ātru un elastÄ«gu risinājumu pārnēsāŔanai.

Protams, konteineru tehnoloÄ£ija nav nekas jauns un pirmo reizi tika ieviests 70. gadu beigās. Tajos laikos tika veikti daudzi pētÄ«jumi, izstrādes un mēģinājumi. Bet tieÅ”i Docker pielāgoja Å”o tehnoloÄ£iju un padarÄ«ja to viegli pieejamu masām. MÅ«sdienās, kad mēs runājam par konteineriem, vairumā gadÄ«jumu mēs domājam Docker. Kad mēs runājam par Docker konteineriem, mēs domājam Linux konteinerus. Mēs varam izmantot Windows un macOS sistēmas, lai palaistu konteinerus, taču ir svarÄ«gi saprast, ka Å”ajā gadÄ«jumā parādās papildu slānis. Piemēram, Docker operētājsistēmā Mac klusi palaiž konteinerus vieglā Linux virtuālajā maŔīnā. Mēs atgriezÄ«simies pie Ŕīs tēmas, kad apspriedÄ«sim Android emulatoru darbÄ«bu konteineros, tāpēc Å”eit ir ļoti svarÄ«ga nianse, kas jāapspriež sÄ«kāk.

Vērtība automatizācijas infrastruktūrai

Mēs noskaidrojām, ka konteinerizācija un Docker ir forÅ”i. ApskatÄ«sim to automatizācijas kontekstā, jo katram instrumentam vai tehnoloÄ£ijai ir jāatrisina problēma. Ieskicēsim acÄ«mredzamās pārbaudes automatizācijas problēmas UI testu kontekstā:

  • milzÄ«gs skaits atkarÄ«bu, instalējot Selēnu un jo Ä«paÅ”i Appium;
  • saderÄ«bas problēmas starp pārlÅ«kprogrammu, simulatoru un draiveru versijām;
  • izolētas vietas trÅ«kums pārlÅ«kprogrammām/simulatoriem, kas ir Ä«paÅ”i svarÄ«gi paralēlai darbÄ«bai;
  • grÅ«ti pārvaldÄ«t un uzturēt, ja jums vienlaikus jāpalaiž 10, 50, 100 vai pat 1000 pārlÅ«kprogrammas.

Bet, tā kā Selēns ir vispopulārākais automatizācijas rÄ«ks un Docker ir vispopulārākais konteinerizācijas rÄ«ks, nav jābrÄ«nās, ka kāds ir mēģinājis tos apvienot, lai izveidotu jaudÄ«gu rÄ«ku iepriekÅ” minēto problēmu risināŔanai. Apsvērsim Ŕādus risinājumus sÄ«kāk. 

Selēna režģis dokā

Å is rÄ«ks ir vispopulārākais Selēna pasaulē, lai palaistu vairākas pārlÅ«kprogrammas vairākās iekārtās un pārvaldÄ«tu tās no centrālā centrmezgla. Lai sāktu, jums jāreÄ£istrē vismaz 2 daļas: centrmezgls un mezgls(-i). Hub ir centrālais mezgls, kas saņem visus pieprasÄ«jumus no testiem un izplata tos attiecÄ«gajiem mezgliem. Katram Node varam konfigurēt konkrētu konfigurāciju, piemēram, norādot vajadzÄ«go pārlÅ«kprogrammu un tās versiju. Tomēr mums joprojām ir paÅ”iem jāparÅ«pējas par saderÄ«giem pārlÅ«kprogrammas draiveriem un jāinstalē tie vajadzÄ«gajos Nodes. Å Ä« iemesla dēļ Selēna režģis netiek izmantots tÄ«rā veidā, izņemot gadÄ«jumus, kad mums ir jāstrādā ar pārlÅ«kprogrammām, kuras nevar instalēt operētājsistēmā Linux. Visos citos gadÄ«jumos ļoti elastÄ«gs un pareizs risinājums bÅ«tu izmantot Docker attēlus, lai palaistu Selenium grid Hub un Nodes. Å Ä« pieeja ievērojami vienkārÅ”o mezglu pārvaldÄ«bu, jo mēs varam atlasÄ«t vajadzÄ«go attēlu ar jau instalētām saderÄ«gām pārlÅ«kprogrammu versijām un draiveriem.

Neskatoties uz negatÄ«vām atsauksmēm par stabilitāti, it Ä«paÅ”i, ja paralēli darbojas liels skaits mezglu, Selēna režģis joprojām ir vispopulārākais rÄ«ks Selēna testu veikÅ”anai paralēli. Ir svarÄ«gi atzÄ«mēt, ka atvērtajā pirmkoda versijā pastāvÄ«gi parādās dažādi Ŕī rÄ«ka uzlabojumi un modifikācijas, kas cÄ«nās ar dažādām vājajām vietām.

Selenoīds tīmeklim

Å is rÄ«ks ir izrāviens selēna pasaulē, jo tas darbojas uzreiz no kastes un ir ievērojami atvieglojis daudzu automatizācijas inženieru dzÄ«vi. Pirmkārt, Ŕī nav vēl viena Selēna režģa modifikācija. Tā vietā izstrādātāji Golangā izveidoja pilnÄ«gi jaunu Selenium Hub versiju, kas kopā ar viegliem Docker attēliem dažādām pārlÅ«kprogrammām deva impulsu testÄ“Å”anas automatizācijas attÄ«stÄ«bai. Turklāt Selenium Grid gadÄ«jumā mums ir iepriekÅ” jānosaka visas nepiecieÅ”amās pārlÅ«kprogrammas un to versijas, kas nav problēma, strādājot tikai ar vienu pārlÅ«kprogrammu. Bet, ja runa ir par vairākām atbalstÄ«tām pārlÅ«kprogrammām, Selenoid ir risinājums numur viens, pateicoties tā funkcijai ā€œpārlÅ«ks pēc pieprasÄ«jumaā€. Viss, kas no mums tiek prasÄ«ts, ir iepriekÅ” ar pārlÅ«kprogrammām lejupielādēt nepiecieÅ”amos attēlus un atjaunināt konfigurācijas failu, ar kuru mijiedarbojas Selenoid. Kad Selenoid saņems pieprasÄ«jumu no testiem, tas automātiski palaidÄ«s vajadzÄ«go konteineru ar vēlamo pārlÅ«kprogrammu. Kad pārbaude bÅ«s pabeigta, Selenoid izņems konteineru, tādējādi atbrÄ«vojot resursus turpmākiem pieprasÄ«jumiem. Å Ä« pieeja pilnÄ«bā novērÅ” labi zināmo ā€œmezglu degradācijasā€ problēmu, ar kuru mēs bieži sastopamies selēna režģī.

Bet, diemžēl, selenoÄ«ds joprojām nav sudraba lode. Mēs saņēmām funkciju ā€œPārlÅ«kprogramma pēc pieprasÄ«jumaā€, taču funkcija ā€œResursi pēc pieprasÄ«jumaā€ joprojām nav pieejama. Lai izmantotu Selenoid, mums tas ir jāizvieto fiziskajā aparatÅ«rā vai virtuālajā maŔīnā, kas nozÄ«mē, ka mums iepriekÅ” ir jāzina, cik daudz resursu ir jāpieŔķir. Es domāju, ka tā nav problēma maziem projektiem, kuros paralēli darbojas 10, 20 vai pat 30 pārlÅ«kprogrammas. Bet ko tad, ja mums vajag 100, 500, 1000 vai vairāk? Nav jēgas visu laiku uzturēt un maksāt tik daudz resursu. Å Ä« raksta 5. un 6. sadaļā mēs apspriedÄ«sim risinājumus, kas ļauj palielināt mērogu, tādējādi ievērojami samazinot uzņēmuma izmaksas.

Selenoīds operētājsistēmai Android

Pēc Selenoid kā tÄ«mekļa automatizācijas rÄ«ka panākumiem cilvēki vēlējās kaut ko lÄ«dzÄ«gu Android ierÄ«cēm. Un tas notika - Selenoid tika izlaists ar Android atbalstu. No augsta lÄ«meņa lietotāju viedokļa darbÄ«bas princips ir lÄ«dzÄ«gs tÄ«mekļa automatizācijai. VienÄ«gā atŔķirÄ«ba ir tā, ka pārlÅ«kprogrammas konteineru vietā Selenoid darbojas Android emulatora konteineri. Manuprāt, Å”obrÄ«d Å”is ir jaudÄ«gākais bezmaksas rÄ«ks Android testu paralēlai palaiÅ”anai.

Es tieŔām negribētu runāt par Ŕī rÄ«ka negatÄ«vajiem aspektiem, jo ā€‹ā€‹man tas ļoti patÄ«k. Tomēr joprojām ir tie paÅ”i trÅ«kumi, kas attiecas uz tÄ«mekļa automatizāciju un ir saistÄ«ti ar mērogoÅ”anu. Papildus tam mums ir jārunā par vēl vienu ierobežojumu, kas var bÅ«t pārsteigums, ja mēs iestatām rÄ«ku pirmo reizi. Lai palaistu Android attēlus, mums ir nepiecieÅ”ama fiziska maŔīna vai virtuālā maŔīna ar ligzdotas virtualizācijas atbalstu. PamācÄ«bā es parādÄ«Å”u, kā to iespējot Linux virtuālajā maŔīnā. Tomēr, ja esat MacOS lietotājs un vēlaties lokāli izvietot Selenoid, Android testus nevarēs palaist. Taču jÅ«s vienmēr varat lokāli palaist Linux virtuālo maŔīnu ar konfigurētu ā€œligzdoto virtualizācijuā€ un iekŔā izvietot Selenoid.

PaÅ”reizējā infrastruktÅ«ras stāvokļa ilustrācija

Å Ä« raksta kontekstā mēs pievienosim 2 rÄ«kus, lai ilustrētu infrastruktÅ«ru. Tie ir Selenium režģis tÄ«mekļa testiem un Selenoid Android testiem. GitHub apmācÄ«bā es arÄ« parādÄ«Å”u, kā izmantot Selenoid tÄ«mekļa testu veikÅ”anai. 

DevOps rīki nav paredzēti tikai DevOps. Testa automatizācijas infrastruktūras izveides process no nulles

Saites izpētei

Līdzīgi rīki

  • Ir arÄ« citi konteinerizācijas rÄ«ki, bet Docker ir vispopulārākais. Ja vēlaties izmēģināt kaut ko citu, ņemiet vērā, ka rÄ«ki, kurus esam nodroÅ”inājuÅ”i paralēlai Selēna testu veikÅ”anai, nedarbosies.  
  • Kā jau minēts, Selēna režģī ir daudz modifikāciju, piemēram, Zalēnijs.

4.CI/CD

ÄŖss tehnoloÄ£ijas apraksts

Nepārtrauktas integrācijas prakse ir diezgan populāra attÄ«stÄ«bā un ir lÄ«dzvērtÄ«ga versiju kontroles sistēmām. Neskatoties uz to, man Ŕķiet, ka terminoloÄ£ijā valda neskaidrÄ«bas. Å ajā rindkopā es vēlos aprakstÄ«t 3 Ŕīs tehnoloÄ£ijas modifikācijas no mana viedokļa. Internetā jÅ«s atradÄ«siet daudz rakstu ar dažādām interpretācijām, un tas ir pilnÄ«gi normāli, ja jÅ«su viedoklis atŔķiras. VissvarÄ«gākais ir tas, ka esat uz viena viļņa ar saviem kolēģiem.

Tātad ir 3 termini: CI ā€” nepārtraukta integrācija, CD ā€” nepārtraukta piegāde un atkal CD ā€” nepārtraukta izvietoÅ”ana. (Tālāk es izmantoÅ”u Å”os terminus angļu valodā). Katra modifikācija jÅ«su izstrādes konveijeram pievieno vairākas papildu darbÄ«bas. Bet vārds nepārtraukts (nepārtraukts) ir vissvarÄ«gākā lieta. Å ajā kontekstā mēs domājam kaut ko, kas notiek no sākuma lÄ«dz beigām, bez pārtraukuma vai manuālas iejaukÅ”anās. ApskatÄ«sim CI & CD un CD Å”ajā kontekstā.

  • Nepārtraukta integrācija tas ir pirmais evolÅ«cijas solis. Pēc jauna koda iesniegÅ”anas serverÄ« mēs ceram saņemt ātru atgriezenisko saiti, ka mÅ«su izmaiņas ir pareizas. Parasti CI ietver statisku koda analÄ«zes rÄ«ku darbÄ«bu un vienÄ«bas/iekŔējo API testus. Tas ļauj mums iegÅ«t informāciju par mÅ«su kodu dažu sekunžu/minÅ«Å”u laikā.
  • Nepārtraukta Piegāde ir uzlabots solis, kurā mēs veicam integrācijas/UI testus. Tomēr Å”ajā posmā mēs nesaņemam rezultātus tik ātri kā ar CI. Pirmkārt, Ŕāda veida testu pabeigÅ”ana prasa ilgāku laiku. Otrkārt, pirms palaiÅ”anas mums ir jāizvieto izmaiņas testa/iestudÄ“Å”anas vidē. Turklāt, ja mēs runājam par mobilo izstrādi, parādās papildu solis, lai izveidotu mÅ«su lietojumprogrammas bÅ«vējumu.
  • Nepārtraukta izvietoÅ”ana pieņem, ka mēs automātiski izlaižam izmaiņas ražoÅ”anā, ja iepriekŔējās stadijās ir nokārtotas visas pieņemÅ”anas pārbaudes. Papildus tam pēc izlaiÅ”anas stadijas varat konfigurēt dažādus posmus, piemēram, veikt dÅ«mu testus ražoÅ”anā un apkopot interesējoÅ”os rādÄ«tājus. Nepārtraukta izvietoÅ”ana ir iespējama tikai ar labu automātisko testu pārklājumu. Ja ir nepiecieÅ”ama manuāla iejaukÅ”anās, tostarp testÄ“Å”ana, tad tā vairs nav Nepārtraukts (nepārtraukti). Tad mēs varam teikt, ka mÅ«su cauruļvads atbilst tikai nepārtrauktās piegādes praksei.

Vērtība automatizācijas infrastruktūrai

Å ajā sadaļā man jāpaskaidro, ka, runājot par pilnÄ«gu lietotāja saskarnes testiem, tas nozÄ«mē, ka mums ir jāizvieto savas izmaiņas un saistÄ«tie pakalpojumi, lai testētu vidi. Nepārtraukta integrācija - process nav piemērojams Å”im uzdevumam, un mums ir jārÅ«pējas par vismaz nepārtrauktas piegādes prakses ievieÅ”anu. Nepārtrauktai izvietoÅ”anai ir jēga arÄ« UI testu kontekstā, ja mēs gatavojamies tos palaist ražoÅ”anā.

Un pirms mēs aplÅ«kojam arhitektÅ«ras izmaiņu ilustrāciju, es vēlos teikt dažus vārdus par GitLab CI. AtŔķirÄ«bā no citiem CI/CD rÄ«kiem, GitLab nodroÅ”ina attālo repozitoriju un daudzas citas papildu funkcijas. Tādējādi GitLab ir vairāk nekā CI. Tas ietver pirmkoda pārvaldÄ«bu, Agile pārvaldÄ«bu, CI/CD konveijerus, reÄ£istrÄ“Å”anas rÄ«kus un metrikas vākÅ”anu. GitLab arhitektÅ«ra sastāv no Gitlab CI/CD un GitLab Runner. Å eit ir Ä«ss apraksts no oficiālās vietnes:

Gitlab CI/CD ir tÄ«mekļa lietojumprogramma ar API, kas saglabā savu stāvokli datu bāzē, pārvalda projektus/bÅ«vējumus un nodroÅ”ina lietotāja saskarni. GitLab Runner ir lietojumprogramma, kas apstrādā bÅ«vējumus. To var izvietot atseviŔķi, un tas darbojas ar GitLab CI/CD, izmantojot API. Lai veiktu testus, jums ir nepiecieÅ”ams gan Gitlab gadÄ«jums, gan Runner.

PaÅ”reizējā infrastruktÅ«ras stāvokļa ilustrācija

DevOps rīki nav paredzēti tikai DevOps. Testa automatizācijas infrastruktūras izveides process no nulles

Saites izpētei

Līdzīgi rīki

5. Mākoņu platformas

ÄŖss tehnoloÄ£ijas apraksts

Å ajā sadaļā mēs runāsim par populāru tendenci, ko sauc par ā€œpubliskajiem mākoņiemā€. Neskatoties uz milzÄ«gajām priekÅ”rocÄ«bām, ko sniedz iepriekÅ” aprakstÄ«tās virtualizācijas un konteinerizācijas tehnoloÄ£ijas, mums joprojām ir nepiecieÅ”ami skaitļoÅ”anas resursi. Uzņēmumi iegādājas dārgus serverus vai Ä«rē datu centrus, taču Å”ajā gadÄ«jumā ir jāveic aprēķini (dažkārt nereāli), cik resursu mums bÅ«s nepiecieÅ”ams, vai tos izmantosim 24/7 un kādiem mērÄ·iem. Piemēram, ražoÅ”anai nepiecieÅ”ams serveris, kas darbojas XNUMX/XNUMX, bet vai mums ir nepiecieÅ”ami lÄ«dzÄ«gi resursi testÄ“Å”anai ārpus darba laika? Tas ir atkarÄ«gs arÄ« no veicamās pārbaudes veida. Piemērs varētu bÅ«t slodzes/stresa testi, kurus plānojam veikt ārpus darba laika, lai nākamajā dienā iegÅ«tu rezultātus. Bet noteikti XNUMX/XNUMX servera pieejamÄ«ba nav nepiecieÅ”ama pilnÄ«gai automatizētai pārbaudei un jo Ä«paÅ”i ne manuālās testÄ“Å”anas vidēm. Šādām situācijām bÅ«tu labi pēc pieprasÄ«juma iegÅ«t tik daudz resursu, cik nepiecieÅ”ams, tos izmantot un pārtraukt maksāt, kad tie vairs nav vajadzÄ«gi. Turklāt bÅ«tu lieliski tos saņemt uzreiz, veicot dažus peles klikŔķus vai palaižot pāris skriptus. Å im nolÅ«kam tiek izmantoti publiskie mākoņi. ApskatÄ«sim definÄ«ciju:

ā€œPubliskais mākonis ir definēts kā skaitļoÅ”anas pakalpojumi, ko publiskajā internetā piedāvā treÅ”o puÅ”u pakalpojumu sniedzēji, padarot tos pieejamus ikvienam, kas vēlas tos izmantot vai iegādāties. Tie var bÅ«t bezmaksas vai pārdoti pēc pieprasÄ«juma, ļaujot klientiem maksāt tikai par lietojumu par CPU cikliem, krātuvi vai joslas platumu, ko viņi patērē."

Pastāv viedoklis, ka publiskie mākoņi ir dārgi. Taču viņu galvenā ideja ir samazināt uzņēmuma izmaksas. Kā minēts iepriekÅ”, publiskie mākoņi ļauj iegÅ«t resursus pēc pieprasÄ«juma un maksāt tikai par to lietoÅ”anas laiku. Tāpat dažkārt aizmirstam, ka darbinieki saņem algas, un arÄ« speciālisti ir dārgs resurss. Jāņem vērā, ka publiskie mākoņi ievērojami atvieglo infrastruktÅ«ras atbalstu, kas ļauj inženieriem koncentrēties uz svarÄ«gākiem uzdevumiem. 

Vērtība automatizācijas infrastruktūrai

Kādi konkrēti resursi mums ir nepiecieÅ”ami pilnÄ«gai lietotāja saskarnes testiem? BÅ«tÄ«bā tās ir virtuālās maŔīnas vai kopas (par Kubernetes mēs runāsim nākamajā sadaļā) pārlÅ«kprogrammu un emulatoru darbināŔanai. Jo vairāk pārlÅ«kprogrammu un emulatoru mēs vēlamies darbināt vienlaikus, jo vairāk nepiecieÅ”ams CPU un atmiņa, un jo vairāk naudas mums par to ir jāmaksā. Tādējādi publiskie mākoņi testu automatizācijas kontekstā ļauj mums pēc pieprasÄ«juma darbināt lielu skaitu (100, 200, 1000...) pārlÅ«kprogrammu/emulatoru, pēc iespējas ātrāk iegÅ«t testa rezultātus un pārstāt maksāt par tik neprātÄ«gi resursietilpÄ«gu. jauda. 

Populārākie mākoņa pakalpojumu sniedzēji ir Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). PamācÄ«bā ir sniegti piemēri, kā lietot GCP, taču kopumā nav nozÄ«mes tam, ko izmantojat automatizācijas uzdevumiem. Tie visi nodroÅ”ina aptuveni vienādu funkcionalitāti. Parasti, lai izvēlētos pakalpojumu sniedzēju, vadÄ«ba koncentrējas uz uzņēmuma vispārējo infrastruktÅ«ru un biznesa prasÄ«bām, kas ir ārpus Ŕī raksta darbÄ«bas jomas. Automatizācijas inženieriem interesantāk bÅ«s salÄ«dzināt mākoņpakalpojumu sniedzēju izmantoÅ”anu ar mākoņu platformu izmantoÅ”anu tieÅ”i testÄ“Å”anas nolÅ«kos, piemēram, Sauce Labs, BrowserStack, BitBar u.c. Tāpēc darÄ«sim to arÄ« mēs! Manuprāt, Sauce Labs ir slavenākā mākoņu testÄ“Å”anas ferma, tāpēc izmantoju to salÄ«dzināŔanai. 

GCP vs Sauce Labs automatizācijas nolūkos:

Iedomāsimies, ka mums vienlaikus jāpalaiž 8 tÄ«mekļa testi un 8 Android testi. Å im nolÅ«kam mēs izmantosim GCP un palaidÄ«sim 2 virtuālās maŔīnas ar Selenoid. Pirmajā mēs pacelsim 8 konteinerus ar pārlÅ«kprogrammām. Otrajā ir 8 konteineri ar emulatoriem. ApskatÄ«sim cenas:  

DevOps rīki nav paredzēti tikai DevOps. Testa automatizācijas infrastruktūras izveides process no nulles
Lai palaistu vienu konteineru ar Chrome, mums ir nepiecieÅ”ams n1-standarta-1 auto. Android gadÄ«jumā tā bÅ«s n1-standarta-4 vienam emulatoram. Faktiski elastÄ«gāks un lētāks veids ir iestatÄ«t konkrētas lietotāja vērtÄ«bas CPU/Memory, taču Å”obrÄ«d tas nav svarÄ«gi, lai salÄ«dzinātu ar Sauce Labs.

Un Ŕeit ir Sauce Labs lietoŔanas tarifi:

DevOps rīki nav paredzēti tikai DevOps. Testa automatizācijas infrastruktūras izveides process no nulles
Es uzskatu, ka jÅ«s jau esat pamanÄ«juÅ”i atŔķirÄ«bu, taču es joprojām sniegÅ”u tabulu ar mÅ«su uzdevuma aprēķiniem:

NepiecieŔamie resursi
Katru mēnesi
Darba stundas(8:8ā€“XNUMX:XNUMX)
Darba stundas+ Paredzams

GCP tīmeklim
n1-standarta-1 x 8 = n1-standarta-8
$194.18
23 dienas * 12 h * 0.38 = 104.88 ASV dolāri 
23 dienas * 12 h * 0.08 = 22.08 ASV dolāri

Sauce Labs for Web
Virtual Cloud8 paralēlie testi
$1.559
Sākot no
Sākot no

GCP operētājsistēmai Android
n1-standarta-4 x 8: n1-standarta-16
$776.72
23 dienas * 12 h * 1.52 = 419.52 ASV dolāri 
23 dienas * 12 h * 0.32 = 88.32 ASV dolāri

Sauce Labs Android ierīcēm
Real Device Cloud 8 paralēlie testi
$1.999
Sākot no
Sākot no

Kā redzat, izmaksu atŔķirÄ«ba ir milzÄ«ga, it Ä«paÅ”i, ja testus veicat tikai divpadsmit stundu darba periodā. Bet jÅ«s varat samazināt izmaksas vēl vairāk, ja izmantojat iepriekŔējas iespējas. Kas tas ir?

PriekÅ”laicÄ«ga virtuālā maŔīna ir gadÄ«jums, ko varat izveidot un palaist par daudz zemāku cenu nekā parastās instances. Tomēr Compute Engine var pārtraukt (iepriekÅ” novērst) Å”os gadÄ«jumus, ja tai ir nepiecieÅ”ama piekļuve Å”iem resursiem citu uzdevumu veikÅ”anai. Paredzamie gadÄ«jumi ir pārmērÄ«ga Compute Engine jauda, ā€‹ā€‹tāpēc to pieejamÄ«ba mainās atkarÄ«bā no lietojuma.

Ja jÅ«su lietotnes ir izturÄ«gas pret kļūmēm un var izturēt iespējamos gadÄ«jumu priekÅ”apmaksas gadÄ«jumus, tad, izmantojot iepriekŔējas darbÄ«bas, var ievērojami samazināt Compute Engine izmaksas. Piemēram, pakeÅ”apstrādes darbi var tikt palaisti priekÅ”laicÄ«gās instancēs. Ja daži no Å”iem gadÄ«jumiem tiek pārtraukti apstrādes laikā, darbs palēninās, bet neapstājas pilnÄ«bā. Preemptible instances pabeidz jÅ«su pakeÅ”u apstrādes uzdevumus, neuzliekot papildu darba slodzi esoÅ”ajiem gadÄ«jumiem un neprasot maksāt pilnu cenu par papildu parastajiem gadÄ«jumiem.

Un tas joprojām nav beidzies! PatiesÄ«bā esmu pārliecināts, ka neviens neveic testus 12 stundas bez pārtraukuma. Un ja tā, tad jÅ«s varat automātiski palaist un apturēt virtuālās maŔīnas, kad tās nav vajadzÄ«gas. Faktiskais lietoÅ”anas laiks var tikt samazināts lÄ«dz 6 stundām dienā. Tad maksājums mÅ«su uzdevuma kontekstā samazināsies lÄ«dz 11 USD mēnesÄ« par 8 pārlÅ«kprogrammām. Vai tas nav brÄ«niŔķīgi? Bet ar iepriekÅ” novērÅ”amām maŔīnām mums jābÅ«t uzmanÄ«giem un gataviem pārtraukumiem un nestabilitātei, lai gan Ŕīs situācijas var nodroÅ”ināt un apstrādāt programmatÅ«rā. Tas ir tā vērts!

Bet es nekādā gadÄ«jumā nesaku "nekad neizmantojiet mākoņa pārbaudes fermas". Viņiem ir vairākas priekÅ”rocÄ«bas. Pirmkārt, Ŕī nav tikai virtuāla maŔīna, bet gan pilnvērtÄ«gs testÄ“Å”anas automatizācijas risinājums ar funkcionalitātes komplektu, kas tiek izņemts no kastes: attālā piekļuve, žurnāli, ekrānuzņēmumi, video ierakstÄ«Å”ana, dažādas pārlÅ«kprogrammas un fiziskas mobilās ierÄ«ces. Daudzās situācijās tā var bÅ«t bÅ«tiska eleganta alternatÄ«va. TestÄ“Å”anas platformas ir Ä«paÅ”i noderÄ«gas IOS automatizācijai, kad publiskie mākoņi var piedāvāt tikai Linux/Windows sistēmas. Bet par iOS mēs runāsim nākamajos rakstos. Iesaku vienmēr skatÄ«ties uz situāciju un sākt no uzdevumiem: dažos gadÄ«jumos lētāk un efektÄ«vāk ir izmantot publiskos mākoņus, savukārt citos testa platformas noteikti ir iztērētās naudas vērtas.

PaÅ”reizējā infrastruktÅ«ras stāvokļa ilustrācija

DevOps rīki nav paredzēti tikai DevOps. Testa automatizācijas infrastruktūras izveides process no nulles

Saites izpētei

Līdzīgi rīki:

6. Orķestrācija

ÄŖss tehnoloÄ£ijas apraksts

Man ir labas ziņas - esam gandrÄ«z raksta beigās! Å obrÄ«d mÅ«su automatizācijas infrastruktÅ«ru veido tÄ«mekļa un Android testi, kurus paralēli veicam caur GitLab CI, izmantojot Docker iespējotus rÄ«kus: Selenium grid un Selenoid. Turklāt mēs izmantojam virtuālās maŔīnas, kas izveidotas, izmantojot GCP, lai mitinātu konteinerus ar pārlÅ«kprogrammām un emulatoriem. Lai samazinātu izmaksas, mēs iedarbinām Ŕīs virtuālās maŔīnas tikai pēc pieprasÄ«juma un pārtraucam tās, kad testÄ“Å”ana netiek veikta. Vai ir vēl kaut kas, kas var uzlabot mÅ«su infrastruktÅ«ru? Atbilde ir jā! IepazÄ«stieties ar Kubernetes (K8s)!

Vispirms apskatÄ«sim, kā vārdi orÄ·estrÄ“Å”ana, klasteris un Kubernetes ir saistÄ«ti viens ar otru. Augstā lÄ«menÄ« orÄ·estrÄ“Å”ana ir sistēma, kas izvieto un pārvalda lietojumprogrammas. Testa automatizācijai Ŕādas konteineru lietojumprogrammas ir Selēna režģis un Selenoid. Docker un K8 papildina viens otru. Pirmais tiek izmantots lietojumprogrammu izvietoÅ”anai, otrais - orÄ·estrÄ“Å”anai. Savukārt K8s ir klasteris. Klastera uzdevums ir izmantot virtuālās maŔīnas kā mezglus, kas ļauj vienā serverÄ« (klasterā) instalēt dažādas funkcionalitātes, programmas un servisus. Ja kāds no mezgliem neizdodas, tiks izmantoti citi mezgli, kas nodroÅ”ina mÅ«su lietojumprogrammas nepārtrauktu darbÄ«bu. Papildus tam K8s ir svarÄ«ga ar mērogoÅ”anu saistÄ«ta funkcionalitāte, pateicoties kurai mēs automātiski iegÅ«stam optimālo resursu daudzumu, pamatojoties uz slodzi un noteiktajiem ierobežojumiem.

PatiesÄ«bā manuāla Kubernetes izvietoÅ”ana no nulles nepavisam nav mazsvarÄ«gs uzdevums. Es atstāŔu saiti uz slaveno ceļvedi "Kubernetes The Hard Way", un, ja jÅ«s interesē, varat to praktizēt. Bet, par laimi, ir alternatÄ«vas metodes un rÄ«ki. VienkārŔākais veids ir izmantot Google Kubernetes Engine (GKE) GCP, kas ļaus jums iegÅ«t gatavu klasteru ar dažiem klikŔķiem. Es iesaku izmantot Å”o pieeju, lai sāktu mācÄ«Å”anos, jo tā ļaus jums koncentrēties uz mācÄ«Å”anos, kā izmantot K8s saviem uzdevumiem, nevis mācÄ«ties, kā iekŔējās sastāvdaļas ir jāintegrē savā starpā. 

Vērtība automatizācijas infrastruktūrai

Apskatīsim dažas nozīmīgas funkcijas, ko nodroŔina K8s:

  • lietojumprogrammu izvietoÅ”ana: vairāku mezglu klastera izmantoÅ”ana virtuālo maŔīnu vietā;
  • dinamiskā mērogoÅ”ana: samazina resursu izmaksas, kas tiek izmantotas tikai pēc pieprasÄ«juma;
  • paÅ”dziedināŔanās: automātiska pākstu atgÅ«Å”ana (kā rezultātā tiek atjaunoti arÄ« konteineri);
  • atjauninājumu izvērÅ”ana un izmaiņu atsaukÅ”ana bez dÄ«kstāves: atjaunināŔanas rÄ«ki, pārlÅ«kprogrammas un emulatori nepārtrauc paÅ”reizējo lietotāju darbu

Bet K8s joprojām nav sudraba lode. Lai saprastu visas priekÅ”rocÄ«bas un ierobežojumus mÅ«su apsvērto rÄ«ku kontekstā (Selēna režģis, Selenoid), mēs Ä«si apspriedÄ«sim K8 struktÅ«ru. Klasteris satur divu veidu mezglus: galveno mezglu un darbinieku mezglus. Galvenie mezgli ir atbildÄ«gi par pārvaldÄ«bas, izvietoÅ”anas un plānoÅ”anas lēmumiem. Darbinieku mezgli ir vieta, kur tiek darbinātas lietojumprogrammas. Mezgli satur arÄ« konteinera izpildlaika vidi. MÅ«su gadÄ«jumā tas ir Docker, kas ir atbildÄ«gs par darbÄ«bām, kas saistÄ«tas ar konteineriem. Bet ir arÄ« alternatÄ«vi risinājumi, piemēram konteinerā. Ir svarÄ«gi saprast, ka mērogoÅ”ana vai paÅ”atveseļoÅ”anās neattiecas tieÅ”i uz konteineriem. Tas tiek Ä«stenots, pievienojot/samazinot podiņu skaitu, kuros savukārt ir konteineri (parasti viens konteiners katrā podā, bet atkarÄ«bā no uzdevuma var bÅ«t arÄ« vairāk). Augsta lÄ«meņa hierarhija sastāv no strādnieku mezgliem, kuru iekÅ”pusē ir pākstis, kuru iekÅ”pusē ir pacelti konteineri.

MērogoÅ”anas lÄ«dzeklis ir galvenais, un to var lietot gan klastera mezglu pÅ«la mezgliem, gan mezgliem. Ir 2 mērogoÅ”anas veidi, kas attiecas gan uz mezgliem, gan uz pākstiem. Pirmais veids ir horizontāls ā€“ mērogoÅ”ana notiek, palielinot mezglu/podiņu skaitu. Å is veids ir vēlams. Otrais veids attiecÄ«gi ir vertikāls. MērogoÅ”ana tiek veikta, palielinot mezglu/podiņu izmēru, nevis to skaitu.

Tagad aplÅ«kosim mÅ«su rÄ«kus iepriekÅ” minēto nosacÄ«jumu kontekstā.

Selēna režģis

Kā minēts iepriekÅ”, selēna režģis ir ļoti populārs rÄ«ks, un nav pārsteigums, ka tas ir ievietots konteineros. Tāpēc nav pārsteigums, ka Selēna režģi var izvietot K8s. Piemērs, kā to izdarÄ«t, ir atrodams oficiālajā K8s repozitorijā. Kā parasti, sadaļas beigās pievienoju saites. Turklāt pamācÄ«bā ir parādÄ«ts, kā to izdarÄ«t programmā Terraform. Ir arÄ« norādÄ«jumi par to, kā mērogot to aplikumu skaitu, kuros ir pārlÅ«kprogrammas konteineri. Bet automātiskās mērogoÅ”anas funkcija K8s kontekstā joprojām nav pilnÄ«gi acÄ«mredzams uzdevums. Uzsākot studijas, neatradu nekādus praktiskus norādÄ«jumus vai ieteikumus. Pēc vairākiem pētÄ«jumiem un eksperimentiem ar DevOps komandas atbalstu mēs izvēlējāmies pieeju konteineru pacelÅ”anai ar nepiecieÅ”amajiem pārlÅ«kiem vienā podā, kas atrodas viena darba mezgla iekÅ”pusē. Å Ä« metode ļauj pielietot mezglu horizontālās mērogoÅ”anas stratēģiju, palielinot to skaitu. Ceru, ka nākotnē tas mainÄ«sies un mēs redzēsim arvien vairāk aprakstu par labākām pieejām un gataviem risinājumiem, Ä«paÅ”i pēc Selenium grid 4 izdoÅ”anas ar mainÄ«tu iekŔējo arhitektÅ«ru.

Selenoīds:

SelenoÄ«da izvietoÅ”ana K8s paÅ”laik ir lielākā vilÅ”anās. Tie nav saderÄ«gi. Teorētiski mēs varam pacelt Selenoid konteineru podā, bet, kad Selenoid sāks palaist konteinerus ar pārlÅ«kprogrammām, tie joprojām bÅ«s tajā paŔā podā. Tas padara mērogoÅ”anu neiespējamu, un rezultātā Selenoid darbs klasterÄ« neatŔķirsies no darba virtuālajā maŔīnā. Stāsta beigas.

mēness:

Zinot Å”o vājo vietu, strādājot ar Selenoid, izstrādātāji izlaida jaudÄ«gāku rÄ«ku ar nosaukumu Moon. Å is rÄ«ks sākotnēji tika izstrādāts darbam ar Kubernetes, un tāpēc var un vajadzētu izmantot automātiskās mērogoÅ”anas funkciju. Turklāt es teiktu, ka Å”obrÄ«d tā ir vienÄ«gais rÄ«ks Selēna pasaulē, kuram ir sākotnējā K8s klasteru atbalsts (vairs nav pieejams, skatiet nākamo rÄ«ku ). Galvenās Moon funkcijas, kas nodroÅ”ina Å”o atbalstu, ir: 

PilnÄ«gi bezvalstnieks. SelenoÄ«ds saglabā atmiņā informāciju par paÅ”laik palaistajām pārlÅ«kprogrammas sesijām. Ja kāda iemesla dēļ tā process avarē - visas darbÄ«bas sesijas tiek zaudētas. Mēnesim gluži pretēji nav iekŔēja stāvokļa, un to var atkārtot datu centros. PārlÅ«kprogrammas sesijas paliek aktÄ«vas pat tad, ja viena vai vairākas kopijas pazÅ«d.

Tātad, Mēness ir lielisks risinājums, taču ir viena problēma: tas nav bezmaksas. Cena ir atkarÄ«ga no sesiju skaita. Bez maksas varat palaist tikai 0ā€“4 sesijas, kas nav Ä«paÅ”i noderÄ«gi. Bet, sākot no piektās sesijas, jums bÅ«s jāmaksā USD 5 par katru. Situācija dažādos uzņēmumos var atŔķirties, taču mÅ«su gadÄ«jumā Moon lietoÅ”ana ir bezjēdzÄ«ga. Kā jau aprakstÄ«ju iepriekÅ”, mēs varam darbināt virtuālās maŔīnas ar Selenium Grid pēc pieprasÄ«juma vai palielināt mezglu skaitu klasterÄ«. Aptuveni vienam konveijeram mēs palaižam 500 pārlÅ«kprogrammas un apturam visus resursus pēc testu pabeigÅ”anas. Ja mēs izmantotu Moon, mums bÅ«tu jāmaksā papildu 500 x 5 = 2500 USD mēnesÄ« neatkarÄ«gi no tā, cik bieži mēs veicam testus. Es atkal nesaku, ka neizmantojiet Moon. JÅ«su uzdevumiem tas var bÅ«t neaizstājams risinājums, piemēram, ja jÅ«su organizācijā ir daudz projektu/komandu un jums ir nepiecieÅ”ams milzÄ«gs kopÄ«gs klasteris visiem. Kā vienmēr, beigās atstāju saiti un iesaku veikt visus nepiecieÅ”amos aprēķinus sava uzdevuma kontekstā.

Callisto: (Uzmanību! Tas nav oriģinālajā rakstā un ir ietverts tikai tulkojumā krievu valodā)

Kā jau teicu, Selēns ir ļoti populārs rÄ«ks, un IT joma attÄ«stās ļoti strauji. Kamēr strādāju pie tulkoÅ”anas, tÄ«meklÄ« parādÄ«jās jauns daudzsoloÅ”s rÄ«ks Callisto (sveiki Cypress un citi Selēna slepkavas). Tas darbojas sākotnēji ar K8s un ļauj darbināt Selenoid konteinerus, kas sadalÄ«ti pa mezgliem. Viss darbojas uzreiz no kastes, ieskaitot automātisko mērogoÅ”anu. Fantastiski, bet vajag pārbaudÄ«t. Man jau ir izdevies izvietot Å”o rÄ«ku un veikt vairākus eksperimentus. Bet ir pāragri izdarÄ«t secinājumus, pēc rezultātu saņemÅ”anas lielā attālumā, iespējams, es izdarÄ«Å”u pārskatu nākamajos rakstos. Pagaidām es atstāju tikai saites neatkarÄ«giem pētÄ«jumiem.  

PaÅ”reizējā infrastruktÅ«ras stāvokļa ilustrācija

DevOps rīki nav paredzēti tikai DevOps. Testa automatizācijas infrastruktūras izveides process no nulles

Saites izpētei

Līdzīgi rīki

7. InfrastruktÅ«ra kā kods (IAC)

ÄŖss tehnoloÄ£ijas apraksts

Un tagad mēs nonākam pie pēdējās sadaļas. Parasti par Å”o tehnoloÄ£iju un saistÄ«tiem uzdevumiem nav atbildÄ«gi automatizācijas inženieri. Un tam ir iemesli. Pirmkārt, daudzās organizācijās infrastruktÅ«ras jautājumi ir DevOps departamenta pārziņā, un izstrādes komandām nav Ä«sti svarÄ«gi, kas nodroÅ”ina cauruļvada darbÄ«bu un kā viss ar to saistÄ«tais ir jāatbalsta. Otrkārt, bÅ«sim godÄ«gi, Infrastructure as Code (IaC) prakse joprojām nav pieņemta daudzos uzņēmumos. Taču tā noteikti ir kļuvusi par populāru tendenci un ir svarÄ«gi censties iesaistÄ«ties ar to saistÄ«tajos procesos, pieejās un rÄ«kos. Vai vismaz esiet lietas kursā.

Sāksim ar Ŕīs pieejas izmantoÅ”anas motivāciju. Mēs jau esam apsprieduÅ”i, ka, lai veiktu testus GitlabCI, mums bÅ«s nepiecieÅ”ami vismaz resursi, lai palaistu Gitlab Runner. Un, lai palaistu konteinerus ar pārlÅ«kprogrammām/emulatoriem, mums ir jārezervē virtuālā maŔīna vai klasteris. Papildus testÄ“Å”anas resursiem mums ir nepiecieÅ”ama ievērojama jauda, ā€‹ā€‹lai atbalstÄ«tu izstrādes, iestudÄ“Å”anas, ražoÅ”anas vides, kas ietver arÄ« datu bāzes, automātiskos grafikus, tÄ«kla konfigurācijas, slodzes balansētājus, lietotāju tiesÄ«bas utt. Galvenais jautājums ir pÅ«les, kas nepiecieÅ”amas, lai to visu atbalstÄ«tu. Ir vairāki veidi, kā mēs varam veikt izmaiņas un ieviest atjauninājumus. Piemēram, GCP kontekstā mēs varam izmantot UI konsoli pārlÅ«kprogrammā un veikt visas darbÄ«bas, noklikŔķinot uz pogām. AlternatÄ«va bÅ«tu izmantot API izsaukumus, lai mijiedarbotos ar mākoņa entÄ«tijām, vai izmantot komandrindas utilÄ«tu gcloud, lai veiktu vēlamās manipulācijas. Taču ar patieŔām lielu skaitu dažādu entÄ«tiju un infrastruktÅ«ras elementu kļūst grÅ«ti vai pat neiespējami veikt visas darbÄ«bas manuāli. Turklāt visas Ŕīs manuālās darbÄ«bas ir nekontrolējamas. Mēs nevaram tos iesniegt pārskatÄ«Å”anai pirms izpildes, izmantot versiju kontroles sistēmu un ātri atsaukt izmaiņas, kas izraisÄ«ja incidentu. Lai atrisinātu Ŕādas problēmas, inženieri izveidoja un izveido automātiskus bash/shell skriptus, kas nav daudz labāki par iepriekŔējām metodēm, jo ā€‹ā€‹tos nav tik viegli ātri lasÄ«t, saprast, uzturēt un modificēt procesuālā stilā.

Å ajā rakstā un pamācÄ«bā es izmantoju 2 rÄ«kus, kas saistÄ«ti ar IaC praksi. Tie ir Terraform un Ansible. Daži cilvēki uzskata, ka nav jēgas tos izmantot vienlaikus, jo to funkcionalitāte ir lÄ«dzÄ«ga un tās ir savstarpēji aizstājamas. Bet fakts ir tāds, ka sākotnēji viņiem tiek doti pavisam citi uzdevumi. Un to, ka Å”iem rÄ«kiem vajadzētu papildināt vienam otru, kopÄ«gā prezentācijā apstiprināja izstrādātāji, kas pārstāv HashiCorp un RedHat. Konceptuālā atŔķirÄ«ba ir tāda, ka Terraform ir nodroÅ”inājuma rÄ«ks paÅ”u serveru pārvaldÄ«bai. Kaut arÄ« Ansible ir konfigurācijas pārvaldÄ«bas rÄ«ks, kura uzdevums ir instalēt, konfigurēt un pārvaldÄ«t programmatÅ«ru Å”ajos serveros.

Vēl viena Å”o rÄ«ku atŔķirÄ«gā iezÄ«me ir kodÄ“Å”anas stils. AtŔķirÄ«bā no bash un Ansible, Terraform izmanto deklaratÄ«vu stilu, pamatojoties uz vēlamā beigu stāvokļa aprakstu, kas jāsasniedz izpildes rezultātā. Piemēram, ja mēs izveidosim 10 VM un piemērosim izmaiņas, izmantojot Terraform, tad mēs iegÅ«sim 10 VM. Ja mēs palaidÄ«sim skriptu vēlreiz, nekas nenotiks, jo mums jau ir 10 VM, un Terraform par to zina, jo saglabā paÅ”reizējo infrastruktÅ«ras stāvokli stāvokļa failā. Bet Ansible izmanto procesuālu pieeju, un, ja lÅ«gsit tai izveidot 10 VM, tad pirmajā palaiÅ”anas reizē mēs saņemsim 10 VM, lÄ«dzÄ«gi kā Terraform. Bet pēc restartÄ“Å”anas mums jau bÅ«s 20 VM. Å Ä« ir bÅ«tiskā atŔķirÄ«ba. ProcedÅ«ras stilā mēs nesaglabājam paÅ”reizējo stāvokli un vienkārÅ”i aprakstām veicamo darbÄ«bu secÄ«bu. Protams, mēs varam risināt dažādas situācijas, pievienot vairākas pārbaudes par resursu esamÄ«bu un paÅ”reizējo stāvokli, taču nav jēgas tērēt savu laiku un pielikt spēkus Ŕīs loÄ£ikas savaldÄ«Å”anai. Turklāt tas palielina kļūdu iespējamÄ«bu. 

Apkopojot visu iepriekÅ” minēto, varam secināt, ka Terraform un deklaratÄ«vā notācija ir piemērotāks rÄ«ks serveru nodroÅ”ināŔanai. Bet labāk konfigurācijas pārvaldÄ«bas darbu deleģēt Ansible. Ņemot to vērā, aplÅ«kosim lietoÅ”anas gadÄ«jumus automatizācijas kontekstā.

Vērtība automatizācijas infrastruktūrai

VienÄ«gais, kas Å”eit ir jāsaprot, ir tas, ka testÄ“Å”anas automatizācijas infrastruktÅ«ra ir jāuzskata par visas uzņēmuma infrastruktÅ«ras daļu. Tas nozÄ«mē, ka visas IaC prakses ir jāpiemēro globāli visas organizācijas resursiem. Tas, kurÅ” par to ir atbildÄ«gs, ir atkarÄ«gs no jÅ«su procesiem. DevOps komanda Å”ajos jautājumos ir pieredzējuŔāka, viņi redz visu notiekoÅ”o. Taču kvalitātes nodroÅ”ināŔanas inženieri vairāk iesaistās ēku automatizācijas un cauruļvada uzbÅ«ves procesā, kas ļauj labāk saskatÄ«t visas nepiecieÅ”amās izmaiņas un uzlaboÅ”anas iespējas. Labākais variants ir strādāt kopā, apmainÄ«ties ar zināŔanām un idejām, lai sasniegtu gaidÄ«to rezultātu. 

Å eit ir daži Terraform un Ansible izmantoÅ”anas piemēri testÄ“Å”anas automatizācijas un iepriekÅ” apspriesto rÄ«ku kontekstā.

1. Aprakstiet nepiecieŔamos VM un klasteru raksturlielumus un parametrus, izmantojot Terraform.

2. Izmantojot Ansible, instalējiet testÄ“Å”anai nepiecieÅ”amos rÄ«kus: docker, Selenoid, Selenium Grid un lejupielādējiet nepiecieÅ”amās pārlÅ«kprogrammu/emulatoru versijas.

3. Izmantojot Terraform, aprakstiet virtuālās maŔīnas īpaŔības, kurā tiks palaists GitLab Runner.

4. Instalējiet GitLab Runner un nepiecieÅ”amos pavadoÅ”os rÄ«kus, izmantojot Ansible, iestatiet iestatÄ«jumus un konfigurācijas.

PaÅ”reizējā infrastruktÅ«ras stāvokļa ilustrācija

DevOps rīki nav paredzēti tikai DevOps. Testa automatizācijas infrastruktūras izveides process no nulles

Saites, ko izpētīt:

Līdzīgi rīki

Apkoposim!

Solis
Tehnoloģija
darbarīki
Vērtība automatizācijas infrastruktūrai

1
Vietējā skrieÅ”ana
Node.js, Selēns, Appium

  • Populārākie rÄ«ki tÄ«meklim un mobilajām ierÄ«cēm
  • Atbalsta daudzas valodas un platformas (tostarp Node.js)

2
Versiju kontroles sistēmas 
Git

  • LÄ«dzÄ«gas priekÅ”rocÄ«bas ar izstrādes kodu

3
Konteinerizācija
Docker, Selēna režģis, Selenoid (tīmeklis, Android)

  • Paralēli veic testus
  • Izolētas vides
  • VienkārÅ”i, elastÄ«gi versiju jauninājumi
  • Dinamiska neizmantoto resursu apturÄ“Å”ana
  • Viegli uzstādÄ«t

4
CI/CD
Gitlab CI

  • Pārbauda cauruļvada daļu
  • Ātrās atsauksmes
  • RedzamÄ«ba visam uzņēmumam/komandai

5
Mākoņu platformas
Google mākoņa platforma

  • Resursi pēc pieprasÄ«juma (maksājam tikai pēc nepiecieÅ”amÄ«bas)
  • Viegli pārvaldÄ«t un atjaunināt
  • Visu resursu redzamÄ«ba un kontrole

6
Orķestrācija
Kubernetes
Konteineru kontekstā ar pārlūkprogrammām/emulatoriem podiņos:

  • MērogoÅ”ana/automātiskā mērogoÅ”ana
  • PaÅ”dziedināŔanās
  • Atjauninājumi un atcelÅ”anas bez pārtraukuma

7
Infrastruktūra kā kods (IaC)
Terraforma, Ansible

  • LÄ«dzÄ«gi ieguvumi ar attÄ«stÄ«bas infrastruktÅ«ru
  • Visas koda versiju izveides priekÅ”rocÄ«bas
  • Viegli veikt izmaiņas un uzturēt
  • PilnÄ«bā automatizēts

Domu karŔu diagrammas: infrastruktūras evolūcija

1. darbība: vietējais
DevOps rīki nav paredzēti tikai DevOps. Testa automatizācijas infrastruktūras izveides process no nulles

2. darbība: VCS
DevOps rīki nav paredzēti tikai DevOps. Testa automatizācijas infrastruktūras izveides process no nulles

3. darbÄ«ba: konteineru ievietoÅ”ana 
DevOps rīki nav paredzēti tikai DevOps. Testa automatizācijas infrastruktūras izveides process no nulles

4. darbÄ«ba: CI/CD 
DevOps rīki nav paredzēti tikai DevOps. Testa automatizācijas infrastruktūras izveides process no nulles

5. darbība: mākoņu platformas
DevOps rīki nav paredzēti tikai DevOps. Testa automatizācijas infrastruktūras izveides process no nulles

6. darbība: Orķestrācija
DevOps rīki nav paredzēti tikai DevOps. Testa automatizācijas infrastruktūras izveides process no nulles

7. darbība: IaC
DevOps rīki nav paredzēti tikai DevOps. Testa automatizācijas infrastruktūras izveides process no nulles

Ko tālāk?

Tātad, Å”is ir raksta beigas. Bet nobeigumā es vēlētos ar jums noslēgt dažus lÄ«gumus.

No tavas puses
Kā jau teicu sākumā, es vēlētos, lai raksts bÅ«tu praktiski noderÄ«gs un palÄ«dzētu pielietot iegÅ«tās zināŔanas reālā darbā. Es pievienoju vēlreiz saite uz praktisko rokasgrāmatu.

Bet arī pēc tam neapstājieties, praktizējieties, studējiet attiecīgās saites un grāmatas, uzziniet, kā tas darbojas jūsu uzņēmumā, atrodiet vietas, kuras var uzlabot, un piedalieties tajā. Veiksmi!

No manas puses

Pēc virsraksta var redzēt, ka Ŕī bija tikai pirmā daļa. Neskatoties uz to, ka tas izrādÄ«jās diezgan liels, svarÄ«gas tēmas Å”eit joprojām netiek apskatÄ«tas. Otrajā daļā plānoju aplÅ«kot automatizācijas infrastruktÅ«ru IOS kontekstā. Tā kā Apple ierobežo iOS simulatoru darbināŔanu tikai macOS sistēmās, mÅ«su risinājumu klāsts ir saÅ”aurināts. Piemēram, mēs nevaram izmantot Docker, lai palaistu simulatoru, vai publiskos mākoņus, lai palaistu virtuālās maŔīnas. Bet tas nenozÄ«mē, ka nav citu alternatÄ«vu. Es centÄ«Å”os jÅ«s informēt par progresÄ«viem risinājumiem un moderniem rÄ«kiem!

Tāpat neesmu minējis diezgan lielas tēmas saistÄ«bā ar monitoringu. 3. daļā es apskatÄ«Å”u populārākos infrastruktÅ«ras uzraudzÄ«bas rÄ«kus un to, kādi dati un rādÄ«tāji jāņem vērā.

Un visbeidzot. Nākotnē es plānoju izdot video kursu par testÄ“Å”anas infrastruktÅ«ras un populāru rÄ«ku izveidi. Å obrÄ«d internetā ir diezgan daudz kursu un lekciju par DevOps, taču visi materiāli tiek prezentēti izstrādes, nevis testa automatizācijas kontekstā. Å ajā jautājumā man patieŔām ir vajadzÄ«gas atsauksmes par to, vai Ŕāds kurss bÅ«s interesants un vērtÄ«gs testētāju un automatizācijas inženieru kopienai. Pateicos jau iepriekÅ”!

Avots: www.habr.com

Pievieno komentāru