ProHoster > Blogs > Administrācija > Infrastructure as Code: kā risināt problēmas ar XP

Infrastructure as Code: kā risināt problēmas ar XP

Sveiks, Habr! Agrāk es sÅ«dzējos par dzÄ«vi infrastruktÅ«ras kā koda paradigmas ietvaros un nepiedāvāju risinājumus esoÅ”ajai situācijai. Å odien esmu atgriezies, lai pastāstÄ«tu, kādi pieejas un prakses var palÄ«dzēt izkļūt no izmisuma bezdibeņa un novirzÄ«t situāciju pareizajā virzienā.

Infrastructure as Code: kā risināt problēmas ar XP

IepriekŔējā rakstā ā€žInfrastruktÅ«ra kā kods: pirmā iepazÄ«Å”anāsā€œ Es dalÄ«jos ar savām pārdomām par Å”o jomu, mēģināju apspriest paÅ”reizējo situāciju un pat pieļāvu, ka standarta, visiem izstrādātājiem zināmās prakses var palÄ«dzēt. Varēja Ŕķist, ka tajā bija daudz sÅ«dzÄ«bu par dzÄ«vi, bet nebija piedāvājumu par risinājumiem sarežģījumiem.

Kas mēs esam, kur mēs esam un kādas ir mūsu problēmas

PaÅ”laik mēs atrodamies SRE onboarding komandā, kas sastāv no seÅ”iem programmētājiem un trim infrastruktÅ«ras inženieriem. Visi mēs cenÅ”amies rakstÄ«t infrastruktÅ«ru kā kodu (IaC). Mēs to darām, jo principā spējam rakstÄ«t kodu un mÅ«su pieredze ir vidējā lÄ«menÄ«.

  • Mums ir vairāki plusi: noteikta pieredze, prakses zināŔanas, spējas rakstÄ«t kodu, vēlme mācÄ«ties jauno.
  • Un ir vājā puse, kas ir mÄ«nuss: zināŔanu trÅ«kums par infrastruktÅ«ras pamata lietām.

Tehnoloģiju kaudze, ko mēs izmantojam mūsu IaC.

  • Terraform resursu izveidei.
  • Packer attēlu veidoÅ”anai. Tas ir Windows, CentOS 7 attēli.
  • Jsonnet, lai veidotu jaudÄ«gas struktÅ«ras drone.io, kā arÄ« packer json un mÅ«su Terraform moduļu Ä£enerÄ“Å”anai.
  • Azure.
  • Ansible attēlu sagatavoÅ”anai.
  • Python palÄ«gservisiem, kā arÄ« provizionÄ“Å”anas skriptiem.
  • Un viss tas VSCode ar paplaÅ”inājumiem, ko kopÄ«gi izmanto komandas dalÄ«bnieki.

Izvērsts no manas iepriekŔējās raksta secinājuma: es centos ieviest (vispirms sevÄ«) optimismu, gribēju teikt, ka mēs izmēģināsim mums zināmās pieejas un prakses, lai cÄ«nÄ«tos ar grÅ«tÄ«bām un sarežģījumiem, kas pastāv Å”ajā jomā.

PaÅ”laik mēs saskaramies ar Ŕādām IaC problēmām:

  • RÄ«ku, kodu izstrādes lÄ«dzekļu nepilnÄ«bas.
  • Lēna izvērÅ”ana. InfrastruktÅ«ra ir reāla pasaule, un tā var bÅ«t lēna.
  • Pieejas un prakses trÅ«kums.
  • Mēs esam jauni un daudz nezinoÅ”i.

Ekstremālā programmÄ“Å”ana (XP) steidzas palÄ«gā.

Visi izstrādātāji labi zina ekstrēmo programmÄ“Å”anu (XP) un tās pamatprincipus. Daudzi no mums ir strādājuÅ”i pēc Ŕāda pieejas, un tā ir bijusi veiksmÄ«ga. Tātad, kāpēc neizmantot principus un prakses, kas tur ir iekļautas, lai pārvarētu infrastruktÅ«ras grÅ«tÄ«bas? Mēs nolēmām piemērot Å”o pieeju un noskaidrot, kas no tā sanāks.

Pārbaude par XP pieejas piemērotību jūsu jomaiPiedāvāju aprakstu par vidi, kurai XP ir labi piemērots, un kā tas attiecas uz mums:

1. Dinamiski mainÄ«gas programmatÅ«ras prasÄ«bas. Mums bija skaidrs, kas ir galamērÄ·is. Bet detaļās var variēt. Mēs paÅ”i nosakām, uz kurieni mums jādodas, tāpēc prasÄ«bas periodiski mainās (pamatā tos nosakām mēs paÅ”i). Ja ņemam SRE komandu, kas pati veic automatizāciju un pati nosaka prasÄ«bas un darba apjomu, tad Å”is punkts ir piemērots.

2. Riski, ko rada fiksētā laika projekti jaunās tehnoloÄ£ijas izmantoÅ”ana. Mums var rasties riski, izmantojot dažas mums nezināmas lietas. Un tas ir 100% mÅ«su gadÄ«jums. Visu mÅ«su projektu veido tehnoloÄ£ijas, ar kurām mēs nebijām lÄ«dz galam pazÄ«stami. PatiesÄ«bā tā ir pastāvÄ«ga problēma, jo infrastruktÅ«ras jomā pastāvÄ«gi parādās daudzas jaunas tehnoloÄ£ijas.

3,4. Mazas, kopā strādājoÅ”as pagarinātās izstrādes komandas. TehnoloÄ£ija, ko jÅ«s izmantojat, ļauj veikt automatizētus vienÄ«bu un funkcionālos testus. Å ie divi punkti mums nav pilnÄ«bā piemēroti. Pirmkārt, mēs neesam kolocēta komanda, otrkārt, mÅ«s ir deviņi, kas var tikt uzskatÄ«ts par lielu komandu. Lai gan, saskaņā ar daudziem definÄ«cijām "liela" komanda ir 14+ cilvēki.

Apskatīsim dažas XP prakses un to, kā tās ietekmē atgriezeniskās saites ātrumu un kvalitāti.

Atgriezeniskās saites cikls XP

Manā izpratnē atgriezeniskā saite ir atbilde uz jautājumu, vai es to daru pareizi, vai mēs ejam pareizajā virzienā? XP Å”ajā jautājumā ir dieviŔķā shēma: atgriezeniskās saites cikls pēc laika. Interesanti ir tas, ka jo dziļāk mēs esam, jo ātrāk mēs varam saņemam OS, lai atbildētu uz nepiecieÅ”amajiem jautājumiem.

Infrastructure as Code: kā risināt problēmas ar XP

Å Ä« ir diezgan interesanta tēma diskusijai, jo mÅ«su IT industrijā iespējams ātri saņemt OS. Iedomājieties, cik sāpÄ«gi ir strādāt pie kāda projekta pusgadu un tikai pēc tam uzzināt, ka paŔā sākumā tika ieviesta kļūda. Tas notiek gan projektÄ“Å”anā, gan jebkurā sarežģītu sistēmu veidoÅ”anā.

MÅ«su gadÄ«jumā IaC mums palÄ«dz atgriezeniskā saite. Nekavējoties veicu nelielu koriģēŔanu iepriekŔējā shēmā: izlaiduma plāns nav mēneÅ”a cikls, bet notiek vairākas reizes dienā. Å im ciklam ir pievienotas dažas prakses, kuras mēs apskatÄ«sim detalizētāk.

SvarÄ«gi: atgriezeniskā saite var kļūt par risinājumu visām iepriekÅ” minētajām problēmām. Apvienojumā ar XP praksēm tā var izvilkt no izmisuma bezdibeņa.

Kā izvilkt sevi no izmisuma bezdibeņa: trīs prakses

Testi

Testi tiek minēti divreiz paŔā XP atgriezeniskās saites ciklā. Tas nav vienkārÅ”i tā. Tie ir ārkārtÄ«gi svarÄ«gi visai ekstrēmā programmÄ“Å”anas tehnoloÄ£ijai.

Pretstatā ir jābÅ«t Unit un Acceptance testiem. Viens dod tev atsauksmes pāris minÅ«tēs, cits ā€“ pāris dienās, jo tie tiek rakstÄ«ti ilgāk un izpildÄ«ti retāk.

Ir klasiskā testÄ“Å”anas piramÄ«da, kas parādÄ«jusi, ka kādu testu vajadzētu bÅ«t vairāk.

Infrastructure as Code: kā risināt problēmas ar XP

Kā Ŕī shēma ir piemērojama mÅ«su IaC projektā? PatiesÄ«bāā€¦ nekādā veidā.

  • Unit testu, lai gan to vajadzētu bÅ«t ļoti daudz, nevar bÅ«t ļoti daudz. Vai nu tie ļoti netieÅ”i testē kaut ko. Faktiski var teikt, ka mēs tos vispār nerakstām. Bet ir dažas Unit testu lietojumprogrammas, kuras mums tomēr izdevās izveidot:
    1. Koda testÄ“Å”ana uz jsonnet. Piemēram, mÅ«su bÅ«vÄ“Å”anas pipeline Drone, kas ir pietiekami sarežģīts. Kods uz jsonnet labi tiek pārklāts ar testiem.
      Mēs izmantojam Å”o Unit testing framework for Jsonnet.
    2. Testi uz skriptiem, kas tiek izpildÄ«ti resursu palaiÅ”anas laikā. Skripti ir uz Python, tāpēc arÄ« testus uz tiem var rakstÄ«t.
  • Potenciāli ir iespējama konfigurācijas pārbaude testos, bet mēs to nedarām. Vēl ir iespējas konfigurācijas noteikumu pārbaudes iestatÄ«Å”anai resursiem caur tflint. Tomēr, vienkārÅ”i Terraform ir pārāk pamata pārbaudes, bet daudz pārbaudes scenāriju ir uzrakstÄ«ti AWS. Mēs esam Azure, tāpēc tas atkal nepiestāv.
  • Komponentu integrācijas testi: Å”eit atkarÄ«gs no tā, kā tu tos klasificē un kur tos izliek. Bet principā tie darbojas.

    Tā izskatās integrācijas testi.

    Infrastructure as Code: kā risināt problēmas ar XP

    Tas ir piemērs, kā notiek attēlu veidoÅ”ana Drone CI. Lai pie tiem tiktu, ir jāgaida 30 minÅ«tes, kamēr Packer izveido attēlu, pēc tam vēl 15 minÅ«tes, kamēr tie tiek izpildÄ«ti. Bet tie ir!

    Attēlu pārbaudes algoritms

    1. Vispirms Packer ir jāizveido attēls pilnībā.
    2. Blakus testam ir Terraform ar lokālo stāvokli, ar kuru mēs Å”o attēlu izvērÅ”am.
    3. IzvērÅ”anas procesā tiek izmantots neliels modulis, kas atrodas blakus, lai vieglāk strādātu ar attēlu.
    4. Kad no attēla ir izvērsta VM, var sākt pārbaudes. Galvenokārt pārbaudes tiek veiktas uz maŔīnas. Tiek pārbaudÄ«ts, kā skripti darbojās startÄ“Å”anas laikā, kā darbojas dēmoni. Tam mēs caur ssh vai winrm piekļūstam tieÅ”i izveidotajai maŔīnai un pārbaudām konfigurācijas stāvokli vai vai pakalpojumi ir palaižami.

  • LÄ«dzÄ«ga situācija ir ar integrācijas testiem un Terraform moduļiem. Å eit ir Ä«sa tabula, kas izskaidro Ŕādu testu Ä«patnÄ«bas.

    Infrastructure as Code: kā risināt problēmas ar XP

    Atsauksmes par pipeline ir apmēram 40 minūtes. Viss notiek ļoti lēni. To var izmantot regresijas testi, bet jauniem izstrādājumiem tas ir pilnīgi nereāli. Ja ļoti labi sagatavosies, sagatavos running, skriptus, tad var samazināt līdz 10 minūtēm. Bet tas joprojām nav Unit testi, kas 5 sekunžu laikā var izpildīt 100 testus.

Unit testu trÅ«kums attēlu vai Terraform moduļu izveidē liek pārrakstÄ«t darbu uz atseviŔķiem pakalpojumiem, kurus vienkārÅ”i var izsist caur REST vai uz Python skriptiem.

Piemēram, mums bija jādara tā, lai, startējot virtuālo maŔīnu, tā reÄ£istrētu sevi pakalpojumā ScaleFT, bet, dzÄ“Å”ot virtuālo maŔīnu, tā dzēstu sevi.

Tā kā ScaleFT mums ir kā pakalpojums, mēs esam spiesti strādāt ar to caur API. Tur ir uzrakstÄ«ta apvalka kode, ko var izsist un teikt: "Ieej un izdzēs to, to". Tas glabā visas nepiecieÅ”amās iestatÄ«jumus un pieejas.

Uz to mēs jau varam rakstÄ«t normālus testus, jo tas nekādā veidā neatŔķiras no parasta programmatÅ«ras: apvirs tiek mētāts, tu izsiti, un skatāmies, kas notiek.

Infrastructure as Code: kā risināt problēmas ar XP

Testu rezultāti: Unit testÄ“Å”ana, kas sola OS sniegt rezultātu minÅ«tē, to nenodroÅ”ina. Bet augstāki testÄ“Å”anas veidi nodroÅ”ina efektu, taču risina tikai daļu problēmu.

Pāra programmÄ“Å”ana

Testi ir, protams, labi. Tos var rakstÄ«t daudz, tie var bÅ«t dažādu veidu. Tie darbosies savos lÄ«meņos un sniegs mums atgriezenisko saiti. Bet problēma ar sliktajiem Unit testiem, kuri dod visātrāko OS, paliek. Tomēr turpinām ilgoties pēc ātras OS, ar kuru ir viegli un patÄ«kami strādāt. Neaizmirstot par iegÅ«tā risinājuma kvalitāti. Pateicoties, ir tehnoloÄ£ijas, kas sniedz vēl ātrāku atgriezenisko saiti nekā modulārie testi. Tas ir pāru programmÄ“Å”ana.

Rakstot kodu, ir vēlme pēc iespējas ātrāk saņemt atgriezenisko saiti par tā kvalitāti. Jā, jÅ«s varat visu rakstÄ«t feature zarā (lai nevienam neko nesabojātu), izveidot pull request GitHubā, pieŔķirt kādam, kuru viedoklis ir svarÄ«gs, un gaidÄ«t atbildi.

Bet gaidÄ«t var ilgi. Cilvēki visi ir aizņemti, un atbilde, pat ja tā ierodas, var nebÅ«t visaugstākā kvalitāte. Pieņemsim, ka atbilde pienāk uzreiz, recenzents momentāli saprot visu ieceri, bet atbilde tomēr tiek saņemta ar aizkavÄ“Å”anos, pēc fakta. Un tomēr gribas ātrāk. Tāpēc pāru programmÄ“Å”ana ir vērsta uz to ā€“ lai to darÄ«tu uzreiz, rakstÄ«Å”anas brÄ«dÄ«.

Nākamajā rindkopā uzskaitÄ«Å”u pāru programmÄ“Å”anas stilus un to piemērojamÄ«bu, strādājot ar IaC:

1. Klasiskais, pieredzējis + pieredzējis, maiņa pēc taimeru. Divas lomas ā€“ vadÄ«tājs un navigators. Divi cilvēki. Viņi strādā pie viena koda un mainās lomās pēc noteikta iepriekÅ” norunāta laika perioda.

Apskatīsim mūsu problēmu kombinācijas ar stilu:

  • Problēma: rÄ«ku, lÄ«dzekļu nepilnÄ«bas kodu izstrādē.
    Negatīva ietekme: ilgāk izstrādāt, mēs palēnināmies, tiek izjaukts darbs/ritms.
    Kā cÄ«nāmies: izmantojam citu rÄ«kspuises, kopÄ«go IDE un vēl mācāmies Å”ortkatus.
  • Problēma: lēna izvērÅ”ana.
    NegatÄ«va ietekme: palielina laiku, kas nepiecieÅ”ams, lai izveidotu strādājoÅ”u koda daļu. Gaida, kamēr gaida, rokas stiepjas nodarboties ar ko citu, kamēr gaidi.
    Kā cÄ«nāmies: neesam uzvarējuÅ”i.
  • Problēma: pieeju un prakses trÅ«kums.
    Negatīva ietekme: nav zināŔanu, kā darīt labi, bet kā slikti. Pagarināts atgriezeniskās saites iegūŔanas laiks.
    Kā cīnāmies: viedokļu un prakses apmaiņa pāru darbā gandrīz atrisina problēmu.

Galvenā problēma Ŕī stila izmantoÅ”anā IaC ir nevienmērÄ«gais darba temps. Tradicionālajā programmatÅ«ras izstrādē tev ir ļoti vienmērÄ«ga kustÄ«ba. Tu vari veltÄ«t piecas minÅ«tes un uzrakstÄ«t N. VeltÄ«t desmit minÅ«tes un uzrakstÄ«t 2N, piecpadsmit minÅ«tes ā€“ 3N. Å eit tu vari veltÄ«t piecas minÅ«tes un uzrakstÄ«t N, bet pēc tam vēl trÄ«sdesmit minÅ«tes un uzrakstÄ«t desmito daļu no N. Å eit tu neko nezini, ir aizÄ·erÅ”anās, apjukums. Izpratnes iegÅ«Å”ana prasa laiku un novirza no tieŔā programmÄ“Å”anas.

Secinājums: tīrā veidā mums neder.

2. Ping-pong. Å is pieejas pieņem, ka viens dalÄ«bnieks raksta testu, bet otrs veic tā Ä«stenoÅ”anu. Ņemot vērā, ka ar vienÄ«bas testiem viss ir sarežģīti un jāraksta ilgstoÅ”s integrācijas tests, visa ping-pong vieglums pazÅ«d.

Varu teikt, ka mēs esam izmēģinājuÅ”i pienākumu sadalÄ«jumu testu scenārija izstrādē un tā koda Ä«stenoÅ”anā. Viens dalÄ«bnieks izdomāja scenāriju, Å”ajā darba daļā viņŔ bija atbildÄ«gs, viņam bija pēdējais vārds. Bet otrs bija atbildÄ«gs par Ä«stenoÅ”anu. Tas izdevās labi. Scenārija kvalitāte Ŕādā pieejā palielinās.

Secinājums: diemžēl darba temps neļauj izmantot ping-pong kā pārÄ« programmÄ“Å”anas praksi IaC.

3. SpēcÄ«gais stils. Sarežģīta prakse. Ideja ir tāda, ka viens dalÄ«bnieks kļūst par vadlÄ«niju sniedzēju, bet otrs uzņemas izpildÄ«tāja lomu. Å ajā gadÄ«jumā lēmumu pieņemÅ”ana ir tikai vadlÄ«niju sniedzēja rokās. IzpildÄ«tājs tikai raksta un vārds var ietekmēt notiekoÅ”o. Lomas nemainās ilgu laiku.

Labi piemērots mācÄ«bām, bet prasa spēcÄ«gas sociālās prasmes. Å eit mēs arÄ« apstājāmies. Tehnika gāja sarežģīti. Un Å”eit pat neiet runa par infrastruktÅ«ru.

Secinājums: potenciāli var tikt izmantots, mēs nebeidzam centienus.

4. Mobbing, swarming un visi zināmie, bet Å”eit neuzskaitÄ«tie stili netiek aplÅ«koti, jo neesam tos izmēģinājuÅ”i un nevaram par to runāt mÅ«su darba kontekstā.

Kopējie secinājumi par pārÄ« programmÄ“Å”anas izmantoÅ”anu:

  • Mums ir nevienmērÄ«gs darba temps, kas novērÅ” uzmanÄ«bu.
  • Mēs esam saskāruÅ”ies ar nepietiekami labām sociālajām prasmēm. Un tēmas joma neveicina Å”o mÅ«su trÅ«kumu pārvarÄ“Å”anu.
  • Ilgi testi, problēmas ar rÄ«kiem padara pāru izstrādi lēnu.

5. Tomēr bija arÄ« panākumi. Mēs izstrādājām savu metodi ā€žSakritÄ«ba ā€“ pretrunaā€. ÄŖsumā aprakstÄ«Å”u, kā tas darbojas.

Mums ir pastāvīgi partneri uz dažām dienām (mazāk nekā nedēļa). Mēs kopā risinām vienu uzdevumu. Kādu laiku mēs strādājam kopā: viens raksta, otrs uzrauga, kā strādā atbalsta komanda. Pēc tam mēs uz kādu laiku izklīstam, katrs veic savus neatkarīgos darbus, tad atkal apvienojam spēkus, ļoti ātri sinhronizējamies, darām kaut ko kopā un atkal izklīstam.

PlānoŔana un komunikācija

Pēdējais prakses bloks, caur kuru tiek risinātas OS problēmas, ir darbu organizācija ar paÅ”iem uzdevumiem. Å eit ietilpst arÄ« pieredzes apmaiņa, kas notiek ārpus pāra darba. ApskatÄ«sim trÄ«s prakses:

1. Uzdevumi caur mērÄ·u koku. Projektu kopÄ«gi organizējam caur koku, kas bezgalÄ«gi ieiet nākotnē. Tehniski tas tiek veikts Miro. Ir viens uzdevums ā€“ tas ir starpposma mērÄ·is. No tā iet gan mazāki mērÄ·i, gan uzdevumu grupas. No tām jau paÅ”i uzdevumi. Visi uzdevumi tiek izveidoti un vadÄ«ti uz Ŕīs dēļa.

Infrastructure as Code: kā risināt problēmas ar XP

Å Ä« shēma arÄ« sniedz atgriezenisko saiti, kas notiek vienreiz dienā, kad mēs sinhronizējamies sanāksmēs. Vispārēja plāna klātbÅ«tne, turklāt strukturēta un pilnÄ«bā atklāta, ļauj ikvienam bÅ«t informētam par notiekoÅ”o un to, cik tālu mēs esam progresējuÅ”i.

Uzdevumu vizuālās redzamības priekŔrocības:

  • CēloņsakarÄ«ba. Katrs uzdevums noved pie kāda globālā mērÄ·a. Uzdevumi tiek grupēti pēc mazākiem mērÄ·iem. InfrastruktÅ«ras joma pati par sevi ir diezgan tehniska. Ne vienmēr ir skaidrs, kā rakstÄ«Å”ana par migrācijas rokasgrāmatu uz citiem nginx ietekmē biznesu. Klāt esoŔā mērÄ·a karte padara to saprotamāku.
    Infrastructure as Code: kā risināt problēmas ar XP
    CēloņsakarÄ«ba ir svarÄ«ga uzdevumu Ä«paŔība. Tā tieÅ”i atbild uz jautājumu: ā€žVai es daru pareizo?ā€
  • Paralēlisms. Mums ir deviņi cilvēki, un visiem uz viena uzdevuma uzbrukt fiziski nav iespējams. Uzdevumu no vienas jomas arÄ« ne vienmēr var pietikt. Mēs spiesti paralelizēt darbu starp mazām darba grupām. Å ajā procesā grupas kādu laiku strādā pie sava uzdevuma, tās var tikt stiprinātas ar kādu citu. No Ŕīs darba grupas reizēm aiziet cilvēki. Kāds dodas atvaļinājumā, kāds sagatavo ziņojumu konferencei DevOps conf, kāds raksta rakstu uz Habr. Zināt, kādi mērÄ·i un uzdevumi var tikt veikti paralēli, kļūst ļoti svarÄ«gi.

2. MainÄ«gie vadÄ«tāji rÄ«ta sapulcēm. Stand-up sapulcēs radās tāda problēma ā€“ cilvēki veic daudz uzdevumu paralēli. Dažreiz uzdevumi ir vāji saistÄ«ti un nav skaidrs, kas ko dara. Un vēl viena komandas dalÄ«bnieka viedoklis ir ļoti svarÄ«gs. Tas ir papildu informācija, kas spēj mainÄ«t uzdevuma risināŔanas gaitu. Protams, parasti tev ir pārinieks, bet konsultācijas un padomi vienmēr nav lieki.

Lai uzlabotu Å”o situāciju, mēs ieviesām paņēmiņu "VadÄ«tāja maiņa stand-up sapulcē". Tagad viņi rotē pēc noteikta saraksta, un tam ir savs efekts. Kad pienāk tava kārta, tev ir jāiegremdējas un jāizprot, kas notiek, lai labi vadÄ«tu scrums sapulci.

Infrastructure as Code: kā risināt problēmas ar XP

3. IekŔējais demos. PalÄ«dzÄ«ba uzdevuma risināŔanā no pārÄ« programmÄ“Å”anas, vizualizācija ar uzdevumu koku un palÄ«dzÄ«ba rÄ«ta scrums sapulcēs ā€“ ir labi, bet ne ideāli. PārÄ« tu esi ierobežots tikai ar savām zināŔanām. Uzdevumu koks palÄ«dz globāli saprast, kas un ko dara. Bet vadÄ«tājs un kolēģi no rÄ«ta sapulcē nevar iedziļināties tavās problēmās. Viņi, protams, var kaut ko arÄ« nokavēt.

Risinājums tika atrasts, demonstrējot paveikto darbus cits citam un pēc tam apspriežot tos. Mēs sanākam reizi nedēļā uz stundu un parādām risinājumu detaļas uzdevumiem, kurus esam veikuÅ”i pēdējā nedēļā.

Demonstrācijas procesā ir jāatklāj uzdevuma detaļas un obligāti jāparāda tās darbs.

Ziņojums var tikt veidots pēc kontrolsaraksta.1. Ievietojiet kontekstā. No kurienes radās uzdevums, kāpēc tas vispār bija nepiecieÅ”ams?

2. Kā uzdevums tika risināts iepriekÅ”? Piemēram, bija nepiecieÅ”ama masveida peles klikŔķināŔana, vai arÄ« vispār bija neiespējami kaut ko izdarÄ«t.

3. Kā mēs uzlabojam to. Piemēram: "Skatieties, tagad ir skriptiņŔ, lÅ«k, rÄ«cÄ«bas plāns."

4. Parādiet, kā tas darbojas. Vēlams uzreiz izpildÄ«t kādu lietotāja scenāriju. Gribu X, daru Y, redzu Z. Piemēram, deployoju NGINX, skatos url, iegÅ«stu 200 OK. Ja darbÄ«ba ir ilgstoÅ”a, sagatavojiet iepriekÅ”, lai vēlāk parādÄ«tu. Vēlams jau stundu pirms demo Ä«paÅ”i nesabojāt, ja tas ir trausls.

5. Izskaidrojiet, cik veiksmÄ«gi ir atrisināta problēma, kādas grÅ«tÄ«bas ir palikuÅ”as, kas nav pabeigts, kādas uzlabojumu iespējas pastāv nākotnē. Piemēram, tagad cli, pēc tam bÅ«s pilnÄ«ga automatizācija CI.

Vēlams katram runātājam iztikt 5-10 minÅ«tēs. Ja jÅ«su uzstāŔanās ir bÅ«tiska un aizņems vairāk laika, iepriekÅ” saskaņojiet to kanālā sre-takeover.

Pēc klātienes daļas obligāti seko diskusija threadā. TieÅ”i Å”eit parādās nepiecieÅ”amā atgriezeniskā saite par saviem uzdevumiem.

Infrastructure as Code: kā risināt problēmas ar XP
Noslēgumā tiek veikta anketa, lai noteiktu notikuma lietderÄ«bu. Tas jau ir atgriezeniskā saite par uzstāŔanās bÅ«tÄ«bu un uzdevuma nozÄ«mÄ«gumu.

Infrastructure as Code: kā risināt problēmas ar XP

Garie secinājumi un kas tālāk

Varētu Ŕķist, ka raksta tonis ir nedaudz pesimistisks. Tā nav. Divi pamata lÄ«meņi atgriezeniskās saites iegÅ«Å”anai, proti, testi un pāru programmÄ“Å”ana, strādā. Ne visai ideāli kā tradicionālajā izstrādē, bet ir pozitÄ«vs efekts.

Testi, paÅ”reizējā to formā, sniedz tikai daļēju koda pārklājumu. Daudzas konfigurācijas funkcijas paliek netestētas. To ietekme uz tieÅ”o darbu rakstot kodu ir maza. Tomēr integrācijas testiem ir efekts, un tie tieÅ”i ļauj bezbailÄ«gi veikt refaktoringus. Tas ir liels sasniegums. Ar fokusa pāreju uz augsta lÄ«meņa valodām (mums ir python, go) problēma izzÅ«d. Un uz "lÄ«mes" ir daudz pārbaudes un nav nepiecieÅ”ams, pietiek ar vispārējo integrāciju.

Darbs pāri vairāk ir atkarÄ«gs no konkrētām personām. Ir uzdevuma faktors un mÅ«su soft skills. Ar kādu ir ļoti labi, ar kādu sliktāk. Å im ir noteikti ieguvumi. Skaidrs, ka pat nepietiekama pāru darba noteikumu ievēroÅ”ana pats fakts, ka uzdevumi tiek veikti kopā, pozitÄ«vi ietekmē rezultāta kvalitāti. PersonÄ«gi man pāris darbā ir vieglāk un patÄ«kamāk.

Augstāka lÄ«meņa veidi ietekmes uz OS ā€“ plānoÅ”ana un darbÄ«ba ar uzdevumiem noteikti dod rezultātus: kvalitatÄ«va zināŔanu apmaiņa un izstrādes kvalitātes uzlaboÅ”ana.

ÄŖsi secinājumi vienā teikumā

  • XP prakse strādā IaC, bet ar mazāku efektivitāti.
  • Pastipriniet to, kas strādā.
  • Izdomājiet savus kompensācijas mehānismus un prakses.

Avots: habr.com

Iegādājieties uzticamu tÄ«mekļa hostingu ar DDoS aizsardzÄ«bu, VPS VDS serveriem šŸ”„ Iegādājieties uzticamu tÄ«mekļa hostingu ar DDoS aizsardzÄ«bu, VPS VDS serveriem | ProHoster