Silav Habr! Berê, min ji jiyana li Binesaziyê wekî paradîgmaya kod gilî kir û ji bo çareserkirina rewşa heyî tiştek pêşkêş nekir. Îro ez vegerim ku ji we re vebêjim ka kîjan nêzîkatî û pratîk dê ji we re bibe alîkar ku hûn ji binemaya bêhêvîtiyê birevin û rewşê ber bi riya rast ve bişopînin.
Di gotara berê de Min nerînên xwe yên li ser vê deverê parve kir, min hewl da ku li ser rewşa heyî ya li vê deverê ronî bikim, û tewra pêşniyar kir ku pratîkên standard ên ku ji hemî pêşdebiran re têne zanîn dikarin bibin alîkar. Dibe ku dixuye ku li ser jiyanê gelek gilî hebûn, lê ji bo rêyek ji rewşa heyî pêşniyar nehatin.
Em kî ne, li ku ne û çi pirsgirêkên me hene
Em niha di Tîma Sre Onboarding de ne, ku ji şeş bernamenûs û sê endezyarên binesaziyê pêk tê. Em hemî hewl didin ku Binesaziyê wekî kod (IaC) binivîsin. Em vê yekê dikin ji ber ku em bi bingehîn dizanin ka meriv çawa kodê dinivîse û xwedan dîrokek pêşdebirên "ji navînî" ye.
- Komek avantajên me hene: paşxaneyek, zanîna pratîkan, şiyana nivîsandina kodê, xwestek fêrbûna tiştên nû.
- Û beşek gemarî heye, ku ew jî kêmasiyek e: nebûna zanînê di derbarê hardware binesaziyê de.
Pişka teknolojiyê ya ku em di IaC-ya xwe de bikar tînin.
- Terraform ji bo afirandina çavkaniyan.
- Paker ji bo komkirina wêneyan. Ev wêneyên Windows, CentOS 7 ne.
- Jsonnet ku di drone.io de avahiyek bi hêz çêbike, û hem jî ji bo hilberîna json pakker û modulên me yên terraform.
- Azure.
- Di dema amadekirina wêneyan de dibe alîkar.
- Python ji bo karûbarên alîkar û dabînkirina nivîsarên.
- Û ev hemî di VSCode de bi pêvekên ku di navbera endamên tîmê de têne parve kirin.
Encam ji min bi vî rengî bû: Min hewl da ku (berî her tiştî) xweşbîniyê bihêlim, min xwest bibêjim ku em ê nêzîkatî û pratîkên ku me nas dikin biceribînin da ku bi zehmetî û tevliheviyên ku di vî warî de hene re mijûl bibin.
Em niha bi pirsgirêkên IaC yên jêrîn re têkoşîn dikin:
- Kêmasiya amûr û amûrên ji bo pêşkeftina kodê.
- Daxistina hêdî. Binesaziyê beşek ji cîhana rastîn e, û ew dikare hêdî be.
- Nebûna nêzîkatî û pratîkan.
- Em nû ne û pir nizanin.
Programming Extreme (XP) ji bo rizgarkirinê
Hemî pêşdebiran bi Bernameya Extreme (XP) û pratîkên ku li pişt wê radiwestin nas dikin. Gelek ji me bi vê rêbazê xebitîn, û ew serkeftî bû. Ji ber vê yekê çima prensîb û pratîkên ku li wir hatine danîn bikar neynin da ku li ser pirsgirêkên binesaziyê derbas bibin? Me biryar da ku em vê nêzîkbûnê bigirin û bibînin ka çi dibe.
Kontrolkirina sepandina nêzîkatiya XP li ser pîşesaziya weLi vir ravekek hawîrdora ku XP jê re xweş e, û ew çawa bi me re têkildar e:
1. Pêdiviyên nermalava dînamîkî diguherin. Ji me re diyar bû ku armanca dawî çi ye. Lê hûrgulî dikarin cûda bibin. Em bi xwe biryar didin ku em li ku derê taksiyê hewce dikin, ji ber vê yekê hewcedarî bi periyodîk diguhezin (bi taybetî bi xwe). Ger em tîmê SRE-yê bigirin, ku bixwe otomatîkê dike, û bixwe hewcedarî û qada xebatê sînordar dike, wê hingê ev xal baş li hev tê.
2. Rîskên ku ji ber projeyên dema sabît ên ku teknolojiya nû bikar tînin. Dema ku hin tiştên ku ji me re nenas bi kar tînin dibe ku em bi xetereyan re rû bi rû bimînin. Û ev 100% doza me ye. Tevahiya projeya me karanîna teknolojiyên ku em bi tevahî nas nedikirin bû. Bi gelemperî, ev pirsgirêkek berdewam e, ji ber ku ... Di sektora binesaziyê de her dem gelek teknolojiyên nû derdikevin holê.
3,4. Tîma pêşkeftina dirêjkirî ya piçûk, hevgirtî. Teknolojiya otomatîkî ya ku hûn bikar tînin destûrê dide ceribandinên yekîn û fonksiyonel. Ev her du xal ne li gorî me ne. Ya yekem, em ne tîmek hevrêz in, ya duyemîn jî, em neh kes in, ku dikarin wekî tîmek mezin bêne hesibandin. Her çend, li gorî hin pênaseyên tîmek "mezin", pir 14+ kes in.
Ka em li hin pratîkên XP-ê binihêrin û ka ew çawa bandorê li lez û kalîteya bersivê dikin.
Prensîba XP Feedback Loop
Di têgihîştina min de, bersiv bersiva pirsê ye, gelo ez tiştê rast dikim, gelo em diçin wir? XP ji bo vê yekê nexşeyek xwedayî heye: çerxek paşvegera demê. Tişta balkêş ev e ku em her ku kêmtir bin, em zûtir dikarin OS-ê bigihînin ku bersiva pirsên pêwîst bide.
Ev ji bo nîqaşê mijarek balkêş e, ku di pîşesaziya meya IT-ê de gengaz e ku meriv zû OS-yê bi dest bixe. Bifikirin ka çiqas bi êş e ku meriv şeş mehan projeyek bike û tenê hingê fêr bibe ku di destpêkê de xeletiyek hebû. Ev di sêwiranê de û di her avakirina pergalên tevlihev de dibe.
Di doza me ya IaC de, bersiv ji me re dibe alîkar. Ez ê tavilê verastkirinek piçûk li diyagrama li jor bikim: pilana berdanê çerxa mehane nîne, lê rojê çend caran pêk tê. Bi vê çerxa OS-ê re hin pratîk hene ku em ê bi hûrgulî lê binêrin.
Girîng: bersiv dikare ji bo hemî pirsgirêkên ku li jor hatine destnîşan kirin çareseriyek be. Bi pratîkên XP-ê re, ew dikare we ji bêhêvîtiyê derxe.
Meriv çawa xwe ji bêhêvîtiyê derdixe: sê pratîk
Testsên
Ceribandin du caran di lûleya berteka XP de têne gotin. Ne tenê wisa ye. Ew ji bo tevahiya teknîka Bernamekirina Extreme pir girîng in.
Tê texmîn kirin ku we ceribandinên Yekbûn û Pejirandinê hene. Hin di çend hûrdeman de, yên din jî di çend rojan de bertek didin we, ji ber vê yekê nivîsandina wan dirêjtir digire û kêm caran têne vekolandin.
Piramîdek ceribandina klasîk heye, ku nîşan dide ku divê bêtir ceribandin hebin.
Di projeyek IaC de ev çarçove çawa ji me re derbas dibe? Bi rastî... qet nebe.
- Testên yekîneyê, tevî vê rastiyê ku divê pir ji wan hebin jî, nikarin pir zêde bin. An jî ew tiştekî pir nerasterast diceribînin. Bi rastî em dikarin bibêjin ku em wan qet nanivîsin. Lê li vir çend serîlêdanên ji bo ceribandinên weha hene ku me karîbû bikin:
- Testkirina koda jsonnet. Mînakî, ev xeta meclîsa drona me ye, ku pir tevlihev e. Koda jsonnet ji hêla ceribandinan ve baş tê vegirtin.
Em vê bikar tînin . - Testên ji bo nivîsarên ku dema çavkanî dest pê dike têne darve kirin. Skrîpt bi Python têne nivîsandin, û ji ber vê yekê ceribandin dikarin li ser wan bêne nivîsandin.
- Testkirina koda jsonnet. Mînakî, ev xeta meclîsa drona me ye, ku pir tevlihev e. Koda jsonnet ji hêla ceribandinan ve baş tê vegirtin.
- Potansiyel gengaz e ku meriv di ceribandinan de veavakirinê kontrol bike, lê em wiya nakin. Di heman demê de gengaz e ku meriv qaîdeyên veavakirina çavkaniyê bi rê ve were mîheng kirin . Lêbelê, kontrolên li wir tenê ji bo terraform pir bingehîn in, lê gelek nivîsarên testê ji bo AWS têne nivîsandin. Û em li ser Azure ne, ji ber vê yekê ev dîsa derbas nabe.
- Testên entegrasyonê yên pêkhateyan: ew girêdayî ye ka hûn wan çawa dabeş dikin û hûn wan li ku derê danîne. Lê ew bi bingehîn dixebitin.
Testên entegrasyonê bi vî rengî xuya dikin.
Dema ku di Drone CI de wêneyan çêdikin ev mînakek e. Ji bo ku hûn bigihîjin wan, divê hûn 30 hûrdem bisekinin ku wêneyê Packer çêbibe, paşê 15 hûrdemên din li benda derbasbûna wan bisekinin. Lê ew hene!Algorîtmaya verastkirina wêneyê
- Packer divê pêşî wêneyê bi tevahî amade bike.
- Li tenişta ceribandinê terraformek bi dewletek herêmî heye, ku em bikar tînin da ku vê wêneyê bicîh bikin.
- Dema ku vedibe, modulek piçûk a ku li nêzê ye tê bikar anîn da ku hêsantir bi wêneyê re bixebite.
- Dema ku VM ji wêneyê were saz kirin, kontrol dikarin dest pê bikin. Di bingeh de, kontrol bi otomobîlan têne kirin. Ew kontrol dike ka nivîsar di destpêkê de çawa xebitî û şeytan çawa dixebitin. Ji bo vê yekê, bi ssh an winrm-ê em têkevin makîneya ku ji nû ve hatî hildan û statûya veavakirinê an nebûna karûbaran kontrol bikin.
- Rewş bi testên entegrasyonê yên di modulên ji bo terraformê de wekhev e. Li vir tabloyek kurt heye ku taybetmendiyên ceribandinên weha vedibêje.
Bersiva li ser boriyê li dora 40 hûrdem e. Her tişt ji bo demek pir dirêj dibe. Ew dikare ji bo paşveçûnê were bikar anîn, lê ji bo pêşveçûna nû bi gelemperî nerealîst e. Heke hûn ji bo vê yekê pir, pir amade ne, nivîsarên xebitandinê amade bikin, wê hingê hûn dikarin wê 10 hûrdem kêm bikin. Lê ev hîn jî ne ceribandinên Yekîneyê ne, ku di 5 çirkeyan de 100 perçeyan dikin.
Nebûna ceribandinên Yekîneyê dema berhevkirina wêneyan an modulên terraformê teşwîq dike veguheztina kar ber bi karûbarên veqetandî yên ku bi hêsanî bi REST-ê, an bi tîpên Python-ê ve werin xebitandin.
Mînakî, me hewce kir ku em pê ewle bin ku gava makîneya virtual dest pê dike, ew xwe di karûbarê de tomar dike , û dema ku makîneya virtual hate hilweşandin, ew xwe jêbirin.
Ji ber ku me ScaleFT wekî karûbar heye, em neçar in ku bi navgîniya API-yê pê re bixebitin. Li wir palpiştek hatibû nivîsandin ku tu dikarî bikişînî û bibêjî: "Here hundur û vî û wî jê bike." Ew hemî mîheng û gihîştinên pêwîst hilîne.
Em jixwe dikarin ji bo vê ceribandinên normal binivîsin, ji ber ku ew ji nermalava asayî ne cûda ye: celebek apiha tê kenandin, hûn wê bikişînin, û bibînin ka çi diqewime.
Encamên ceribandinan: Testkirina yekîneyê, ku divê OS-ê di deqîqeyek de bide, wê nade. Û celebên ceribandina bilindtirîn di pîramîdê de bi bandor in, lê tenê beşek pirsgirêkan vedigirin.
Bernamekirina cot
Test, bê guman, baş in. Hûn dikarin gelek ji wan binivîsin, ew dikarin celebên cûda bin. Ew ê di astên xwe de bixebitin û bertekên xwe bidin me. Lê pirsgirêka ceribandinên Unitê yên xirab, ku OS-ya herî bilez dide, dimîne. Di heman demê de, ez hîn jî OS-ya bilez dixwazim ku karkirina pê re hêsan û xweş e. Ne ku behsa kalîteya çareseriya encam bikin. Bi bextewarî, teknîk hene ku dikarin ji ceribandinên yekîneyê jî bertekek zûtir peyda bikin. Ev bernamekirina cot e.
Dema ku kodê dinivîsin, hûn dixwazin bi zûtirîn dem li ser qalîteya wê bertek bistînin. Erê, hûn dikarin her tiştî di şaxek taybetmendiyê de binivîsin (da ku hûn tiştek ji kesî re neşikînin), li Github daxwazek kişandinê bikin, wê ji kesê ku ramana wî giran e destnîşan bikin û li benda bersivê bisekinin.
Lê hûn dikarin demek dirêj bisekinin. Mirov hemî mijûl in, û bersiv, heke hebe jî, dibe ku ne ji kalîteya herî bilind be. Bifikirin ku bersiv tavilê hat, vekoler tavilê tevahî ramanê fêm kir, lê bersiv dîsa jî dereng tê, piştî rastiyê. Xwezî ew berê bûya. Ya ku bernameya cotê armanc dike ev e - di cih de, di dema nivîsandinê de.
Li jêr şêwazên bernamekirinê yên cot û sepandina wan di xebata li ser IaC de hene:
1. Klasîk, Serpêhatî+Tecrube, bi demjimêrê veguherî. Du rol - ajoker û navîgator. Du kes. Ew li ser heman kodê dixebitin û piştî demek diyarkirî ya diyarkirî rola xwe diguhezînin.
Ka em lihevhatina pirsgirêkên xwe bi şêwazê re bifikirin:
- Pirsgirêk: bêkêmasî ya amûr û amûrên ji bo pêşveçûna kodê.
Bandora neyînî: pêşveçûyîna wê demek dirêj digire, em hêdî dibin, leza / rîtma xebatê winda dibe.
Em çawa şer dikin: em amûrek cûda, IDE-yek hevpar bikar tînin û di heman demê de kurtebiran jî fêr dibin. - Pirsgirêk: Dabeşkirina hêdî.
Bandora neyînî: dema ku ji bo afirandina perçeyek xebatê ya kodê hewce dike zêde dike. Dema ku em li bendê ne bêzar dibin, dema ku em li bendê ne, destên me dirêj dibin da ku tiştek din bikin.
Em çawa şer dikin: me ew bi ser nexist. - Pirsgirêk: nebûna nêzîkatî û pratîkan.
Bandora negatîf: zanibe ka meriv wê çawa baş bike û meriv çawa meriv wê xirab bike tune. Wergirtina bertekan dirêj dike.
Em çawa şer dikin: di xebata cotan de pevguhertina raman û pratîkan hema hema pirsgirêkê çareser dike.
Pirsgirêka sereke ya karanîna vê şêwazê di IaC-ê de leza nehevseng a xebatê ye. Di pêşkeftina nermalava kevneşopî de, we tevgerek pir yekgirtî heye. Hûn dikarin pênc deqeyan derbas bikin û binivîsin N. 10 deqîqeyan derbas bikin û 2N binivîsin, 15 deqîqeyan - 3N. Li vir hûn dikarin pênc deqeyan derbas bikin û N binivîsin, û dûv re 30 hûrdemên din derbas bikin û dehyek N binivîsin. Li vir hûn tiştek nizanin, hûn asê mane, ehmeq. Lêpirsîn dem digire û xwe ji bernamekirinê dûr dixe.
Encam: di forma xwe ya paqij de ji me re ne guncaw e.
2. Ping-pong. Ev nêzîkatî tê de ye ku kesek testê dinivîse û yekî din ji bo wê bicîhkirinê dike. Ji ber vê rastiyê ku her tişt bi ceribandinên Unit re tevlihev e, û hûn neçar in ku ceribandinek entegrasyonê ya ku ji bo bernamekirinê demek dirêj digire binivîsin, hemî hêsaniya ping-pong ji holê radibe.
Ez dikarim bibêjim ku me hewl da ku ji bo sêwirana skrîptek ceribandinê berpirsiyariyan veqetînin û ji bo wê kodê bicîh bikin. Yek ji beşdaran bi senaryoyê hat, di vê beşa xebatê de ew berpirsiyar bû, gotina dawî wî anî ziman. Û yê din jî berpirsiyarê bicihkirinê bû. Ew baş xebitî. Kalîteya senaryoyê bi vê nêzîkbûnê zêde dibe.
Encam: mixabin, leza xebatê rê nade ku ping-pong wekî pratîkek bernamesaziya cotê di IaC de were bikar anîn.
3.Strong Style. . Fikir ev e ku yek beşdar bibe navîgatorê rêwerzan, û ya duyemîn jî rola ajokerê darvekirinê digire. Di vê rewşê de, mafê biryargirtinê tenê bi navîgator re dimîne. Ajokar tenê çap dike û dikare bandorê li tiştê ku bi peyvekê diqewime bike. Rol ji bo demeke dirêj nayê guhertin.
Ji bo fêrbûnê baş e, lê jêhatîbûnên nerm ên xurt hewce dike. Li vê derê em şikestin. Teknîk zehmet bû. Û ev jî ne li ser binesaziyê ye.
Encam: ew bi potansiyel dikare were bikar anîn, em dev ji hewldanê bernadin.
4. Mobbing, swarming û hemî şêwazên naskirî lê ne navnîşkirî Em wê nahesibînin, ji ber ku Me hewl nedaye û ne mimkûn e ku em di çarçoveya xebata xwe de behsa wê bikin.
Encamên gelemperî li ser karanîna bernamekirina cot:
- Xebatek me ya neyeksan heye, ku tevlihev e.
- Em ketin nav jêhatîbûnên nerm ên têra xwe baş. Û qada mijarê jî ji bo derbaskirina van kêmasiyên me alîkarî nake.
- Testên dirêj û pirsgirêkên bi amûran re pêşkeftina cotê dijwar dike.
5. Tevî vê yekê jî serketin hebûn. Me bi rêbaza xwe ya "Civak - Cûdahî" vekir. Ez ê bi kurtasî diyar bikim ka ew çawa dixebite.
Ji bo çend rojan (kêmtir ji hefteyekê) hevkarên me yên daîmî hene. Em bi hev re karekî dikin. Em demekê bi hev re rûdinin: yek dinivîse, yê din rûniştiye û li koma piştgiriyê temaşe dike. Dûv re em demekê belav dibin, her yek hin tiştên serbixwe dike, paşê em dîsa têne cem hev, pir zû hevdem dikin, bi hev re tiştekî dikin û dîsa belav dibin.
Plankirin û ragihandinê
Bloka paşîn a pratîkên ku bi navgîniya pirsgirêkên OS-ê têne çareser kirin organîzekirina xebata bi peywiran bixwe ye. Ev di heman demê de pevguhertina ezmûna ku li derveyî xebata cotan e jî dihewîne. Ka em li sê pratîkan binêrin:
1. Armanc bi riya dara armancê. Me rêveberiya giştî ya projeyê bi darek ku bêdawî ber bi pêşerojê ve diçe organîze kir. Ji aliyê teknîkî ve şopandin li Mîro tê kirin. Karek yek heye - ew armancek navîn e. Ji wê an armancên piçûktir an jî komên peywiran diçin. Kar bi xwe ji wan tê. Hemî peywir li ser vê panelê têne afirandin û domandin.
Ev nexşe di heman demê de bertekek peyda dike, ku rojê carekê dema ku em di mîtîngan de hevdem dikin. Hebûna plansaziyek hevbeş li pêşberî her kesî, lê birêkûpêk û bi tevahî vekirî, dihêle ku her kes hay ji tiştên ku diqewime û em çiqas pêşde çûne.
Avantajên dîtina dîtbarî ya peywiran:
- Causality. Her kar berbi hin armancek gerdûnî ve dibe. Karûbar di nav armancên piçûk de têne kom kirin. Domana binesaziyê bi xwe pir teknîkî ye. Her gav tavilê ne diyar e ka çi bandorek taybetî heye, mînakî, nivîsandina pirtûkek li ser koçkirina nginxek din li ser karsaziyê heye. Hebûna qerta armancê li nêzê wê zelaltir dike.
Sedemî taybetmendiyek girîng a pirsgirêkan e. Ew rasterast bersiva pirsê dide: "Gelo ez tiştê rast dikim?" - Paralelîzm. Em neh kes in, û bi fizîkî ne gengaz e ku meriv her kesî bavêje ser yek peywirê. Dibe ku peywirên ji yek deverê her gav têrê nekin jî. Em neçar in ku xebatên di navbera komên piçûk ên xebatê de paralel bikin. Di heman demê de, kom ji bo demekê li ser karê xwe rûniştin, ew dikarin ji hêla kesek din ve bêne xurt kirin. Carinan mirov ji vê koma xebatê dûr dikevin. Kesek diçe betlaneyê, kesek ji bo conf DevOps raporek çêdike, kesek li ser Habr gotarek dinivîse. Fêrbûna kîjan armanc û karan dikarin bi hev re bêne kirin pir girîng dibe.
2. Pêşkêşkerên cîgir yên civînên sibê. Di stand-upên me de ev pirsgirêk heye - mirov gelek karan bi paralelî dikin. Carinan peywir bi hev ve girêdayî ne û têgihîştinek tune ku kî çi dike. Û nêrîna endamê tîmê din pir girîng e. Ev agahdariya zêde ye ku dikare qursa çareserkirina pirsgirêkê biguhezîne. Bê guman, bi gelemperî kesek bi we re heye, lê şîret û şîret her gav bikêr in.
Ji bo başkirina vê rewşê, me teknîka "Guhertina Serkêşiya Stand-Up" bikar anî. Naha ew li gorî navnîşek diyar têne zivirandin, û ev bandora xwe heye. Gava ku dora we ye, hûn neçar in ku bikevin hundur û fêm bikin ka çi diqewime da ku hûn civînek Scrum baş bimeşînin.
3. Demo navxweyî. Alîkariya di çareserkirina pirsgirêkê de ji bernamesaziya cotê, dîtbarîkirina li ser dara pirsgirêkê û arîkariya di civînên scrum ên sibehê de baş in, lê ne îdeal in. Wekî cotek, hûn tenê bi zanîna xwe sînordar in. Dara peywirê arîkariya gerdûnî dike ku fêm bikin ka kî çi dike. Û pêşkêşvan û hevkarên di civîna sibehê de dê di pirsgirêkên we de kûr nebin. Ew bê guman dibe ku tiştek winda bikin.
Çareserî di nîşandana xebatên ku ji hev re hatine kirin û piştre nîqaşkirina wê de hat dîtin. Em hefteyê carekê ji bo saetekê dicivin û hûrguliyên çareseriyên karên ku me di hefteya borî de kirine nîşan didin.
Di dema xwenîşandanê de, pêdivî ye ku hûrguliyên peywirê werin eşkere kirin û bê guman xebata wê were nîşandan.
Rapor dikare bi karanîna navnîşek kontrolê were çêkirin.1. Bikevin nav çarçoweyê. Erk ji ku hat, çima hewce bû?
2. Berê çawa pirsgirêk çareser bû? Mînakî, klîkek girseyî ya mişkî hewce bû, an jî ne gengaz bû ku tiştek were kirin.
3. Em çawa wê çêtir bikin. Mînakî: "Binerin, niha scriptosik heye, li vir readme ye."
4. Nîşan bide ka ew çawa dixebite. Tête pêşniyar kirin ku rasterast hin senaryoya bikarhêner bicîh bikin. Ez X dixwazim, ez Y dikim, Y (an Z) dibînim. Mînakî, ez NGINX-ê bicîh dikim, url-ê dikêşim, û 200 OK distînim. Heke kiryar dirêj e, wê di pêş de amade bikin da ku hûn paşê wê nîşan bidin. Tête pêşniyar kirin ku meriv saetek beriya demoyê pir zêde neşikîne, heke ew zirav be.
5. Vebêjin ka pirsgirêk çiqas bi serketî hate çareser kirin, çi zehmetî mane, çi neqede, di pêşerojê de çi çêtirkirin gengaz in. Mînakî, naha CLI, wê hingê dê di CI-ê de otomasyona tevahî hebe.
Ji bo her axaftvanek tê pêşniyar kirin ku ew 5-10 hûrdem bimîne. Ger axaftina we eşkere girîng e û dê demek dirêj dirêj bike, di kanala sre-takeover de pêşwext li ser vê yekê li hev bikin.
Piştî beşa rû-bi-rû her tim di mijarê de nîqaş tê kirin. Li vir bertekên ku em li ser karên me hewce ne xuya dikin.
Wekî encamek, anketek tête kirin ku bikêrhatîbûna tiştê ku diqewime were destnîşankirin. Ev bertek li ser esasê axaftinê û girîngiya peywirê ye.
Encamên dirêj û paşê çi ye
Dibe ku xuya bibe ku dengê gotarê hinekî reşbîn e. Ev xelet e. Du astên jêrîn ên bersivê, ango ceribandin û bernamekirina cotê, dixebitin. Ne bi qasî pêşkeftina kevneşopî ye, lê bandorek erênî jê heye.
Tests, di forma xweya heyî de, tenê vegirtina kodê ya qismî peyda dikin. Gelek fonksiyonên vesazkirinê neceribandin diqedin. Dema nivîsandina kodê bandora wan li ser xebata rastîn kêm e. Lêbelê, bandorek ji ceribandinên entegrasyonê heye, û ew dihêlin ku hûn bê tirs refaktoran pêk bînin. Ev serkeftinek mezin e. Di heman demê de, bi guheztina balê li pêşkeftina di zimanên asta bilind de (me python heye, go), pirsgirêk ji holê radibe. Û hûn ji bo "leşker"ê ne hewceyî gelek kontrolan in; kontrolek entegrasyonê ya gelemperî bes e.
Karkirina bi cotan bêtir bi mirovên taybetî ve girêdayî ye. Faktora peywirê û jêhatîbûna me ya nerm heye. Bi hin kesan re ew pir baş dixebite, bi hin kesan re xirabtir dibe. Bê guman feydeyên vê yekê hene. Eşkere ye ku her çend rêgezên xebata cot bi têra xwe neyên dîtin jî, rastiya pêkanîna karan bi hev re bandorek erênî li ser kalîteya encamê dike. Bi kesane, ez xebata bi cotan hêsantir û xweştir dibînim.
Rêbazên asta bilind ên bandorkirina OS - plansazkirin û xebata bi peywiran re bi rastî bandoran çêdike: pevguherîna zanîna kalîteya bilind û kalîteya pêşkeftinê ya çêtir.
Encamên kurt di yek rêzê de
- Bijîjkên HR di IaC de dixebitin, lê bi karîgeriyek kêmtir.
- Ya ku dixebite xurt bikin.
- Bi mekanîzma û pratîkên xwe yên tezmînatê re werin.
Source: www.habr.com