Beş 1: Web / Android
bingotin: ev gotar wergerandina rûsî ya gotara orjînal e Lêbelê, hemî nîgar, girêdan, ravekirin û têgîn bi zimanê orîjînal têne parastin da ku dema wergerandina rûsî ji guheztina wateyê dûr nekevin. Ez xwendina xweş ji we re dixwazim!
Heya nuha, taybetmendiya DevOps di pîşesaziya IT-ê de yek ji wan daxwaz e. Ger hûn malperên lêgerîna kar ên populer vekin û li gorî meaşê fîlter bikin, hûn ê bibînin ku karên girêdayî DevOps di serê navnîşê de ne. Lêbelê, girîng e ku meriv fêm bike ku ev bi gelemperî behsa pozîsyonek 'Piştî' ye, ku tê vê wateyê ku berendam xwedan astek jêhatîbûn, zanîna teknolojiyê û amûran e. Ev jî bi asteke bilind a berpirsiyariyê ve girêdayî bi xebata bênavber a hilberînê re tê. Lêbelê, me dest bi ji bîr kir ku DevOps çi ye. Di destpêkê de, ew ne kesek an dezgehek taybetî bû. Ger em li pênaseyên vê têgînê bigerin, em ê gelek navdêrên xweş û rast bibînin, wek rêbaz, pratîk, felsefeya çandî, koma têgînan û hwd.
Pisporiya min endezyarek otomatîkê ya ceribandinê ye (endazyarê otomatîkkirina QA), lê ez bawer dikim ku ew ne tenê bi nivîsandina testên otomatîkî an pêşkeftina mîmariya çarçoveya testê re têkildar be. Di sala 2020-an de, zanîna binesaziya otomasyonê jî pêdivî ye. Ev dihêle hûn pêvajoya xweseriyê bi xwe organîze bikin, ji ceribandinên ceribandinan bigire heya peydakirina encaman ji hemî beşdaran re li gorî armancên xwe. Wekî encamek, jêhatîbûna DevOps pêdivî ye ku kar bi dest bixin. Û ev hemî baş e, lê, mixabin, pirsgirêkek heye (spoiler: ev gotar hewl dide ku vê pirsgirêkê hêsan bike). Mesele ev e ku DevOps dijwar e. Û ev eşkere ye, ji ber ku pargîdan ji bo tiştek ku hêsan e ku meriv bikin dê pir zêde nedin... Di cîhana DevOps de, hejmareke mezin a amûr, şert û pratîk hene ku hewce ne ku werin serdest kirin. Ev bi taybetî di destpêka kariyerek de dijwar e û bi ezmûna teknîkî ya berhevkirî ve girêdayî ye.
Source:
Li vir belkî em ê bi beşa destpêkê biqedînin û li ser armanca vê gotarê bisekinin.
Ev gotar li ser çi ye?
Di vê gotarê de, ez ê ezmûna xwe ya avakirina binesaziyek xweseriya testê parve bikim. Li ser Înternetê gelek çavkaniyên agahdarî li ser amûrên cûrbecûr û awayê karanîna wan hene, lê ez dixwazim bi tenê di çarçoweya otomasyonê de li wan binihêrim. Ez bawer dikim ku gelek endezyarên otomasyonê bi rewşa ku ji bilî we tu kes ceribandinên pêşkeftî dimeşîne an jî li ser domandina wan eleqedar nabe nas dikin. Wekî encamek, ceribandin kevnar dibin û pêdivî ye ku hûn wextê nûvekirina wan derbas bikin. Dîsa, di destpêka kariyerek de, ev dikare bibe karekî pir dijwar: bi aqilmendî biryardana kîjan amûran divê ji rakirina pirsgirêkek diyarkirî re bibe alîkar, meriv çawa wan hilbijêrin, mîhengkirin û domandin. Hin ceribandin ji bo alîkariyê serî li DevOps (mirov) didin û, em rastdar bin, ev nêzîkatî dixebite. Di pir rewşan de dibe ku ev vebijarkek yekane be ji ber ku em di hemî pêwendiyan de xuyang nakin. Lê wekî ku em dizanin, DevOps xortên pir mijûl in, ji ber ku ew neçar in ku li ser binesaziya pargîdanî, bicîhkirin, çavdêrîkirin, mîkroxizmet û karên din ên bi vî rengî li gorî rêxistin / tîmê bifikirin. Wekî ku bi gelemperî rewş e, otomasyon ne pêşînek e. Di rewşeke wiha de divê em ji serî heta dawiyê hewl bidin her tiştî ji aliyê xwe ve bikin. Ev ê pêwendiyan kêm bike, leza xebatê bilez bike, jêhatîbûnên me baştir bike û rê bide me ku em wêneyê mezin ê tiştê ku diqewime bibînin.
Gotar amûrên herî populer û populer pêşkêşî dike û destnîşan dike ku meriv wan çawa bikar tîne da ku gav bi gav binesaziyek otomasyonê ava bike. Her kom bi amûrên ku bi ezmûna kesane ve hatine ceribandin têne temsîl kirin. Lê ev nayê wê wateyê ku hûn heman tiştî bikar bînin. Amûr bi xwe ne girîng in, xuya dibin û kevin dibin. Karê meya endezyariyê ev e ku em prensîbên bingehîn fam bikin: çima em hewceyê vê koma amûran in û kîjan pirsgirêkên xebatê em dikarin bi alîkariya wan çareser bikin. Ji ber vê yekê di dawiya her beşê de ez lînkên amûrên mîna yên ku di rêxistina we de têne bikar anîn dihêlim.
Di vê gotarê de çi nîne
Ez careke din dubare dikim ku gotar ne li ser amûrên taybetî ye, ji ber vê yekê dê kodek ji belgekirin û ravekirina emrên taybetî tune be. Lê di dawiya her beşê de ez ji bo lêkolîna berfireh lînkan dihêlim.
Ev tê kirin ji ber ku:
- dîtina vê materyalê di çavkaniyên cihêreng de (belge, pirtûk, qursên vîdyoyê) pir hêsan e;
- heke em dest bi kûrtir bikin, divê em 10, 20, 30 beşên vê gotarê binivîsin (digel ku plan 2-3 in);
- Ez tenê naxwazim wextê we winda bikim ji ber ku hûn dikarin amûrên din bikar bînin da ku bigihîjin heman armancan.
Praktice
Bi rastî ez dixwazim ku ev materyal ji bo her xwendevanek kêrhatî be, û ne tenê were xwendin û ji bîr kirin. Di her lêkolînê de, pratîk hêmanek pir girîng e. Ji bo vê min amade kiriye. Di heman demê de karê malê jî li benda we ye ku hûn pê ewle bin ku hûn rêzikên fermanên ku hûn dimeşînin bi bêhiş kopî nekin.
Plan
Gav
Technology
Amûrên
1
Rêvekirina herêmî (testên demo yên web / android amade bikin û wê li herêmî bimeşînin)
Node.js, Selenium, Appium
2
pergalên kontrol Versiyon ji
herin
3
Konteynerkirin
Docker, tora Selenium, Selenoid (Web, Android)
4
CI/CD
Gitlab CI
5
platformên Cloud
Platforma Google Cloud
6
Orchestration
Kubernetes
7
Binesaziya wekî kodek (IaC)
Terraform, Ansible
Struktura her beşê
Ji bo zelalbûna vegotinê, her beş li gorî rêzika jêrîn tê vegotin:
- ravekirina kurt a teknolojiyê,
- nirxa ji bo binesaziya otomasyonê,
- nîgara rewşa heyî ya binesaziyê,
- girêdanên xwendinê,
- amûrên wekhev.
1. Testên herêmî bimeşînin
Danasîna kurt a teknolojiyê
Ev tenê pêngavek amadekar e ku hûn ceribandinên demo-yê herêmî bimeşînin û verast bikin ku ew derbas dibin. Di beşa pratîkî de, Node.js tê bikaranîn, lê ziman û platforma bernamekirinê jî ne girîng in û hûn dikarin yên ku di pargîdaniya xwe de têne bikar anîn bikar bînin.
Lêbelê, wekî amûrên otomasyonê, ez bi rêzdarî pêşniyar dikim Selenium WebDriver ji bo platformên malperê û Appium ji bo platforma Android-ê bikar bînin, ji ber ku di gavên pêş de em ê wêneyên Docker-ê yên ku ji bo ku bi taybetî bi van amûran re dixebitin bikar bînin bikar bînin. Digel vê yekê, li gorî hewcedariyên kar, ev amûr di sûkê de herî zêde daxwaz in.
Wekî ku we dîtiye, em tenê ceribandinên web û Android-ê dihesibînin. Mixabin, iOS çîrokek bi tevahî cûda ye (spas ji Apple re). Ez plan dikim ku di beşên pêş de çareserî û pratîkên têkildarî IOS-ê destnîşan bikim.
Nirx ji bo binesaziya automation
Ji perspektîfa binesaziyê, meşandina herêmî ti nirxek peyda nake. Hûn tenê kontrol dikin ku ceribandin li ser makîneya herêmî di gerok û simulatorên herêmî de têne meşandin. Lê di her rewşê de, ev xala destpêkek pêdivî ye.
Nîşana rewşa heyî ya binesaziyê
Girêdanên ji bo lêgerînê
Amûrên wekhev
- her zimanek bernamesaziyê ku hûn jê hez dikin digel ceribandinên Selenium/Appium;
- her ceribandin;
- her bezê testê.
2. Pergalên kontrola guhertoyê (Git)
Danasîna kurt a teknolojiyê
Ger ez bibêjim ku kontrolkirina guhertoyê hem di tîmek û hem jî bi kesane de, beşek pir girîng a pêşkeftinê ye, ew ê ji kesî re ne diyariyek mezin be. Li ser bingeha çavkaniyên cihêreng, meriv bi ewlehî dikare bêje ku Git nûnerê herî populer e. Pergalek kontrolkirina guhertoyê gelek feydeyan peyda dike, wekî parvekirina kodê, hilanîna guhertoyan, vegerandina şaxên berê, şopandina dîroka projeyê, û paşvekêşan. Em ê her xalê bi hûrgulî nîqaş nekin, ji ber ku ez bawer im ku hûn jê re pir nas in û di xebata xwe ya rojane de bikar tînin. Lê heke ji nişkê ve nebe, wê hingê ez pêşniyar dikim ku hûn xwendina vê gotarê rawestînin û di zûtirîn dem de vê valahiyê dagirin.
Nirx ji bo binesaziya automation
Û li vir hûn dikarin pirsek maqûl bipirsin: "Çima ew ji me re li ser Git dibêje? Her kes vê yekê dizane û hem ji bo koda pêşkeftinê û hem jî ji bo koda testa otomatîkî bikar tîne." Hûn ê bi tevahî rast bin, lê di vê gotarê de em li ser binesaziyê diaxivin û ev beş ji bo beşa 7-ê wekî pêşdîtinek tevdigere: "Binesaziya wekî Kodê (IaC)". Ji bo me, ev tê vê wateyê ku tevahiya binesaziyê, tevî ceribandinê, di forma kodê de tê ravekirin, ji ber vê yekê em dikarin pergalên guhertoyê jî li ser wê bicîh bikin û feydeyên mîna ji bo pêşkeftin û koda otomasyonê bistînin.
Em ê di Gav 7-ê de bi hûrgulî li IaC-ê binihêrin, lê tewra nuha jî hûn dikarin bi çêkirina depoyek herêmî dest bi karanîna Git-a herêmî bikin. Dema ku em depoyek dûr li binesaziyê zêde bikin dê wêneya mezin were berfireh kirin.
Nîşana rewşa heyî ya binesaziyê
Girêdanên ji bo lêgerînê
Amûrên wekhev
3. Konteynerkirin (Docker)
Danasîna kurt a teknolojiyê
Ji bo ku nîşan bidin ka konteyneran çawa qaîdeyên lîstikê guhezandiye, em vegerin çend dehsalan. Wê hingê, mirovan makîneyên serverê kirîn û bikar anîn da ku serlêdanan bimeşînin. Lê di pir rewşan de, çavkaniyên destpêkê yên pêwîst di pêş de nedihatin zanîn. Wekî encamek, pargîdaniyan ji bo kirîna serverên biha û hêzdar drav xerc kirin, lê hin ji vê kapasîteyê bi tevahî nehat bikar anîn.
Qonaxa paşîn a pêşkeftinê makîneyên virtual (VM) bûn, ku pirsgirêka windakirina drav li ser çavkaniyên neyên bikar anîn çareser kir. Vê teknolojiyê ev gengaz kir ku serîlêdanan ji hev serbixwe di hundurê heman serverê de bimeşînin, cîhê bi tevahî veqetandî veqetînin. Lê mixabin, her teknolojî kêmasiyên xwe hene. Ji bo xebitandina VM pergalek xebitandinê ya bêkêmasî hewce dike, ku CPU, RAM, hilanînê vedixwe û, li gorî OS-ê, pêdivî ye ku lêçûnên lîsansê bêne hesibandin. Van faktoran bandorê li leza barkirinê dikin û veguheztinê dijwar dikin.
Û niha em tên ser konteynirkirinê. Carek din, ev teknolojî pirsgirêka berê çareser dike, ji ber ku konteynir OS-ya tevahî bikar naynin, ku jimarek mezin çavkaniyan azad dike û çareseriyek bilez û maqûl ji bo veguheztinê peyda dike.
Bê guman, teknolojiya konteyneran ne tiştek nû ye û yekem car di dawiya salên 70-an de hate destnîşan kirin. Di wan rojan de gelek lêkolîn, pêşketin û hewldan hatin kirin. Lê ew Docker bû ku vê teknolojiyê adapte kir û ew bi hêsanî ji girseyan re peyda kir. Naha, dema ku em li ser konteyneran diaxivin, di pir rewşan de mebesta me Docker e. Dema ku em li ser konteynerên Docker diaxivin, mebesta me konteynerên Linux ye. Em dikarin pergalên Windows û macOS-ê bikar bînin da ku konteyneran bimeşînin, lê girîng e ku meriv fêm bike ku di vê rewşê de qatek pêvek xuya dike. Mînakî, Docker li Mac-ê bi bêdengî konteynir di hundurê Linux VM-ya sivik de dimeşîne. Em ê vegerin ser vê mijarê gava ku em li ser xebitandina emulatorên Android-ê di hundurê konteyneran de nîqaş bikin, ji ber vê yekê li vir nuwazeyek pir girîng heye ku pêdivî ye ku bi hûrgulî were nîqaş kirin.
Nirx ji bo binesaziya automation
Me dît ku konteynir û Docker xweş in. Ka em vê yekê di çarçoweya otomasyonê de binihêrin, ji ber ku her amûr an teknolojî hewce dike ku pirsgirêkek çareser bike. Ka em di çarçoveya ceribandinên UI de pirsgirêkên eşkere yên xweseriya testê diyar bikin:
- di dema sazkirina Selenium û nemaze Appium de hejmareke mezin a girêdayîbûnê;
- pirsgirêkên lihevhatina di navbera guhertoyên gerok, simulator û ajokaran de;
- nebûna cîhê veqetandî ji bo gerok/simulatoran, ku bi taybetî ji bo xebitandina paralel krîtîk e;
- Ger hewce be ku hûn di heman demê de 10, 50, 100 an jî 1000 gerokan bimeşînin, birêvebirin û domandin dijwar e.
Lê ji ber ku Selenium amûra otomasyonê ya herî populer e û Docker amûra herî populer a konteynerê ye, pêdivî ye ku ne surprîz be ku kesek hewl daye ku wan berhev bike da ku amûrek hêzdar biafirîne da ku pirsgirêkên jorîn çareser bike. Werin em çareseriyên weha bi hûrgulî bifikirin.
Tora Selenium di dokerê de
Ev amûr di cîhana Selenium de ji bo xebitandina gelek gerokan li ser gelek makîneyan û birêvebirina wan ji navendek navendî ya herî populer e. Ji bo destpêkirinê, hûn hewce ne ku bi kêmî ve 2 beşan tomar bikin: Hub û Node (yên). Hub girêkek navendî ye ku hemî daxwazên ceribandinan distîne û wan li Nodên guncan belav dike. Ji bo her Node em dikarin mîhengek taybetî mîheng bikin, mînakî, bi destnîşankirina geroka xwestî û guhertoya wê. Lêbelê, em hîn jî hewce ne ku em xwe bi ajokarên gerokê yên lihevhatî bigirin û wan li ser Nodên xwestinê saz bikin. Ji ber vê yekê, tora Selenium di forma xweya paqij de nayê bikar anîn, ji bilî dema ku em hewce ne ku bi gerokên ku nekarin li ser Linux OS-ê werin saz kirin bixebitin. Ji bo hemî rewşên din, çareseriyek berbiçav û rast dê ev be ku hûn wêneyên Docker bikar bînin da ku Selenium grid Hub û Nodes bikar bînin. Ev nêzîkatî rêveberiya nodê pir hêsan dike, ji ber ku em dikarin wêneya ku em hewce ne bi guhertoyên hevaheng ên gerok û ajokarên ku berê hatine saz kirin hilbijêrin.
Tevî nirxandinên neyînî yên di derbarê aramiyê de, nemaze dema ku hejmareke mezin ji Nodeyan bi paralel dimeşîne, tora Selenium hîn jî amûra herî populer e ji bo meşandina testên Selenium bi paralel. Girîng e ku were zanîn ku cûrbecûr çêtirkirin û guheztinên vê amûrê bi domdarî di çavkaniyek vekirî de xuya dibin, ku li dijî tengahiyên cihêreng şer dikin.
Selenoid ji bo Web
Ev amûr di cîhana Selenium de serkeftinek e ji ber ku ew rast ji qutiyê dixebite û jiyana gelek endezyarên otomasyonê pir hêsantir kiriye. Berî her tiştî, ev ne guhertinek din a tora Selenium e. Di şûna wê de, pêşdebiran guhertoyek bi tevahî nû ya Selenium Hub li Golang afirandin, ku, digel wêneyên sivik ên Docker-ê ji bo gerokên cihêreng, ji bo pêşkeftina otomasyona ceribandinê guheztinek da. Digel vê yekê, di mijara Selenium Grid de, divê em hemî gerokên hewce û guhertoyên wan di pêş de diyar bikin, ku dema ku bi tenê gerokek re dixebitin ne pirsgirêk e. Lê gava ku dor tê ser gelek gerokên piştgirîkirî, Selenoid ji ber taybetmendiya xwe ya 'geroka li ser daxwazê' çareseriya yekem e. Tiştê ku ji me tê xwestin ev e ku em wêneyên pêwîst bi gerokan re di pêş de dakêşin û pelê veavakirinê ya ku Selenoid pê re têkilî daynin nûve bikin. Piştî ku Selenoid daxwazek ji ceribandinan werdigire, ew ê bixweber bi geroka xwestî re konteynera xwestî bide destpêkirin. Dema ku ceribandin qediya, Selenoid dê konteynerê teqawid bike, bi vî rengî çavkaniyên ji bo daxwazên pêşerojê azad bike. Ev nêzîkatî pirsgirêka naskirî ya 'hilweşîna nodê' ya ku em pir caran di tora Selenium de pê re rû bi rû dimînin bi tevahî ji holê radike.
Lê, mixabin, Selenoid hîn jî ne guleyek zîv e. Me taybetmendiya 'geroka li gorî daxwazê' girt, lê taybetmendiya 'çavkaniyên li gorî daxwazê' hîn jî peyda nabe. Ji bo ku Selenoid bikar bînin, divê em wê li ser cîhaza laşî an li ser VM-ê bi cih bikin, ku tê vê wateyê ku divê em berê zanibin ka çend çavkanî hewce ne ku werin veqetandin. Ez texmîn dikim ku ev ji bo projeyên piçûk ên ku 10, 20 an jî 30 gerokên paralel dimeşînin ne pirsgirêk e. Lê heger em hewceyê 100, 500, 1000 û bêtir hewce ne? Ti wate nake ku meriv her dem ewqas çavkaniyan biparêze û bide. Di beşên 5 û 6-ê yên vê gotarê de, em ê çareseriyên ku destûrê didin we pîvandinê nîqaş bikin, bi vî rengî lêçûnên pargîdaniyê bi girîngî kêm bikin.
Selenoid ji bo Android
Piştî serkeftina Selenoid wekî amûrek otomasyona malperê, mirovan ji bo Android-ê tiştek wusa dixwest. Û ev çêbû - Selenoid bi piştgiriya Android-ê hate berdan. Ji nêrînek bikarhênerek-asta bilind, prensîba xebitandinê mîna otomasyona malperê ye. Cudahiya tenê ev e ku li şûna konteynerên gerokê, Selenoid konteynerên emûlatorê Android-ê dimeşîne. Bi dîtina min, ev naha amûra belaş a herî hêzdar e ku ji bo ceribandinên Android-ê bi paralel dimeşîne.
Ez bi rastî naxwazim li ser aliyên neyînî yên vê amûrê biaxivim, ji ber ku ez bi rastî jê hez dikim. Lê dîsa jî, heman dezawantajên ku li ser otomasyona malperê derbas dibin û bi pîvandinê re têkildar in hene. Digel vê yekê, pêdivî ye ku em li ser sînorek din jî biaxivin ku heke em yekem car amûrê saz bikin dibe ku surprîz be. Ji bo ku hûn wêneyên Android-ê bimeşînin, pêdivî ye ku em makîneyek laşî an VM-ya ku bi piştgirîya virtualîzasyona hêlînê ve girêdayî ye. Di rêberiya meriv-çawa de, ez destnîşan dikim ka meriv çawa vê yekê li ser Linux VM-ê çalak dike. Lêbelê, heke hûn bikarhênerek macOS-ê ne û dixwazin Selenoid-ê li herêmê bicîh bikin, wê hingê ev ê ne gengaz be ku ceribandinên Android-ê bimeşînin. Lê hûn her gav dikarin Linux VM-ya herêmî bi 'virtûalîzasyona hêlîn' vesazkirî bimeşînin û Selenoid-ê li hundur bicîh bikin.
Nîşana rewşa heyî ya binesaziyê
Di çarçoveya vê gotarê de, em ê 2 amûran zêde bikin ku binesaziyê ronî bikin. Vana ji bo ceribandinên malperê tora Selenium û ji bo ceribandinên Android-ê Selenoid in. Di dersa GitHub de, ez ê jî nîşanî we bidim ka meriv çawa Selenoid-ê bikar tîne da ku ceribandinên malperê bimeşîne.
Girêdanên ji bo lêgerînê
Amûrên wekhev
- Amûrên din ên konteynirkirinê hene, lê Docker ya herî populer e. Heke hûn dixwazin tiştek din biceribînin, ji bîr mekin ku amûrên ku me ji bo meşandina ceribandinên Selenium bi paralelî veşartiye dê ji qutiyê nexebitin.
- Wekî ku berê jî got, gelek guhertinên tora Selenium hene, wek nimûne,.
4.CI/CD
Danasîna kurt a teknolojiyê
Pratîka yekbûna domdar di pêşkeftinê de pir populer e û bi pergalên kontrolkirina guhertoyê re li hev e. Digel vê yekê, ez hest dikim ku di termînolojiyê de tevliheviyek heye. Di vê paragrafê de ez dixwazim 3 guhertinên vê teknolojiyê ji nêrîna xwe vebêjim. Li ser înternetê hûn ê gelek gotarên bi şîroveyên cihê bibînin, û heke nêrîna we ji hev cûda be, bi tevahî normal e. Ya herî girîng ev e ku hûn bi hevkarên xwe re di heman rûpelê de bin.
Ji ber vê yekê, 3 şert hene: CI - Yekbûna Berdewam, CD - Radestkirina Berdewam û dîsa CD - Dabeşkirina Berdewam. (Li jêr ez ê van peyvan bi Îngilîzî bi kar bînim). Her guheztin çend gavên din li lûleya pêşkeftina we zêde dike. Lê peyv bêbirrînî (berdewam) ya herî girîng e. Di vê çarçoveyê de, mebesta me tiştek e ku ji destpêkê heya dawiyê, bêyî navber an destwerdana destan diqewime. Ka em di vê çarçoveyê de li CI & CD û CD binêrin.
- Integration Continuous ev gava destpêkê ya pêşveçûnê ye. Piştî şandina koda nû ji serverê re, em hêvî dikin ku bersivek bilez bistînin ku guhertinên me baş in. Bi gelemperî, CI di nav xwe de amûrên analîzkirina koda statîk û testên API-ê yên yekîneyê/hundirîn dihewîne. Ev dihêle ku em di nav çend saniyeyan/deqîqan de agahdariya li ser koda xwe bistînin.
- Radestkirina Berdewam gavek pêşkeftî ye ku em ceribandinên entegrasyonê/UI-yê dimeşînin. Lêbelê, di vê qonaxê de em bi qasî CI-ê zû encam nagirin. Ya yekem, ev celeb ceribandin ji bo temamkirina dirêjtir digire. Ya duyemîn, berî destpêkirinê, divê em guheztinên xwe li hawîrdora ceribandinê / qonaxê bicîh bikin. Wekî din, heke em li ser pêşkeftina mobîl diaxivin, wê hingê gavek din xuya dike ku avahiyek serîlêdana me biafirîne.
- Depandina Berdewam texmîn dike ku heke hemî ceribandinên pejirandinê di qonaxên berê de derbas bûne, em bixweber guhertinên xwe di hilberînê de berdan. Digel vê yekê, piştî qonaxa berdanê, hûn dikarin qonaxên cihêreng mîheng bikin, wek ceribandinên dûmanê li ser hilberînê û berhevkirina metrîkên berjewendiyê. Dabeşkirina Berdewam tenê bi vegirtina baş a ji hêla ceribandinên otomatîkî ve gengaz e. Ger destwerdanên destan hewce ne, tevî ceribandinê, wê hingê ev êdî ne Bêbirrînî (bêbirrînî). Wê hingê em dikarin bibêjin ku xeta boriyê me tenê bi pratîka Radestkirina Berdewam re tevdigere.
Nirx ji bo binesaziya automation
Di vê beşê de, divê ez eşkere bikim ku dema ku em li ser ceribandinên UI-ya dawî-bi-dawî diaxivin, ev tê vê wateyê ku divê em guheztin û karûbarên xwe yên têkildar ji bo hawîrdorên ceribandinê bicîh bikin. Yekbûna Berdewam - pêvajo ji bo vê peywirê ne derbasdar e û divê em bi kêmanî pratîkên Radestkirina Berdewam bicîh bînin. Ger em ê wan di hilberînê de bimeşînin, Damezrandina Berdewam di çarçoveya ceribandinên UI de jî watedar e.
Û berî ku em li nîgara guherîna mîmariyê binerin, ez dixwazim çend peyvan li ser GitLab CI bibêjim. Berevajî amûrên din ên CI/CD, GitLab depoyek dûr û gelek taybetmendiyên din ên din peyda dike. Bi vî rengî, GitLab ji CI-ê bêtir e. Ew rêveberiya koda çavkaniyê, rêveberiya Agile, boriyên CI/CD, amûrên têketinê û berhevkirina metrîkan ji qutiyê vedihewîne. Mîmariya GitLab ji Gitlab CI/CD û GitLab Runner pêk tê. Li vir şiroveyek kurt ji malpera fermî ye:
Gitlab CI/CD serîlêdanek webê ye bi API-yê ku rewşa xwe di databasekê de hilîne, projeyan/ava dike û navberek bikarhêner peyda dike. GitLab Runner serîlêdanek e ku pêvajoyê çêdike. Ew dikare ji hev veqetandî were bicîh kirin û bi GitLab CI/CD bi navgîniya API-yê re dixebite. Ji bo ceribandinên ku têne xebitandin hûn hem mînaka Gitlab û hem jî Runner hewce ne.
Nîşana rewşa heyî ya binesaziyê
Girêdanên ji bo lêgerînê
Amûrên wekhev
- Û gelekên din
5. platformên Cloud
Danasîna kurt a teknolojiyê
Di vê beşê de em ê li ser meyla populer a bi navê 'ewrên giştî' biaxivin. Tevî feydeyên mezin ên ku teknolojiyên virtualîzasyon û konteynirkirinê yên ku li jor hatine destnîşan kirin peyda dikin, em hîn jî hewceyê çavkaniyên hesabkirinê ne. Pargîdan serverên biha dikirin an navendên daneyê kirê dikin, lê di vê rewşê de pêdivî ye ku hesaban bikin (carinan ne rast in) ka em ê çend çavkaniyan hewce bikin, gelo em ê wan 24/7 û ji bo çi armancan bikar bînin. Mînakî, hilberandin serverek XNUMX/XNUMX hewce dike, lê gelo ji bo ceribandina li derveyî demjimêrên xebatê ji me re çavkaniyên wekhev hewce ne? Ew jî bi celebê ceribandinê ve girêdayî ye. Nimûneyek dê ceribandinên barkêş / stresê be ku em plan dikin ku di demjimêrên nexebitî de bimeşînin da ku roja din encam bigirin. Lê bê guman hebûna servera XNUMX/XNUMX ji bo ceribandinên otomatîkî yên dawî-bi-dawî û nemaze ji bo hawîrdorên ceribandina destan ne hewce ye. Ji bo rewşên weha, dê baş be ku meriv li gorî daxwazê bi qasî hewcedariyên çavkanî bidest bixin, wan bikar bînin û gava ku êdî hewce nebin dayîna drav bidin sekinandin. Wekî din, dê pir baş be ku meriv wan tavilê bi kirina çend klîkên mişkî an bi xebitandina çend senaryoyan tavilê werbigire. Ya ku ewrên gelemperî ji bo vê yekê têne bikar anîn. Ka em li pênaseyê binêrin:
"Ewra gelemperî wekî karûbarên komputerê yên ku ji hêla pêşkêşkerên sêyemîn ve li ser Înterneta gelemperî têne pêşkêş kirin, têne destnîşan kirin, wan ji her kesê ku bixwaze wan bikar bîne an bikire peyda dike. Dibe ku ew belaş bin an li ser daxwazê werin firotin, ku dihêle xerîdar tenê ji bo karanîna ji bo çerxên CPU, hilanîn, an firehiya bandê ya ku ew dixwin bidin.
Ramanek heye ku ewrên gelemperî biha ne. Lê fikra wan a sereke kêmkirina lêçûnên pargîdaniyê ye. Wekî ku berê hate behs kirin, ewrên gelemperî dihêlin hûn li gorî daxwazê çavkaniyan bistînin û tenê ji bo dema ku hûn wan bikar tînin bidin. Di heman demê de, carinan em ji bîr dikin ku karmend meaş distînin, û pispor jî çavkaniyek biha ne. Pêdivî ye ku were hesibandin ku ewrên gelemperî piştgiriya binesaziyê pir hêsantir dike, ku dihêle endezyar li ser karên girîngtir hûr bibin.
Nirx ji bo binesaziya automation
Ji bo ceribandinên UI-ya dawî-bi-dawî ji me re kîjan çavkaniyên taybetî hewce ne? Di bingeh de ev makîneyên virtual an kom in (em ê di beşa pêş de li ser Kubernetes biaxivin) ji bo gerok û emulatoran dimeşînin. Zêdetir gerok û emulatorên ku em dixwazin bi hevdemî bixebitin, CPU û bîranîn bêtir hewce dike û pêdivî ye ku em ji bo wê bêtir drav bidin. Bi vî rengî, ewrên gelemperî di çarçoweya xweseriya ceribandinê de rê didin me ku em hejmareke mezin (100, 200, 1000 ...) gerokên / emulatoran li gorî daxwazê bimeşînin, encamên testê bi lez û bez bistînin û dev ji dayîna berdêla ji bo çavkaniyek wusa bêaqil berdin. erk.
Pêşkêşvanên ewr ên herî populer Karûbarên Webê yên Amazon (AWS), Microsoft Azure, Google Cloud Platform (GCP) ne. Rêbernameya-çawa mînakan dide ka meriv çawa GCP bikar tîne, lê bi gelemperî ne girîng e ku hûn ji bo karên otomasyonê çi bikar tînin. Ew hemî hema hema heman fonksiyonê peyda dikin. Bi gelemperî, ji bo hilbijartina pêşkêşvanek, rêveberî balê dikişîne ser tevahiya binesaziya pargîdanî û hewcedariyên karsaziyê, ku li derveyî çarçoveya vê gotarê ye. Ji bo endezyarên otomasyonê, dê balkêştir be ku karanîna pêşkêşkerên ewr bi karanîna platformên ewr re bi taybetî ji bo armancên ceribandinê, wek Sauce Labs, BrowserStack, BitBar, û hwd. Îcar em jî bikin! Li gorî min, Sauce Labs çandiniya ceribandina ewr a herî navdar e, ji ber vê yekê min ew ji bo berhevdanê bikar anî.
GCP vs Sauce Labs ji bo armancên otomasyonê:
Ka em bifikirin ku em hewce ne ku 8 ceribandinên malperê û 8 testên Android-ê bi hevdemî bimeşînin. Ji bo vê yekê em ê GCP-ê bikar bînin û 2 makîneyên virtual bi Selenoid-ê bimeşînin. Di ya yekem de em ê 8 konteynerên bi gerokan rakin. Di ya duyemîn de 8 konteynerên bi emulatoran hene. Ka em li bihayan binêrin:
Ji bo ku em yek konteynir bi Chrome re bimeşînin, em hewce ne n1-standard-1 trimbêl. Di doza Android-ê de ew ê bibe n1-standard-4 ji bo yek emulatorê. Di rastiyê de, rêgezek maqûltir û erzantir ev e ku meriv nirxên bikarhêner ên taybetî ji bo CPU / Memory destnîşan bike, lê heya niha ev ji bo berhevdana bi Sauce Labs ne girîng e.
Û li vir tarîfên ji bo karanîna Sauce Labs hene:
Ez bawer dikim ku we berê ferq dîtiye, lê ez ê dîsa jî tabloyek bi hesabên ji bo peywira me peyda bikim:
Çavkaniyên pêwîst
Montly
Karên xebatê(8 - 8)
Karên xebatê+ Pêşîgirtin
GCP ji bo Web
n1-standard-1 x 8 = n1-standard-8
$194.18
23 roj * 12h * 0.38 = 104.88 $
23 roj * 12h * 0.08 = 22.08 $
Sauce Labs for Web
testên paralel Cloud8 Virtual
$1.559
-
-
GCP ji bo Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 roj * 12h * 1.52 = 419.52 $
23 roj * 12h * 0.32 = 88.32 $
Sauce Labs ji bo Android
Testên paralel Cloud 8 Device Real
$1.999
-
-
Wekî ku hûn dikarin bibînin, cûdahiya lêçûnê pir mezin e, nemaze heke hûn ceribandinan tenê di heyamek xebata diwanzdeh-saetê de bimeşînin. Lê heke hûn makîneyên pêşdibistanê bikar bînin hûn dikarin lêçûn hîn bêtir kêm bikin. Ew çi ye?
VM-ya pêşîn mînakek e ku hûn dikarin ji mînakên normal bi bihayek pirtir biafirînin û bimeşînin. Lêbelê, Compute Engine dibe ku van mînakan biqedîne (pêşkêş bike) heke ew ji bo karên din gihîştina wan çavkaniyan hewce dike. Mînakên pêşîlêgirtinê kapasîteya motora Compute ya zêde ne, ji ber vê yekê hebûna wan li gorî karanîna diguhere.
Ger sepanên we bi xeletî re tolerans in û dikarin li hember pêşdîtinên mînakî yên mimkun bisekinin, wê hingê mînakên pêşîlêgirtinê dikarin lêçûnên Engine Compute Engine-a we bi girîngî kêm bikin. Mînakî, karên pêvajoyek berhevokê dikarin li ser mînakên pêşîlêgirtinê bixebitin. Ger hin ji wan mînakan di dema pêvajoyê de bi dawî bibin, kar hêdî dibe lê bi tevahî namîne. Mînakên pêşîlêgirtinê bêyî ku bargiraniya xebata zêde li ser mînakên weyên heyî bicîh bikin û bêyî ku hûn ji bo mînakên normal ên zêde bihaya tam bidin we, karên weya pêvajoya berhevokê temam dikin.
Û hîn jî neqediyaye! Di rastiyê de, ez bawer im ku kes 12 demjimêran bêyî navberê ceribandinan nake. Û heke wusa be, wê hingê hûn dikarin bixweber makîneyên virtual gava ku ne hewce ne dest pê bikin û rawestînin. Dema karanîna rastîn dikare rojane 6 demjimêran kêm bibe. Dûv re drav di çarçoveya peywira me de dê ji bo 11 gerokên mehê 8 $ kêm bibe. Ma ev ne ecêb e? Lê digel makîneyên pêşîlêgirtinê divê em baldar bin û ji navber û bêîstiqrariyê re amade bin, her çend ev rewş dikarin di nermalavê de bêne peyda kirin û bi rê ve bibin. Ew hêja ye!
Lê bi tu awayî ez nabêjim 'tu carî zeviyên ceribandina ewr bikar neynin'. Gelek avantajên wan hene. Berî her tiştî, ev ne tenê makîneyek virtual e, lê çareseriyek otomatîkî ya ceribandinê ya bêkêmasî ye ku bi komek fonksiyonên derveyî ve girêdayî ye: gihîştina ji dûr ve, têketin, dîmenên dîmenan, tomarkirina vîdyoyê, gerokên cihêreng û amûrên mobîl ên laşî. Di gelek rewşan de, ev dikare bibe alternatîfek xweşikek bingehîn. Platformên ceribandinê bi taybetî ji bo otomasyona IOS-ê bikêr in, dema ku ewrên gelemperî tenê dikarin pergalên Linux/Windows pêşkêşî bikin. Lê em ê di gotarên jêrîn de li ser iOS biaxivin. Ez pêşniyar dikim ku her gav li rewşê mêze bikin û ji peywiran dest pê bikin: di hin rewşan de karanîna ewrên giştî erzantir û bikêrtir e, û di yên din de platformên ceribandinê bê guman hêjayî dravê xerckirî ne.
Nîşana rewşa heyî ya binesaziyê
Girêdanên ji bo lêgerînê
Amûrên wekhev:
6. Orkestrasyon
Danasîna kurt a teknolojiyê
Mizgîniya min heye - em hema hema li dawiya gotarê ne! Heya nuha, binesaziya meya otomasyona me ji ceribandinên tevn û Android-ê pêk tê, ku em bi GitLab CI re paralel dimeşînin, bi karanîna amûrên çalak-Docker bikar tînin: Tora Selenium û Selenoid. Wekî din, em makîneyên virtual ku bi GCP-ê ve hatine afirandin bikar tînin da ku konteynerên bi gerok û emulatoran re mêvandar bikin. Ji bo kêmkirina lêçûn, em van makîneyên virtual tenê li ser daxwazê dest pê dikin û dema ku ceribandin neyê kirin wan rawestînin. Ma tiştek din heye ku dikare binesaziya me baştir bike? Bersiv erê ye! Bi Kubernetes (K8s) re hevdîtin bikin!
Pêşîn, em binihêrin ka peyvên orkestra, kom û Kubernetes çawa bi hevûdu re têkildar in. Di astek bilind de, orkestrasyon pergalek e ku sepanan saz dike û bi rê ve dibe. Ji bo otomatîkkirina ceribandinê, serîlêdanên weha yên konteynirkirî tora Selenium û Selenoid in. Docker û K8 hevûdu temam dikin. Ya yekem ji bo bicihkirina serîlêdanê, ya duyemîn ji bo orkestrasyonê tê bikar anîn. Di encamê de, K8s komek e. Erka komê ev e ku meriv VM-an wekî Node bikar bîne, ku dihêle hûn di nav yek serverê (kluster) de fonksiyon, bername û karûbarên cihêreng saz bikin. Ger yek ji Nodes têk biçe, dê Nodên din hilbijêrin, ku xebata bênavber a serlêdana me piştrast dike. Digel vê yekê, K8s xwedan fonksiyonek girîng a têkildarî pîvandinê ye, bi saya vê yekê em bixweber li ser bingeha barkirinê û danîna sînorên çavkaniyek çêtirîn werdigirin.
Di rastiyê de, bi destan danasîna Kubernetes ji sifrê ne karekî hindik e. Ez ê lînkek ji rêbernameya navdar "Kubernetes The Hard Way" re bihêlim û heke hûn eleqedar in, hûn dikarin wê pratîk bikin. Lê mixabin, rêbaz û amûrên alternatîf hene. Rêya herî hêsan ev e ku meriv Google Kubernetes Engine (GKE) di GCP-ê de bikar bîne, ku dê bihêle ku hûn di çend klîk de komek amade bistînin. Ez pêşniyar dikim ku vê nêzîkatiyê bikar bînin da ku dest bi fêrbûnê bikin, ji ber ku ew ê bihêle hûn li şûna ku hûn fêr bibin ka pêkhateyên hundurîn bi hevûdu re çawa têne yek kirin, bala xwe bidin fêrbûna ka meriv çawa K8-an ji bo karên xwe bikar tîne.
Nirx ji bo binesaziya automation
Ka em li çend taybetmendiyên girîng ên ku K8s peyda dikin binêrin:
- bicihkirina serîlêdanê: li şûna VM-ê komek pir-girêk bikar tîne;
- pîvana dînamîk: lêçûna çavkaniyên ku tenê li gorî daxwazê têne bikar anîn kêm dike;
- xwe-başkirin: vegerandina otomatîkî ya potan (ku di encamê de konteyneran jî têne nûve kirin);
- danasîna nûvekirin û paşvexistina guhertinan bê dem: nûvekirina amûr, gerok û emulatoran xebata bikarhênerên heyî qut nake
Lê K8 hîn jî ne guleyek zîv e. Ji bo fêmkirina hemî awantaj û sînorkirinên di çarçoweya amûrên ku em li ber çavan digirin (Treka Selenium, Selenoid), em ê bi kurtî li ser avahiya K8-an nîqaş bikin. Cluster du celeb Nod hene: Nodes Master û Karker Nodes. Master Nodes ji biryarên rêveberî, bicihkirin û plansazkirinê berpirsiyar in. Nokên karkeran cihê ku serîlêdan têne meşandin in. Nod di heman demê de hawîrdorek dema xebitandinê ya konteyneran jî vedihewîne. Di doza me de, ev Docker e, ku berpirsiyarê karûbarên konteynerê ye. Lê ji bo nimûne çareseriyên alternatîf jî hene. Girîng e ku meriv fêhm bike ku pîvazkirin an xwe-başkirin rasterast li konteyneran nayê sepandin. Ev bi lêzêdekirin/kêmkirina hejmara potan, ku di encamê de konteyneran vedihewîne (bi gelemperî ji her podek konteynerek, lê li gorî peywirê dibe ku bêtir be) tête bicîh kirin. Hiyerarşiya asta bilind ji girêkên karkeran pêk tê, ku di hundurê wan de qulik hene, di hundurê wan de konteynir têne bilind kirin.
Taybetmendiya pîvandinê serekî ye û dikare hem li ser girêkên di nav girêk-poolek komê de hem jî li ser girêkên di nav girêkekê de were sepandin. 2 cureyên pîvandinê hene ku hem li ser girêk û hem jî li ser piyan têne sepandin. Cûreya yekem horizontî ye - scaling bi zêdekirina hejmara nod/pods pêk tê. Ev celeb bêtir tercîh e. Cûreya duyemîn, li gorî, vertîkal e. Scaling bi zêdekirina qebareya girêkan/podsê, û ne hejmara wan, tê kirin.
Naha em di çarçoveya şertên jorîn de li amûrên xwe binêrin.
Tora Selenium
Wekî ku berê hate behs kirin, tora Selenium amûrek pir populer e, û ne surprîz e ku ew konteynir bûye. Ji ber vê yekê, ne ecêb e ku tora Selenium dikare di K8s de were bicîh kirin. Mînaka meriv çawa vê yekê dikare di depoya fermî ya K8s de were dîtin. Wekî gelemperî, ez di dawiya beşê de zencîreyan girêdidim. Wekî din, rêber-çawa nîşan dide ka meriv çawa vê yekê di Terraform de dike. Di heman demê de rêwerzên li ser ka meriv çawa hejmara podên ku konteynerên gerokê vedihewîne pîvan hene. Lê fonksiyona pîvandina otomatîkî di çarçoweya K8s de hîn jî ne karekî bi tevahî eşkere ye. Dema ku min dest bi xwendinê kir, min tu rêber û pêşniyarek pratîk nedît. Piştî çend lêkolîn û ceribandinên bi piştgiriya tîmê DevOps, me nêzîkatiya bilindkirina konteyneran bi gerokên pêwîst di hundurê yek podê de, ku di hundurê yek girêka karker de ye, hilbijart. Ev rêbaz rê dide me ku em stratejiya pîvankirina horizontî ya girêkan bi zêdekirina hejmara wan bicîh bînin. Ez hêvî dikim ku ev dê di pêşerojê de biguhere û em ê bêtir û bêtir ravekirinên nêzîkatiyên çêtir û çareseriyên amade bibînin, nemaze piştî serbestberdana Selenium grid 4 bi mîmariya navxweyî ya guheztin.
Selenoid:
Rakirina Selenoid di K8s de niha bêhêvîbûna herî mezin e. Ew ne lihevhatî ne. Di teoriyê de, em dikarin konteynirek Selenoid di hundurê podek de rakin, lê gava ku Selenoid dest bi vekirina konteynerên bi gerokan re dike, ew ê hîn jî di hundurê heman podê de bin. Ev yek pîvazkirinê ne mumkun dike û, wekî encam, xebata Selenoid di hundurê komekê de dê ji xebata hundurê makîneyek virtual cûda nebe. Dawiya çîrokê.
Hêv:
Dema ku bi Selenoid re dixebitin vê tengahiyê dizanin, pêşdebiran amûrek bihêztir a bi navê Moon berdan. Ev amûr di destpêkê de hate çêkirin ku bi Kubernetes re bixebite û, wekî encamek, taybetmendiya otoscaling dikare û divê were bikar anîn. Wekî din, ez ê bibêjim ku niha ew e tenê amûrek di cîhana Selenium de, ku xwedan piştgirîya komê ya K8-ya xwecî ye (nema peyda dibe, li amûra paşîn binêre ). Taybetmendiyên sereke yên Moon ku vê piştgiriyê peyda dikin ev in:
Bi tevahî bê dewlet. Selenoid di derheqê danişînên gerokê yên ku niha têne xebitandin de agahdariya bîranînê hilîne. Ger ji ber hin sedeman pêvajoya wê têk diçe - wê hingê hemî danişînên xebitandinê winda dibin. Berevajî Moon xwedan rewşek navxweyî tune û dikare li navendên daneyê were dubare kirin. Danişînên gerokê sax dimînin her çend yek an çend kopiyek dakevin.
Ji ber vê yekê, Moon çareseriyek mezin e, lê pirsgirêkek heye: ew ne belaş e. Biha bi hejmara danişînan ve girêdayî ye. Hûn dikarin tenê 0-4 danişînan belaş bimeşînin, ku bi taybetî ne bikêr e. Lê, ji rûniştina pêncemîn dest pê dike, hûn ê ji bo her yekê 5 $ bidin. Dibe ku rewş ji pargîdaniyek bi pargîdanî cûda bibe, lê di rewşa me de, karanîna Moon bêwate ye. Wekî ku min li jor diyar kir, em dikarin li gorî daxwazê VM-yên bi Grid Selenium bimeşînin an jî hejmara Nodên di komê de zêde bikin. Ji bo hema yek boriyek, em 500 gerokan didin destpêkirin û piştî ku ceribandin qediyan hemî çavkaniyan rawestînin. Ger me Moon bikar anî, me neçar ma ku mehê 500 x 5 = 2500 $ zêde bidin, çu carî em ceribandinan dikin. Dîsa, ez nabêjim Moon bikar neynin. Ji bo peywirên we, ev dikare bibe çareseriyek domdar, mînakî, heke we di rêxistina we de gelek proje / tîm hebin û ji bo her kesî komek hevpar a mezin hewce dike. Mîna her gav, ez di dawiyê de girêdanek dihêlim û pêşniyar dikim ku di çarçoveya peywira we de hemî hesabên pêwîst bikin.
Callisto(Baldarî! Ev ne di gotara orîjînal de ye û tenê di wergera rûsî de heye)
Wekî ku min got, Selenium amûrek pir populer e, û qada IT-ê pir zû pêş dikeve. Dema ku ez li ser wergerê dixebitim, amûrek nû ya sozdar a bi navê Callisto li ser tevneyê xuya bû (silav Cypress û kujerên din ên Selenium). Ew bi K8-ên xwemalî re dixebite û dihêle hûn konteynerên Selenoid-ê di nav potan de, ku li seranserê Nodes têne belav kirin, bimeşînin. Her tişt rast ji qutîkê dixebite, di nav de otoscaling. Fantastîk, lê pêdivî ye ku were ceribandin. Min berê xwe da ku vê amûrê bicîh bikim û gelek ceribandinan bimeşînim. Lê hê zû ye ku meriv encaman derxîne, piştî wergirtina encaman ji dûr ve, dibe ku ez ê di gotarên pêşerojê de vekolînek bikim. Heya nuha ez tenê girêdan ji bo lêkolîna serbixwe dihêlim.
Nîşana rewşa heyî ya binesaziyê
Girêdanên ji bo lêgerînê
Amûrên wekhev
7. Binesaziya wekî Kodê (IaC)
Danasîna kurt a teknolojiyê
Û niha em werin beşa dawî. Bi gelemperî, ev teknolojî û peywirên têkildar ne berpirsiyariya endezyarên otomasyonê ne. Û sedemên vê yekê hene. Ya yekem, di gelek rêxistinan de, pirsgirêkên binesaziyê di bin kontrola beşa DevOps de ne û tîmên pêşkeftinê bi rastî guh nadin ka çi dike ku boriyê bixebite û çawa her tiştê ku pê ve girêdayî ye pêdivî ye ku were piştgirî kirin. Ya duyemîn, em rastdar bin, pratîka Binesaziyê wekî Code (IaC) hîn jî di gelek pargîdaniyan de nayê pejirandin. Lê bê guman ew bûye trendek populer û girîng e ku meriv hewl bide ku di pêvajo, nêzîkatî û amûrên pê re têkildar be. An jî bi kêmanî rojane bimînin.
Ka em bi motîvasyona karanîna vê nêzîkbûnê dest pê bikin. Me berê nîqaş kir ku ji bo ceribandinên li GitlabCI-ê bimeşînin, em ê herî kêm hewceyê çavkaniyan bikin ku Gitlab Runner bimeşînin. Û ji bo ku konteynerên bi gerok/emulatoran bimeşînin, pêdivî ye ku em VM an komek veqetînin. Digel ceribandina çavkaniyan, em hewceyê kapasîteyên girîng in ku piştgirî bidin pêşkeftin, qonax, hawîrdorên hilberînê, ku di heman demê de databas, nexşeyên otomatîk, veavakirina torê, hevsengên barkirinê, mafên bikarhêner, û hwd jî tê de hene. Pirsgirêka sereke hewldana ku ji bo piştgirîkirina hemî hewce ye. Gelek awayên ku em dikarin guhartinan bikin û nûvekirinan derxînin hene. Mînakî, di çarçoveya GCP-ê de, em dikarin konsolê UI-yê di gerokê de bikar bînin û bi tikandina bişkokan hemî çalakiyan pêk bînin. Alternatîfek dê ev be ku hûn bangên API-ê bikar bînin da ku bi saziyên ewr re têkilî daynin, an jî karanîna xeta fermanê ya gcloud bikar bînin da ku manipulasyonên xwestinê bikin. Lê digel hejmareke pir mezin a sazî û hêmanên binesaziyê yên cihêreng, pêkanîna hemî operasyonan bi destan dijwar an jî ne mumkun dibe. Digel vê yekê, hemî van kiryarên destan nayên kontrol kirin. Em nikarin wan berî darvekirinê ji bo vekolînê bişînin, pergalek kontrolkirina guhertoyê bikar bînin, û bi lez guhertinên ku bûne sedema bûyerê paşve bixin. Ji bo çareserkirina pirsgirêkên weha, endezyaran skrîptên bash / şêl ên otomatîkî afirandin û diafirînin, ku ji rêbazên berê ne pir çêtir in, ji ber ku ew qas ne hêsan in ku zû bi zû bixwînin, fêm bikin, biparêzin û bi şêwazek prosedurî veguhezînin.
Di vê gotarê de û rêber-çawa, ez 2 amûrên têkildarî pratîka IaC-ê bikar tînim. Ev Terraform û Ansible ne. Hin kes bawer dikin ku karanîna wan di heman demê de ne wate ye, ji ber ku fonksiyona wan dişibihe û ew guhezbar in. Lê rastî ev e ku di destpêkê de ji wan re karên bi tevahî cûda têne dayîn. Û rastiya ku divê van amûran hevûdu temam bikin di pêşandanek hevbeş de ji hêla pêşdebirên HashiCorp û RedHat ve hatî pejirandin. Cûdahiya têgehî ev e ku Terraform ji bo birêvebirina serveran bixwe amûrek peydakirinê ye. Dema ku Ansible amûrek rêveberiya mîhengê ye ku peywira wê sazkirin, mîhengkirin û birêvebirina nermalava li ser van serveran e.
Taybetmendiyek din a girîng a van amûran şêwaza kodkirinê ye. Berevajî bash û Ansible, Terraform şêwazek daxuyandî li ser bingeha ravekirina rewşa dawiya xwestinê ya ku di encama darvekirinê de bi dest dikeve bikar tîne. Mînakî, heke em ê 10 VM-an biafirînin û bi Terraform-ê guheztinan bicîh bînin, wê hingê em ê 10 VM-an bistînin. Ger em ji nû ve skrîptê bimeşînin, dê tiştek neqewime ji ber ku me berê 10 VM hene, û Terraform bi vê yekê dizane ji ber ku ew rewşa heyî ya binesaziyê di pelek dewletê de hilîne. Lê Ansible nêzîkatiyek pêvajoyê bikar tîne û, heke hûn jê bipirsin ku 10 VM-an biafirîne, wê hingê di destpêka yekem de em ê 10 VM-an, mîna Terraform, bistînin. Lê piştî ji nû ve destpêkirinê em ê berê xwe bidin 20 VM. Cûdahiya girîng ev e. Di şêwaza pêvajoyê de, em rewşa heyî hilnagirin û bi tenê rêzek gavên ku divê bêne kirin diyar dikin. Bê guman, em dikarin rewşên cihêreng bi rê ve bibin, ji bo hebûna çavkaniyan û rewşa heyî hin kontrolan lê zêde bikin, lê ti wateya windakirina dema xwe û hewldana ji bo kontrolkirina vê mantiqê tune ye. Bi ser de, ev xetera kirina xeletiyan zêde dike.
Bi kurtkirina hemî jorîn, em dikarin encam bidin ku Terraform û nîşana daxuyandî ji bo peydakirina serveran amûrek maqûltir e. Lê çêtir e ku meriv karê rêveberiya mîhengê ji Ansible re veguhezîne. Digel vê yekê, bila em di çarçoweya otomasyonê de li dozên karanînê binêrin.
Nirx ji bo binesaziya automation
Tenê tiştek girîng a ku meriv li vir fêm bike ev e ku binesaziya xweseriya testê divê wekî beşek ji binesaziya tevaya pargîdaniyê were hesibandin. Ev tê vê wateyê ku hemî pratîkên IaC divê li seranserê cîhanê li ser çavkaniyên tevahiya rêxistinê werin sepandin. Kî ji vê yekê berpirsiyar e, bi pêvajoyên we ve girêdayî ye. Tîma DevOps di van mijaran de bi tecrûbetir e, ew tevahiya wêneya ku diqewime dibînin. Lêbelê, endezyarên QA bêtir beşdarî pêvajoya otomasyona avahiyê û strukturên lûleyê dibin, ku rê dide wan ku baştir hemî guhertinên pêwîst û derfetên başbûnê bibînin. Vebijarka herî baş ew e ku bi hev re bixebitin, zanyarî û ramanan biguhezînin da ku bigihîjin encama çaverê.
Li vir çend mînakên karanîna Terraform û Ansible di çarçoweya xweseriya ceribandinê de û amûrên ku me berê nîqaş kirin hene:
1. Taybetmendî û pîvanên pêwîst ên VM û koman bi karanîna Terraform vebêjin.
2. Bi karanîna Ansible, amûrên ku ji bo ceribandinê hewce ne saz bikin: docker, Selenoid, Selenium Grid û guhertoyên hewce yên gerok/emulatoran dakêşin.
3. Bi karanîna Terraform, taybetmendiyên VM-ya ku dê GitLab Runner tê de were destpêkirin vebêjin.
4. GitLab Runner û amûrên pêvek ên pêwîst bi karanîna Ansible saz bikin, mîheng û veavakirinan saz bikin.
Nîşana rewşa heyî ya binesaziyê
Girêdanên ji bo lêkolînê:
Amûrên wekhev
Werin em bi kurtî!
Gav
Technology
Amûrên
Nirx ji bo binesaziya automation
1
Rêveçûna herêmî
Node.js, Selenium, Appium
- Amûrên herî populer ên ji bo tevn û mobîl
- Gelek ziman û platforman piştgirî dike (tevî Node.js)
2
pergalên kontrol Versiyon ji
herin
- Feydeyên bi vî rengî bi koda pêşkeftinê re
3
Konteynerkirin
Docker, tora Selenium, Selenoid (Web, Android)
- Di paralel de testan dimeşînin
- Derdorên îzolekirî
- Nûvekirinên guhertoya hêsan, maqûl
- Bi awayekî dînamîkî çavkaniyên bêkaran rawestînin
- Sazkirin hêsan e
4
CI/CD
Gitlab CI
- Beşek boriyê diceribîne
- Feedback Zû
- Dîtin ji bo tevahiya pargîdanî / tîmê
5
platformên Cloud
Platforma Google Cloud
- Çavkaniyên li ser daxwazê (em tenê gava ku hewce be didin)
- Rêvekirin û nûvekirin hêsan e
- Dîtin û kontrolkirina hemî çavkaniyan
6
Orchestration
Kubernetes
Di çarçoweya konteynerên bi gerok/emulatorên di hundurê pods de:
- Scaling / auto scaling
- Xwe dermankirin
- Nûvekirin û bê navber vedigere
7
Binesaziya wekî kodek (IaC)
Terraform, Ansible
- Feydeyên bi vî rengî bi binesaziya pêşkeftinê re
- Hemî feydeyên guhertoya kodê
- Guhertin û parastin hêsan e
- Bi tevahî otomatîk
Diagramên nexşeya hiş: pêşkeftina binesaziyê
gav1: Herêmî
gav2: VCS
gav3: Konteynirkirin
gav4: CI / CD
gav5: Platformên Cloud
gav6: Orkestrasyon
gav7: IaC
Çi ye?
Ji ber vê yekê, ev dawiya gotarê ye. Lê di encamê de ez dixwazim bi we re hin peymanan saz bikim.
Ji milê te
Wekî ku min di destpêkê de got, ez dixwazim gotar bikêrhatî be û ji we re bibe alîkar ku hûn zanyariyên ku di xebata rastîn de hatine bidestxistin bicîh bînin. Ez dîsa lê zêde dikim.
Lê piştî wê jî, nesekinin, pratîk bikin, girêdan û pirtûkên têkildar bixwînin, fêr bibin ka ew di pargîdaniya we de çawa dixebite, cîhên ku dikarin werin çêtir kirin bibînin û beşdarî wê bibin. Bextxweş bî!
Ji aliyê min ve
Ji sernavê diyar e ku ev tenê beşa yekem bû. Digel ku ew pir mezin derketiye holê jî, mijarên girîng hîn jî li vir nehatine girtin. Di beşa duyemîn de, ez plan dikim ku di çarçoweya IOS-ê de binesaziya otomasyonê binihêrim. Ji ber qedexeyên Apple li ser xebitandina simulatorên iOS-ê tenê li ser pergalên macOS-ê, rêza çareseriyên me teng bûne. Mînakî, em nekarin Docker bikar bînin da ku simulator an jî ewrên gelemperî ji bo xebitandina makîneyên virtual bikar bînin. Lê ev nayê wê wateyê ku alternatîfên din tune. Ez ê hewl bidim ku we bi çareseriyên pêşkeftî û amûrên nûjen re nûjen bikim!
Di heman demê de, min behsa mijarên pir mezin ên têkildarî çavdêriyê nekiriye. Di Beşa 3-ê de, ez ê li amûrên çavdêriya binesaziyê yên herî populer binihêrim û çi dane û metrîkên ku li ber çavan bigirin.
Û di dawiyê de. Di pêşerojê de, ez plan dikim ku qursek vîdyoyê li ser avakirina binesaziya ceribandinê û amûrên populer derxim. Heya nuha, li ser Înternetê çend qurs û dersên li ser DevOps hene, lê hemî materyal di çarçoweya pêşkeftinê de têne pêşkêş kirin, ne ku bixweberkirina ceribandinê. Li ser vê mijarê, ez bi rastî hewceyê bersivdayînê ye ka gelo qursek wusa dê ji bo civata ceribandin û endezyarên otomasyonê balkêş û hêja be. Pêşî spas!
Source: www.habr.com