ProHoster > Blog > Administrim > Infrastruktura si Kod: si si gali te zgjidhni problemet me XP

Infrastruktura si Kod: si si gali te zgjidhni problemet me XP

Përshëndetje, Habr! Më parë ankoja mbi jetën në paradigmen e Infrastrukturës si Kod dhe nuk ofroja asnjë zgjidhje për situatën e krijuar. Sot kam rikthyer për t'ju treguar se cilat qasje dhe praktika mund t'i bëjnë të largoheni nga humbja e shpresës dhe të rregulloni situatën drejt rrugës së duhur.

Infrastruktura si Kod: si si gali te zgjidhni problemet me XP

Në artikullin e mëparshëm «Infrastruktura si kod: njohje e parë» ndaja përshtypjet e mia për këtë fushë, përpiqesha të reflektoja mbi situatën aktuale në këtë fushë dhe madje të supozova se praktikat e njohura, të njohura për të gjithë zhvilluesit, mund të ndihmojnë. Mund të ketë dukur se kishte shumë ankesa për jetën, por nuk kishte propozime për zgjidhjen e situatës.

Kush jemi, ku jemi dhe cilat janë problemet tona

Tani jemi në Sre Onboarding Team, që përbëhet nga gjashtë programues dhe tre inxhinierë infrastrukture. Të gjithë ne përpiqemi të shkruajmë Infrastrukturë si Kod (IaC). E bëjmë këtë sepse, në thelb, dimë të shkruajmë kod dhe kemi një histori si zhvillues më të avancuar.

  • Kemi njĂ« grup pĂ«rparĂ«sish: njĂ« pĂ«rvojĂ« tĂ« caktuar, njohuri praktike, aftĂ«si nĂ« kodim, dĂ«shirĂ« pĂ«r tĂ« mĂ«suar tĂ« reja.
  • Dhe kemi njĂ« pjesĂ« qĂ« tĂ«rhiqet mbrapa, qĂ« Ă«shtĂ« njĂ« minus: mungesa e njohurive pĂ«r materien e infrastrukturĂ«s.

Grupi i teknologjive që përdorim në IaC tonë.

  • Terraform pĂ«r tĂ« krijuar burime.
  • Packer pĂ«r ndĂ«rtimin e imazheve. KĂ«to janĂ« imazhe Windows dhe CentOS 7.
  • Jsonnet, pĂ«r tĂ« krijuar njĂ« ndĂ«rtim tĂ« fuqishĂ«m nĂ« drone.io, si dhe pĂ«r gjenerimin e packer json dhe moduleve tĂ« terraformit tanĂ«.
  • Azure.
  • Ansible gjatĂ« pĂ«rgatitjes sĂ« imazheve.
  • Python pĂ«r shĂ«rbime ndihmĂ«se dhe gjithashtu pĂ«r skriptet e provisioning.
  • Dhe gjithçka kjo nĂ« VSCode me shtesa tĂ« ndara midis pjesĂ«tarĂ«ve tĂ« ekipit.

Përfundimi nga artikulli im të mëparshëm ishte ky: kam përpiquar të transmetoj (së pari në veten time) optimizëm, doja të thosha se do të provojmë qasjet dhe praktikat që na janë të njohura për të luftuar me vështirësitë dhe sfidat që ekzistojnë në këtë fushë.

Tani po luftojmë me këto probleme të IaC:

  • PĂ«rkryerja e veglave, mjeteve pĂ«r zhvillimin e kodit.
  • NdĂ«rtime tĂ« ngadalta. Infrastruktura Ă«shtĂ« njĂ« pjesĂ« e botĂ«s reale, dhe ajo mund tĂ« jetĂ« e ngadaltĂ«.
  • Mungesa e qasjeve dhe praktikave.
  • Jemi tĂ« rinj dhe nuk dimĂ« shumĂ«.

Programimi ekstrem (XP) nxiton për ndihmë

Të gjithë zhvilluesit e njohin mirë programimin ekstreme (XP) dhe praktikat që e mbështesin atë. Shumë prej nesh kanë punuar sipas këtij qasjeje, dhe ka qenë e suksesshme. Pse mos të shfrytëzojmë parimet dhe praktikat e vendosura aty për të përballuar vështirësitë e infrastrukturës? Ne vendosëm të zbatonim këtë qasje dhe të shohim se çfarë do të dalë prej saj.

Kontrolli i aplikueshmërisë së qasjes XP në fushën tuajJa përshkrimi i mjedisit për të cilin XP përshtatet mirë dhe si lidhet kjo me ne:

1. Kërkesat e softuerit që ndryshojnë dinamikisht. Na ishte e qartë se cila ishte qëllimi përfundimtar. Por në detaje mund të kemi variacione. Ne vetë vendosim se ku duam të shkojmë, prandaj kërkesat ndryshojnë herë pas here (kryesisht nga ne vetë). Nëse marrim ekipin SRE, i cili automatikisht bën automatizimin dhe vetë kufizon kërkesat dhe përmbajtjen e punëve, ky pikë është i përshtatshëm.

2. Rreziqet e shkaktuara nga projektet me kohë të fixuar duke përdorur teknologji të reja. Ne mund të hasim rreziqe kur përdorim gjëra që nuk i njohim. Dhe ky është rasti ynë 100%. Të gjithë projekti ynë është përdorimi i teknologjive me të cilat nuk ishim plotësisht të njohur. Për më tepër, kjo është një problem në vazhdimësi, sepse në fushën e infrastrukturës vazhdimisht po shfaqen teknologji të reja.

3,4. Ekip i vogël, i vendosur së bashku. Teknologjia që po përdorni lejon teste automatike unitare dhe funksionale. Këta dy pikë nuk na përshtaten plotësisht. Së pari, ne nuk jemi një ekip i vendosur, së dyti, kemi nëntë persona, që mund të konsiderohet një ekip i madh. Megjithatë, sipas disa definicionëve të ekipit "të madh", shumë do të ishte 14+ persona.

Le të shqyrtojmë disa praktika nga XP dhe si ato ndikojnë në shbrirjen dhe cilësinë e feedback-ut.

Parimi i ciklit të feedback-ut në XP

Në mendimin tim, feedback-u është përgjigja ndaj pyetjes, a po e bëj drejt, a po shkojmë drejt? Në XP ka një diagram hyjnor për këtë: cikli i feedback-ut në kohë. Interesant është se sa më poshtë jemi, aq më shpejt kemi mundësi të marrim OS, për të përgjigjur pyetjeve të nevojshme.

Infrastruktura si Kod: si si gali te zgjidhni problemet me XP

Kjo është një temë mjaft interesante për t'u diskutuar, se në industri dhe IT është e mundur të merrni shpejt OS. Imagjinoni sa e vështirë është të realizoni një projekt për gjashtë muaj dhe pastaj të kuptoni se në fillim është bërë një gabim. Kjo ndodh jo vetëm në projektim, por në çdo ndërtim të sistemeve të komplikuara.

Në rastin tonë, IaC na ndihmon me feedback-un. Menjëherë bëj një rregullim të vogël në skemën e mësipërme: plani i lëshimit nuk është një cikël mujor, por ndodh disa herë në ditë. Në këtë cikël, OS ka lidhje me disa praktika, të cilat do i shqyrtojmë më në detaje.

ËshtĂ« e rĂ«ndĂ«sishme: feedback-u mund tĂ« bĂ«het zgjidhja pĂ«r tĂ« gjitha problemet e pĂ«rmendura mĂ« sipĂ«r. NĂ« bashkĂ«punim me praktikat XP, ai mund tĂ« na nxjerrĂ« nga humbja e shpresĂ«s.

Si të të nxjerrësh veten nga humbja e shpresës: tri praktika

Testet

Testet përmenden dy herë në ciklin e feedback-ut XP. Kjo nuk është rastësi. Ato janë jashtëzakonisht të rëndësishme për tërë teknikën e programimit ekstrem.

Supozoheni se keni teste Unit dhe Acceptance. Disa ju japin feedback brenda disa minutash, të tjerat brenda disa ditësh, prandaj ato shkruhen më gjatë, por ekzekutohen më rrallë.

Ekziston një piramidë klasike testimi, e cila tregon se disa teste duhet të jenë më shumë.

Infrastruktura si Kod: si si gali te zgjidhni problemet me XP

Si aplikohet kjo skemĂ« nĂ« projektin tonĂ« IaC? NĂ« tĂ« vĂ«rtetë  aspak.

  • Testet Unit, megjithĂ«se duhet tĂ« jenĂ« shumĂ«, nuk mund tĂ« jenĂ« tejet tĂ« shumta. Ose ato testojnĂ« diçka shumĂ« indirekt. NĂ« tĂ« vĂ«rtetĂ«, mund tĂ« themi se ne nuk i shkruajmĂ« fare. MegjithatĂ«, kĂ«tu janĂ« disa aplikime pĂ«r teste tĂ« tilla qĂ« çdo tĂ« paktĂ«n mundĂ«m t'i realizojmĂ«:
    1. Testimi i kodit në jsonnet. Ky është, për shembull, pipeline ynë i ndërtimit në drone, i cili është mjaft kompleks. Kodi në jsonnet mbulohet mirë me teste.
      Ne përdorim këtë Unit testing framework for Jsonnet.
    2. Testet për skriptet, të cilat ekzekutohen gjatë nisjes së burimeve. Skriptet në Python, dhe për rrjedhojë testet për to mund të shkruheshin.
  • Potencialisht Ă«shtĂ« e mundur tĂ« kontrollojmĂ« konfigurimin nĂ« teste, por ne nuk e bĂ«jmĂ« kĂ«shtu. Ka gjithashtu mundĂ«sinĂ« e konfigurimit tĂ« rregullave tĂ« kontrollit tĂ« burimeve pĂ«rmes tflint. MegjithatĂ«, thjesht pĂ«r Terraform Ă«shtĂ« kryer njĂ« kontroll shumĂ« bazik, por ka shumĂ« skenarĂ« testuese tĂ« shkruar pĂ«r AWS. Dhe ne jemi nĂ« Azure, kĂ«shtu qĂ« kjo sĂ«rish nuk i pĂ«rshtatet.
  • Testet e integrimit tĂ« komponentĂ«ve: kĂ«tu varet nga mĂ«nyra se si i klasifikoni dhe ku i vendosni. Por ato nĂ« parim funksionojnĂ«.

    Këtu janë të tilla integrimet e testeve.

    Infrastruktura si Kod: si si gali te zgjidhni problemet me XP

    Ky është një shembull gjatë ndërtimit të imazheve në Drone CI. Për të arritur atje, duhet të presësh 30 minuta për të pritur që imazhi Packer të grumbullohet, pastaj 15 minuta për të kaluar. Por ato ekzistojnë!

    Algoritmi i kontrollit të imazheve

    1. Fillimisht, Packer duhet të përgatisë plotësisht imazhin.
    2. Përkrah testit ka terraform me gjendje lokale, me të cilin e zhvillojmë këtë imazh.
    3. Gjatë zhvillimit përdoret një modul i vogël, i cili ndodhet afër, për ta bërë më të lehtë punën me imazhin.
    4. Kur një VM është zhvilluar nga imazhi, mund të fillojmë verifikimet. Kryesisht, verifikimet bëhen në makinë. Këtu kontrollohet si kanë funksionuar skritpat gjatë startit dhe si funksionojnë demonët. Për këtë, përmes ssh ose winrm ne hyjmë në makinën e sapolindur dhe kontrollojmë gjendjen e konfigurimit ose nëse shërbimet janë aktivizuar.

  • SituatĂ« e ngjashme ka me testet integruese dhe nĂ« modulĂ«t pĂ«r terraform. Ja njĂ« tabelĂ« e shkurtĂ«r qĂ« shpjegon veçoritĂ« e kĂ«tyre testeve.

    Infrastruktura si Kod: si si gali te zgjidhni problemet me XP

    Kthimi i informacionit në pipeline është rreth 40 minuta. Gjithçka ndodh shumë ngadalë. Mund të përdoret për regresinë, por për zhvillim të ri është krejtësisht e pamundur. Nëse përgatitemi shumë, përgatitim running, skritpat, atëherë mund ta zvogëlojmë në 10 minuta. Por kjo gjithsesi nuk është test Unit, që bën 100 teste për 5 sekonda.

Mungesa e testeve Unit gjatë ndërtimit të imazheve ose modulëve të terraformit na detyron të hedhim punën në shërbime të veçanta, të cilat thjesht mund të thirren përmes REST, ose në skritpa Python.

Për shembull, na nevojitej të bënim që, gjatë startit të makinës virtuale, ajo të regjistrohej në shërbimin ScaleFT, dhe gjatë shkatërrimit të VM-së të hiqte veten.

Deri sa ScaleFT është një shërbim, ne detyrohemi të punojmë me të përmes API-së. Atje ishte shkruar një mbështetje, që mund të thirret dhe të thuhet: "Hy dhe hiqe këtë, atë". Ajo mban të gjitha konfigurimet dhe qasjen e nevojshme.

Tani mund të shkruajmë teste normale, pasi kjo nuk ka asnjë ndryshim nga softi i zakonshëm: mock-ojmë ndonjë API, e thirremi dhe shohim çfarë ndodh.

Infrastruktura si Kod: si si gali te zgjidhni problemet me XP

Përfundimet nga testet: Testimi Unit, që duhet të japë OS për një minutë, nuk e bën atë. Ndërsa llojet më të larta të testimit në piramidë japin efekt, por mbulojnë vetëm një pjesë të problemeve.

Programimi i çiftave

Testet janë, sigurisht, të mira. Mund të shkruhen shumë prej tyre, mund të jenë të llojeve të ndryshme. Ato do të punojnë në nivelet e tyre dhe do të na japin feedback. Por problemi me testet e dobëta që ofrojnë sistemin më të shpejtë vazhdon të ekzistojë. Megjithatë, vazhdojmë të duam një sistem të shpejtë, me të cilin është lehtë dhe këndshëm të punosh. Pa folur për cilësinë e zgjidhjes që marrim. Me fat, ka teknika që lejojnë të ofrojnë një feedback edhe më të shpejtë se testet modulare. Kjo është programimi i çiftit.

Kur shkruajmë kod, duam të marrim feedback mbi cilësinë e tij sa më shpejt të jetë e mundur. Po, mund të shkruani gjithçka në një degë funksionale (për të mos prishur asgjë për askënd), të krijoni një pull request në GitHub, të caktoni dikë, mendimi i të cilit ka peshë, dhe të prisni përgjigjen.

Por mund tĂ« presim gjatĂ«. NjerĂ«zit janĂ« tĂ« gjithĂ« tĂ« zĂ«nĂ«, dhe pĂ«rgjigja, edhe nĂ«se vjen, mund tĂ« mos jetĂ« e cilĂ«sisĂ« mĂ« tĂ« lartĂ«. SupozojmĂ« se pĂ«rgjigja erdhi menjĂ«herĂ«, rishikuesi e kuptoi menjĂ«herĂ« gjithĂ« qĂ«llimin, por pĂ«rgjigja gjithsesi vjen me vonesĂ«, pas faktit. Dhe ne duam ta marim atĂ« mĂ« tĂ« shpejtĂ«. KĂ«tu synon programimi i çiftit – qĂ« tĂ« ketĂ« feedback menjĂ«herĂ«, nĂ« momentin e shkruar.

Më poshtë po sjell stilet e programimit të çiftit dhe aplikueshmërinë e tyre në punën mbi IaC:

1. Klasik, Ekspert+ekspert, ndĂ«rrim sipas njĂ« kohezgjatjeje tĂ« caktuar. Dy role – shofer dhe navigator. Dy persona. Ata punojnĂ« mbi njĂ« kod dhe ndĂ«rrimin e roleve e bĂ«jnĂ« pas njĂ« periudhe tĂ« caktuar kohore.

Le të shqyrtojmë përputhshmërinë e problemeve tona me stilin:

  • Problemi: pĂ«rsosmĂ«ritĂ« e mjeteve, mjeteve pĂ«r zhvillimin e kodit.
    Ndikimi negativ: zhvillimi zgjat më gjatë, ne ngadalësohemi, humbasim ritmin.
    Si luftojmë: aplikojmë mjete të tjera, IDE për të gjithë dhe mësojmë shkurtesat.
  • Problemi: shpĂ«rndarja e ngadaltĂ«.
    Ndikimi negativ: rrit kohën për të krijuar një copë funksionale të kodit. Bëhemi të mërzitur gjatë pritjes, duar tërhiqen për të bërë diçka tjetër, derisa presim.
    Si luftojmë: nuk e kemi përballuar.
  • Problemi: mungesa e qasjeve dhe praktikave.
    Ndikimi negativ: nuk ka njohuri se si të bëhet mirë dhe si keq. Zgjat marrjen e feedbackut.
    Si luftojmë: shkëmbimi i mendimeve dhe praktikave në punën e çiftit pothuajse zgjidh problemin.

Problemi kryesor i pĂ«rdorimit tĂ« kĂ«tij stili nĂ« IaC Ă«shtĂ« ritmi i papĂ«rshtatshĂ«m i punĂ«s. NĂ« zhvillimin tradicional tĂ« softuerit, ke njĂ« lĂ«vizje shumĂ« uniforme. Mund tĂ« harxhosh pesĂ« minuta dhe tĂ« shkruash N. TĂ« harxhosh 10 minuta dhe tĂ« shkruash 2N, 15 minuta – 3N. KĂ«tu, mund tĂ« harxhosh pesĂ« minuta dhe tĂ« shkruash N, pastaj tĂ« harxhosh akoma 30 minuta dhe tĂ« shkruash njĂ« tĂ« dhjetĂ«n e N. KĂ«tu nuk di asgjĂ«, ndihesh i bllokuar. Zgjidhja merr kohĂ« dhe tĂ« shpĂ«rqendron nga programimi vetĂ«.

Përfundimi: në formën e pastër nuk na përshtatet.

2. Ping-pong. Ky qasje supozon që një pjesëmarrës shkruan testin, ndërsa tjetri e bën realizimin e tij. Duke marrë parasysh se me testet e njësive gjithçka është e komplikuar, dhe është e nevojshme të shkruash një test integrues që kërkon shumë kohë, e gjithë lehtësia e ping-pong-ut largohet.

Mund të them se kemi provuar ndarjen e detyrave për projektimin e skenarit të testit dhe realizimin e kodit për të. Një pjesëmarrës shpik skenarin, në këtë pjesë të punës ai është përgjegjës, atij i përket fjala përfundimtare. Ndërsa tjetri është përgjegjës për realizimin. Kjo rezultoi mirë. Cilësia e skenarit në këtë qasje rritet.

Përfundimi: fatkeqësisht, ritmi i punës nuk lejon përdorimin e ping-pong si praktikë të programimit në çift në IaC.

3. Strong Style. Praktikë e komplikuar.. Ideja është që një pjesëmarrës bëhet një navigues direktiv, ndërsa tjetri merr rolin e shoferit ekzekutues. Në këtë rast, e drejta për të marrë vendime është ekskluzivisht e naviguesit. Shoferi thjesht shtyp dhe me fjalë mund të ndikojë në ngjarjet. Roli nuk ndryshon për një kohë të gjatë.

Shkon mirë për mësim, por kërkon aftësi të forta sociale. Këtu u bllokuam. Teknikat ishin të komplikuara. Dhe kjo ndodhi jo për shkak të infrastrukturës.

Përfundimi: potencialisht mund të aplikohet, ne nuk e lëmë mundësinë.

4. Mobbing, swarming, dhe të gjithë stilët e njohur, por jo të përmendur këtu, nuk shqyrtohen, pasi nuk i kemi provuar dhe nuk mund të themi për këtë në kontekstin e punës tonë.

Përmbledhje e përgjithshme mbi përdorimin e programimit në çift:

  • Kemi njĂ« ritĂ«m pune tĂ« pauniformuar, qĂ« na pengon.
  • Ne kemi hasur nĂ« aftĂ«si tĂ« pamjaftueshme sociale. Dhe fusha tematike nuk ndihmon nĂ« tejkalimin e kĂ«tyre mangĂ«sive tona.
  • Testet e gjata, problemet me mjetet e punĂ«s e bĂ«jnĂ« zhvillimin nĂ« çift tĂ« ngadaltĂ«.

5. Megjithatë, kishim edhe suksese. Ne krijuam metodën tonë "Konvergjencë - Divergjencë". Përmbledhtas, do ta përshkruaj si funksionon.

Kemi partnerë të përhershëm për disa ditë (pak më pak se një javë). Bëjmë një detyrë së bashku. Njëfarë kohe qëndrojmë së bashku: një shkruan, tjetri qëndron dhe vështron si një ekip mbështetës. Pastaj shpërndajmë për një kohë, secili bën diçka të pavarur, pastaj prapë takohemi, shpejtëkoordinim, bëjmë diçka së bashku dhe përsëri shpërndajmë.

Planifikimi dhe komunikimi

Blloku i fundit i praktikave, pĂ«rmes tĂ« cilave zgjidhen problemet e OS – Ă«shtĂ« organizimi i punĂ«s me detyrat vetĂ«. KĂ«tu hyjnĂ« edhe shkĂ«mbimi i pĂ«rvojĂ«s, i cili Ă«shtĂ« jashtĂ« punĂ«s nĂ« çift. Le tĂ« shqyrtojmĂ« tre praktika:

1. Detyrat pĂ«rmes strukturĂ«s sĂ« qĂ«llimeve. Menaxhimi i pĂ«rgjithshĂ«m i projektit e kemi organizuar pĂ«rmes njĂ« strukture, qĂ« shkon pafundĂ«sisht nĂ« tĂ« ardhmen. Teknikisht, mbajtja e vĂ«shtirĂ«sohet nĂ« Miro. Ka njĂ« detyrĂ« – ajo Ă«shtĂ« njĂ« qĂ«llim ndĂ«rmjetĂ«s. Prej saj dalin ose qĂ«llime mĂ« tĂ« vogla, ose grupe detyrash. Prej tyre janĂ« pa dyshim detyrat. TĂ« gjitha detyrat krijohen dhe menaxhohen nĂ« kĂ«tĂ« tabelĂ«.

Infrastruktura si Kod: si si gali te zgjidhni problemet me XP

Ky skemë gjithashtu ofron reagim, i cili ndodh një herë në ditë, kur ne koordinatohemi në mbledhje. Prania e një plani të përbashkët për të gjithë, i strukturuar dhe plotësisht i hapur, lejon çdo kush të jetë në dijeni të asaj që po ndodh dhe se sa përpara kemi avancuar në progres.

Përparësitë e shikimit vizual të detyrave:

  • Kauzaliteti. Çdo detyrĂ« çon nĂ« njĂ« qĂ«llim global. Detyrat grupohen sipas qĂ«llimeve mĂ« tĂ« vogla. Domeni i infrastrukturĂ«s vetĂ« Ă«shtĂ« mjaft teknik. Nuk Ă«shtĂ« gjithmonĂ« e qartĂ« menjĂ«herĂ« se cilat ndikim konkret ka nĂ« biznes, pĂ«r shembull, shkruani njĂ« dokument rregullash pĂ«r migrimin nĂ« njĂ« nginx tjetĂ«r. Prania e njĂ« kartĂ« qĂ«llimike pranĂ« e bĂ«n mĂ« tĂ« kuptueshĂ«m.
    Infrastruktura si Kod: si si gali te zgjidhni problemet me XP
    Kauzaliteti – Ă«shtĂ« njĂ« pronĂ« e rĂ«ndĂ«sishme e detyrave. Ai pĂ«rgjigjet drejtpĂ«rdrejt nĂ« pyetjen: "A po bĂ«j atĂ« qĂ« duhet?"
  • Paraleliteti. Ne jemi nĂ«ntĂ« njerĂ«z, dhe Ă«shtĂ« fizikisht e pamundur qĂ« tĂ« sulmojmĂ« tĂ« gjithĂ« njĂ« detyrĂ«. Detyrat nga njĂ« fushĂ« gjithashtu nuk janĂ« gjithmonĂ« tĂ« mjaftueshme. Ne jemi tĂ« detyruar tĂ« ndahet punĂ«n nĂ« grupe tĂ« vogla punuese. GjatĂ« kĂ«saj, grupet kalojnĂ« njĂ« kohĂ« tĂ« caktuar me detyrĂ«n e tyre dhe mund tĂ« forcohen nga dikush tjetĂ«r. NdonjĂ«herĂ« ndodhin ndryshime nĂ« kĂ«tĂ« grup pune. Disa largohen nĂ« pushim, disa pĂ«rgatisin njĂ« referim pĂ«r konferencĂ«n DevOps conf, disa shkruajnĂ« njĂ« artikull pĂ«r Habr. TĂ« dish se cilat qĂ«llime dhe detyra mund tĂ« bĂ«hen paralelisht bĂ«het shumĂ« e rĂ«ndĂ«sishme.

2. Ndryshimi i liderëve në takimet e mëngjesit. Në standup, u shfaq një problem - shumë detyra njerëzit i bëjnë paralelisht. Ndonjëherë detyrat janë pak të lidhura dhe nuk ka kuptim se kush bën çfarë. Opinioni i një anëtari tjetër të ekipit është shumë i rëndësishëm. Ky është informacion shtesë, i cili mund të ndryshojë kursin e zgjidhjes së detyrës. Sigurisht, zakonisht je me dikë, por konsultimi dhe ndihmat janë gjithmonë të dobishme.

Për të përmirësuar këtë situatë, ne aplikuam teknikën "Ndryshimi i liderit të standup-it". Tani ato rotullohen sipas një liste të caktuar, dhe ky ka efektin e tij. Kur arrin radha jote, je i detyruar të thellohesh dhe të kuptosh çfarë po ndodh, për të drejtuar mirë takimin e skram.

Infrastruktura si Kod: si si gali te zgjidhni problemet me XP

3. Demo e brendshme. Ndihma në zgjidhjen e detyrës nga programimi i përbashkët, vizualizimi në pemën e detyrave dhe ndihma në takimet e skramit në mëngjes është e mirë, por jo perfekte. Në çift je i kufizuar vetëm nga njohuritë tuaja. Pema e detyrave ndihmon për të kuptuar globalisht se kush dhe çfarë po bën. Ndërsa udhëheqësi dhe kolegët në takimin e mëngjesit nuk do të thellohen shumë në problemet tua. Ata sigurisht mund të lënë diçka pa qënë vënë re.

Zgjidhja u gjet në demontrimin e punimeve të bëra ndaj njëri-tjetrit dhe diskutimit të mëpasshëm të tyre. Ne mblidhemi një herë në javë për një orë dhe tregojmë detajet e zgjidhjeve për detyrat që kemi bërë javën e kaluar.

Në procesin e demontrimit, duhet të zbulojmë detajet e detyrës dhe patjetër të demonstrojmë funksionimin e saj.

Raporti mund të udhëhiqet sipas një liste kontrolli.1. Fut në kontekst. Nga erdhi detyra, përse ishte e nevojshme kjo në të vërtetë?

2. Si është zgjidhur detyra deri tani? Për shembull, ishte e nevojshme të klikosh shumë me miun, ose ishte krejtësisht e pamundur të bëhej diçka.

3. Si e përmirësojmë këtë. Për shembull: "Shikoni, tani ka një skrip, ja README."

4. Trego se si funksionon. Preferohet të realizoni një skenar të përdoruesit. Dua X, bëj Y, shoh Z (ose Z'). Për shembull, deploy NGINX, shikoj url, merr 200 OK. Nëse veprimi zgjat, përgatiteni më parë për ta treguar më vonë. Preferohet të mos ndërpritet shumë para demos, veçanërisht nëse është delikat.

5. Shpjegoni se sa mirë është zgjidhur problemi, cilat vështirësi kanë mbetur, çfarë nuk është përfunduar, çfarë përmirësimesh janë të mundshme në të ardhmen. Për shembull, tani cli, më vonë do të ketë automatizim të plotë në CI.

Preferohet që çdo folës të përfshihet brenda 5-10 minutash. Nëse fjalimi juaj është me rëndësi të madhe dhe do të zgjasë më shumë, dakordoni këtë paraprakisht në kanalin sre-takeover.

Pas pjesës me prezencë fizike, përcjellja e diskutimeve në thread është e domosdoshme. Këtu do të dalë e nevojshmja për ne një informacion të kthyer për detyrat tona.

Infrastruktura si Kod: si si gali te zgjidhni problemet me XP
Në përfundim, organizohet një anketë për të vlerësuar përdorshmërinë e zhvillimeve. Kjo është tashmë një informacion i kthyer në lidhje me përmbajtjen e fjalimit dhe rëndësinë e detyrës.

Infrastruktura si Kod: si si gali te zgjidhni problemet me XP

Përfundime të gjata dhe çfarë do të ndodhë më pas

Mund të duket se qëndrimi i artikullit është disi pesimist. Kjo nuk është e saktë. Dy nivelet e ulëta të marrjes së informacionit të kthyer, domethënë testet dhe programimi në çift, funksionojnë. Nuk është aq perfekt sa në zhvillimin tradicional, por ka një efekt pozitiv nga kjo.

Testet, në formën e tyre aktuale, ofrojnë vetëm mbulim të pjesshëm të kodit. Shumë funksione konfigurimi nuk janë testuar. Ndikimi i tyre në punën e menjëhershme gjatë shkruarjes së kodit është i ulët. Megjithatë, ka një efekt nga testet integruese, dhe ato lejojnë që të kryhen pa frikë refaktorizime. Kjo është një arritje e madhe. Gjithashtu, me kalimin në zhvillimin në gjuhë të nivelit të lartë (ne kemi python, go) problemi zhduket. Dhe për "ndihmën" ka shumë prova dhe nuk është e nevojshme, mjafton teste të përgjithshme integruese.

Puna në çift varet më shumë nga njerëzit specifikë. Ka një faktor të detyrës dhe aftësive tona të buta. Me dikë funksionon shumë mirë, me dikë më keq. Patjetër ka dobi nga kjo. E qartë është se edhe kur rregullat e punës në çift nuk respektohen, vetë fakti i realizimit të detyrave së bashku ndikon pozitivisht në cilësinë e rezultatit. Për mua, është më e lehtë dhe më e këndshme të punosh në çift.

Metoda më të nivelit të lartë për të ndikuar në OS - planifikimi dhe puna me detyrat sigurisht që japin efekte: shkëmbimi i njohurive dhe përmirësimi i cilësisë së zhvillimit.

Përmbledhje të shkurtra me një rresht

  • Praktikat XP funksionojnĂ« nĂ« IaC, por me efikasitet mĂ« tĂ« ulĂ«t.
  • Forconi atĂ« qĂ« funksionon.
  • Krijoni mekanizmat dhe praktikat tuaja kompensuese.

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster