Imprastraktura bilang Code: kung paano lampasan ang mga problema gamit ang XP

Hello, Habr! Dati, nagreklamo ako tungkol sa buhay sa Infrastructure bilang code paradigm at hindi nag-aalok ng anumang bagay upang malutas ang kasalukuyang sitwasyon. Ngayon ay bumalik ako para sabihin sa iyo kung anong mga diskarte at kasanayan ang tutulong sa iyo na makatakas mula sa kailaliman ng kawalan ng pag-asa at idirekta ang sitwasyon sa tamang direksyon.

Sa isang nakaraang artikulo "Imprastraktura bilang code: unang kakilala" Ibinahagi ko ang aking mga impression sa lugar na ito, sinubukan kong pagnilayan ang kasalukuyang sitwasyon sa lugar na ito, at nagmungkahi pa na makakatulong ang mga karaniwang kasanayan na alam ng lahat ng developer. Maaaring mukhang maraming mga reklamo tungkol sa buhay, ngunit walang mga panukala para sa isang paraan sa kasalukuyang sitwasyon.

Sino tayo, nasaan tayo at kung ano ang mga problema natin

Kasalukuyan kaming nasa Sre Onboarding Team, na binubuo ng anim na programmer at tatlong inhinyero sa imprastraktura. Sinusubukan nating lahat na magsulat ng Infrastructure bilang code (IaC). Ginagawa namin ito dahil alam namin talaga kung paano magsulat ng code at may kasaysayan ng pagiging "above average" na mga developer.

• Mayroon kaming isang hanay ng mga pakinabang: isang tiyak na background, kaalaman sa mga kasanayan, ang kakayahang magsulat ng code, isang pagnanais na matuto ng mga bagong bagay.
• At mayroong isang sagging bahagi, na isa ring minus: kakulangan ng kaalaman tungkol sa hardware ng imprastraktura.

Ang teknolohiya stack na ginagamit namin sa aming IaC.

• Terraform para sa paglikha ng mga mapagkukunan.
• Packer para sa pag-assemble ng mga imahe. Ito ang mga imahe ng Windows, CentOS 7.
• Jsonnet upang makagawa ng isang malakas na build sa drone.io, gayundin upang makabuo ng packer json at ang aming mga module ng terraform.
• Azure.
• Ansible kapag naghahanda ng mga larawan.
• Python para sa mga auxiliary services at provisioning script.
• At lahat ng ito sa VSCode na may mga plugin na ibinahagi sa pagitan ng mga miyembro ng team.

Konklusyon mula sa aking huling artikulo ay ganito: Sinubukan kong itanim (una sa lahat sa aking sarili) ang optimismo, nais kong sabihin na susubukan natin ang mga diskarte at kasanayan na alam natin upang harapin ang mga paghihirap at kumplikadong umiiral sa lugar na ito.

Kasalukuyan kaming nahihirapan sa mga sumusunod na isyu sa IaC:

• Kakulangan ng mga tool at paraan para sa pagbuo ng code.
• Mabagal na pag-deploy. Ang imprastraktura ay bahagi ng totoong mundo, at maaari itong maging mabagal.
• Kakulangan ng mga diskarte at kasanayan.
• Kami ay bago at hindi gaanong alam.

Extreme Programming (XP) to the rescue

Ang lahat ng mga developer ay pamilyar sa Extreme Programming (XP) at ang mga kasanayan na nasa likod nito. Marami sa atin ang nagtrabaho sa pamamaraang ito, at ito ay naging matagumpay. Kaya bakit hindi gamitin ang mga prinsipyo at gawi na inilatag doon upang malampasan ang mga hamon sa imprastraktura? Nagpasya kaming gawin ang diskarteng ito at tingnan kung ano ang mangyayari.

Sinusuri ang applicability ng XP approach sa iyong industriyaNarito ang isang paglalarawan ng kapaligiran kung saan angkop ang XP, at kung paano ito nauugnay sa amin:

1. Dynamic na pagbabago ng mga kinakailangan sa software. Malinaw sa amin kung ano ang layunin ng pagtatapos. Ngunit ang mga detalye ay maaaring mag-iba. Kami mismo ang nagpapasya kung saan namin kailangang mag-taxi, kaya pana-panahong nagbabago ang mga kinakailangan (pangunahin sa aming sarili). Kung kukunin natin ang pangkat ng SRE, na gumagawa ng automation mismo, at nililimitahan mismo ang mga kinakailangan at saklaw ng trabaho, kung gayon ang puntong ito ay angkop na angkop.

2. Mga panganib na dulot ng mga fixed time na proyekto gamit ang bagong teknolohiya. Maaaring makatagpo tayo ng mga panganib kapag gumagamit ng ilang bagay na hindi natin alam. At ito ay 100% ang aming kaso. Ang aming buong proyekto ay ang paggamit ng mga teknolohiya na hindi namin lubos na pamilyar. Sa pangkalahatan, ito ay isang palaging problema, dahil... Maraming mga bagong teknolohiya ang umuusbong sa sektor ng imprastraktura sa lahat ng oras.

3,4. Maliit, co-located extended development team. Ang automated na teknolohiyang ginagamit mo ay nagbibigay-daan para sa mga unit at functional na pagsubok. Ang dalawang puntong ito ay hindi angkop sa atin. Una, hindi kami coordinated team, at pangalawa, siyam kami, which can be considered a large team. Bagama't, ayon sa ilang mga kahulugan ng isang "malaking" team, marami ang 14+ na tao.

Tingnan natin ang ilang mga kasanayan sa XP at kung paano nakakaapekto ang mga ito sa bilis at kalidad ng feedback.

XP Feedback Loop Prinsipyo

Sa aking pagkakaintindi, feedback ang sagot sa tanong, tama ba ang ginagawa ko, pupunta ba tayo doon? Ang XP ay may divine scheme para dito: isang time feedback loop. Ang kawili-wiling bagay ay na mas mababa tayo, mas mabilis nating makuha ang OS upang sagutin ang mga kinakailangang tanong.

Ito ay isang medyo kawili-wiling paksa para sa talakayan, na sa aming industriya ng IT posible na mabilis na makakuha ng isang OS. Isipin kung gaano kasakit ang gumawa ng isang proyekto sa loob ng anim na buwan at pagkatapos lamang malaman na may pagkakamali sa simula pa lang. Nangyayari ito sa disenyo at sa anumang pagtatayo ng mga kumplikadong sistema.

Sa aming kaso ng IaC, tinutulungan kami ng feedback. Kaagad akong gagawa ng maliit na pagsasaayos sa diagram sa itaas: ang plano sa pagpapalabas ay walang buwanang cycle, ngunit nangyayari nang ilang beses sa isang araw. Mayroong ilang mga kasanayan na nauugnay sa ikot ng OS na ito na titingnan natin nang mas detalyado.

Mahalaga: maaaring maging solusyon ang feedback sa lahat ng problemang nakasaad sa itaas. Kasama ng mga kasanayan sa XP, maaari ka nitong hilahin mula sa kailaliman ng kawalan ng pag-asa.

Paano hilahin ang iyong sarili mula sa kailaliman ng kawalan ng pag-asa: tatlong kasanayan

Mga Pagsubok

Ang mga pagsubok ay binanggit nang dalawang beses sa XP feedback loop. Hindi lang ganun. Napakahalaga ng mga ito para sa buong pamamaraan ng Extreme Programming.

Ipinapalagay na mayroon kang mga pagsubok sa Unit at Pagtanggap. Ang ilan ay nagbibigay sa iyo ng feedback sa loob ng ilang minuto, ang iba sa loob ng ilang araw, kaya mas matagal silang sumulat at hindi gaanong nasusuri.

Mayroong isang klasikong pagsubok na pyramid, na nagpapakita na dapat magkaroon ng higit pang mga pagsubok.

Paano nalalapat sa amin ang balangkas na ito sa isang proyekto ng IaC? Actually... hindi naman.

• Ang mga unit test, sa kabila ng katotohanang dapat marami sa kanila, ay hindi maaaring masyadong marami. O sila ay sumusubok ng isang bagay nang hindi direkta. Sa katunayan, masasabi nating hindi natin ito sinusulat. Ngunit narito ang ilang mga aplikasyon para sa mga naturang pagsubok na nagawa namin:
  1. Pagsubok ng jsonnet code. Ito, halimbawa, ay ang aming drone assembly pipeline, na medyo kumplikado. Ang jsonnet code ay mahusay na sakop ng mga pagsubok.
     Ginagamit namin ito Unit testing framework para sa Jsonnet.
  2. Mga pagsubok para sa mga script na isinasagawa kapag nagsimula ang mapagkukunan. Ang mga script ay nakasulat sa Python, at samakatuwid ang mga pagsubok ay maaaring isulat sa kanila.
• Posibleng suriin ang configuration sa mga pagsubok, ngunit hindi namin ginagawa iyon. Posible ring i-configure ang pagsuri sa mga panuntunan sa pagsasaayos ng mapagkukunan sa pamamagitan ng tflint. Gayunpaman, ang mga tseke doon ay napakasimple para sa terraform, ngunit maraming mga script ng pagsubok ang isinulat para sa AWS. At nasa Azure kami, kaya hindi na ito nalalapat muli.
• Mga pagsubok sa pagsasama ng bahagi: depende ito sa kung paano mo inuuri ang mga ito at kung saan mo ito inilalagay. Ngunit karaniwang gumagana sila.

  Ganito ang hitsura ng mga integration test.

  
  
  Ito ay isang halimbawa kapag gumagawa ng mga imahe sa Drone CI. Upang maabot sila, kailangan mong maghintay ng 30 minuto para mabuo ang imahe ng Packer, pagkatapos ay maghintay ng isa pang 15 minuto para makapasa sila. Ngunit mayroon sila!

  Algoritmo ng pag-verify ng larawan

  1. Dapat munang ganap na ihanda ng Packer ang imahe.
  2. Sa tabi ng pagsubok ay mayroong isang terraform na may lokal na estado, na ginagamit namin upang i-deploy ang larawang ito.
  3. Kapag binubuksan, isang maliit na module na nakalatag sa malapit ay ginagamit upang gawing mas madaling gamitin ang imahe.
  4. Kapag na-deploy na ang VM mula sa larawan, maaaring magsimula ang mga pagsusuri. Karaniwan, ang mga tseke ay isinasagawa sa pamamagitan ng kotse. Sinusuri nito kung paano gumagana ang mga script sa pagsisimula at kung paano gumagana ang mga daemon. Upang gawin ito, sa pamamagitan ng ssh o winrm nag-log in kami sa bagong itinaas na makina at tinitingnan ang katayuan ng pagsasaayos o kung ang mga serbisyo ay tapos na.

• Ang sitwasyon ay katulad ng mga pagsubok sa pagsasama sa mga module para sa terraform. Narito ang isang maikling talahanayan na nagpapaliwanag ng mga tampok ng naturang mga pagsubok.

  
  
  Ang feedback sa pipeline ay humigit-kumulang 40 minuto. Ang lahat ay nangyayari sa napakahabang panahon. Maaari itong gamitin para sa regression, ngunit para sa bagong pag-unlad ito ay karaniwang hindi makatotohanan. Kung ikaw ay napaka, handa na para dito, maghanda ng mga tumatakbong script, pagkatapos ay maaari mong bawasan ito sa 10 minuto. Ngunit hindi pa rin ito mga Unit test, na gumagawa ng 5 piraso sa loob ng 100 segundo.

Ang kawalan ng mga Unit test kapag nag-assemble ng mga imahe o terraform modules ay naghihikayat sa paglipat ng trabaho sa hiwalay na mga serbisyo na maaaring patakbuhin lamang sa pamamagitan ng REST, o sa mga script ng Python.

Halimbawa, kailangan naming tiyakin na kapag nagsimula ang virtual machine, irerehistro nito ang sarili nito sa serbisyo ScaleFT, at nang nawasak ang virtual machine, tinanggal nito ang sarili nito.

Dahil mayroon kaming ScaleFT bilang isang serbisyo, napipilitan kaming magtrabaho kasama nito sa pamamagitan ng API. May nakasulat doon na wrapper na maaari mong hilahin at sabihing: "Pumasok at tanggalin ito at iyon." Iniimbak nito ang lahat ng kinakailangang setting at pag-access.

Maaari na tayong sumulat ng mga normal na pagsubok para dito, dahil hindi ito naiiba sa ordinaryong software: ang ilang uri ng apiha ay kinukutya, hinila mo ito, at tingnan kung ano ang mangyayari.

Mga resulta ng mga pagsubok: Ang pagsubok sa yunit, na dapat magbigay ng OS sa isang minuto, ay hindi nagbibigay nito. At ang mga uri ng pagsubok na mas mataas sa pyramid ay epektibo, ngunit sumasaklaw lamang sa bahagi ng mga problema.

Ipares ang programming

Ang mga pagsubok ay, siyempre, mabuti. Maaari mong isulat ang marami sa kanila, maaari silang maging ng iba't ibang uri. Gagawin nila ang kanilang mga antas at bibigyan kami ng feedback. Ngunit nananatili ang problema sa mga hindi magandang Unit test, na nagbibigay ng pinakamabilis na OS. Kasabay nito, gusto ko pa rin ng mabilis na OS na madali at kaaya-ayang gamitin. Hindi banggitin ang kalidad ng resultang solusyon. Sa kabutihang palad, may mga diskarteng makakapagbigay ng mas mabilis na feedback kaysa sa mga unit test. Ito ay pares programming.

Kapag nagsusulat ng code, gusto mong makakuha ng feedback sa kalidad nito sa lalong madaling panahon. Oo, maaari mong isulat ang lahat sa isang feature na sangay (para hindi masira ang anuman para sa sinuman), gumawa ng pull request sa Github, italaga ito sa isang tao na may timbang ang opinyon, at maghintay ng tugon.

Ngunit maaari kang maghintay ng mahabang panahon. Ang mga tao ay abala lahat, at ang sagot, kahit na mayroon, ay maaaring hindi sa pinakamataas na kalidad. Ipagpalagay na ang sagot ay dumating kaagad, ang reviewer ay agad na naunawaan ang buong ideya, ngunit ang sagot ay dumating pa rin huli, pagkatapos ng katotohanan. sana mas maaga. Ito ang layunin ng pares programming – kaagad, sa oras ng pagsulat.

Nasa ibaba ang pares na mga istilo ng programming at ang kanilang pagiging angkop sa pagtatrabaho sa IaC:

1. Classic, Experienced+Experienced, shift by timer. Dalawang tungkulin - driver at navigator. Dalawang tao. Gumagana sila sa parehong code at lumipat ng mga tungkulin pagkatapos ng isang tiyak na paunang natukoy na yugto ng panahon.

Isaalang-alang natin ang pagiging tugma ng ating mga problema sa istilo:

• Problema: di-kasakdalan ng mga tool at tool para sa pagbuo ng code.
  Negatibong epekto: mas matagal itong umuunlad, bumabagal tayo, nawawala ang takbo/ritmo ng trabaho.
  Paano kami lumaban: gumagamit kami ng ibang tooling, isang karaniwang IDE at natututo din ng mga shortcut.
• Problema: Mabagal na pag-deploy.
  Negatibong epekto: pinapataas ang oras na kinakailangan upang lumikha ng gumaganang piraso ng code. Naiinip kami habang naghihintay, nag-aabot ang mga kamay namin para gumawa ng iba habang naghihintay.
  Paano tayo lumaban: hindi natin ito nalampasan.
• Problema: kakulangan ng mga diskarte at kasanayan.
  Negatibong epekto: walang kaalaman kung paano ito gagawin nang maayos at kung paano ito gagawin nang hindi maganda. Pinapahaba ang pagtanggap ng feedback.
  Paano tayo lumaban: ang pagpapalitan ng mga opinyon at kasanayan sa magkapares na trabaho ay halos malulutas ang problema.

Ang pangunahing problema sa paggamit ng istilong ito sa IaC ay ang hindi pantay na bilis ng trabaho. Sa tradisyunal na software development, mayroon kang isang napaka-pantay na paggalaw. Maaari kang gumugol ng limang minuto at isulat ang N. Gumugol ng 10 minuto at isulat ang 2N, 15 minuto - 3N. Dito maaari kang gumugol ng limang minuto at isulat ang N, at pagkatapos ay gumugol ng isa pang 30 minuto at isulat ang ikasampu ng N. Dito wala kang alam, natigil ka, tanga. Ang pagsisiyasat ay tumatagal ng oras at nakakagambala sa mismong programming.

Konklusyon: sa dalisay na anyo nito ay hindi angkop para sa atin.

2. Ping-pong. Ang diskarte na ito ay nagsasangkot ng isang tao na sumulat ng pagsusulit at isa pang gumagawa ng pagpapatupad para dito. Isinasaalang-alang ang katotohanan na ang lahat ay kumplikado sa mga pagsubok sa Unit, at kailangan mong magsulat ng isang pagsubok sa pagsasama na tumatagal ng mahabang panahon upang mag-program, ang lahat ng kadalian ng ping-pong ay mawawala.

Masasabi kong sinubukan naming paghiwalayin ang mga responsibilidad para sa pagdidisenyo ng test script at pagpapatupad ng code para dito. Isang kalahok ang nakaisip ng script, sa bahaging ito ng trabaho siya ang may pananagutan, siya ang may huling salita. At ang isa ay responsable para sa pagpapatupad. Ito ay gumana nang maayos. Ang kalidad ng script na may ganitong paraan ay tumataas.

Konklusyon: sayang, ang bilis ng trabaho ay hindi pinapayagan ang paggamit ng ping-pong bilang isang pares na kasanayan sa programming sa IaC.

3.Malakas na Estilo. Mahirap na pagsasanay. Ang ideya ay ang isang kalahok ay nagiging direktiba navigator, at ang pangalawa ay tumatagal ng tungkulin ng driver ng pagpapatupad. Sa kasong ito, ang karapatang gumawa ng mga pagpapasya ay nakasalalay lamang sa navigator. Ang driver ay nagpi-print lamang at maaaring makaimpluwensya sa kung ano ang nangyayari sa isang salita. Ang mga tungkulin ay hindi nagbabago sa mahabang panahon.

Mabuti para sa pag-aaral, ngunit nangangailangan ng malakas na soft skills. Dito kami nangalumbaba. Ang pamamaraan ay mahirap. At hindi ito tungkol sa imprastraktura.

Konklusyon: maaari itong magamit, hindi kami sumusuko sa pagsubok.

4. Mobbing, swarming at lahat ng kilala ngunit hindi nakalistang mga istilo Hindi namin ito isinasaalang-alang, dahil Hindi pa namin ito sinubukan at imposibleng pag-usapan ito sa konteksto ng aming trabaho.

Mga pangkalahatang resulta sa paggamit ng pares na programming:

• Mayroon kaming hindi pantay na bilis ng trabaho, na nakakalito.
• Naranasan namin ang hindi sapat na mahusay na soft skills. At hindi nakakatulong ang subject area na malampasan itong mga pagkukulang natin.
• Ang mahabang pagsubok at mga problema sa mga tool ay nagpapahirap sa pagpapares na pag-unlad.

5. Sa kabila nito, may mga tagumpay. Nakabuo kami ng sarili naming pamamaraan na "Convergence - Divergence". Ilalarawan ko nang maikli kung paano ito gumagana.

Mayroon kaming mga permanenteng kasosyo sa loob ng ilang araw (wala pang isang linggo). Magkasama kaming gumagawa ng isang gawain. Umupo kami saglit: ang isa ay nagsusulat, ang isa ay nakaupo at nanonood ng koponan ng suporta. Pagkatapos ay naghiwa-hiwalay kami ng ilang oras, bawat isa ay gumagawa ng ilang mga independiyenteng bagay, pagkatapos ay nagsasama-sama kaming muli, mabilis na nagsi-synchronize, gumawa ng isang bagay nang magkasama at muling naghiwa-hiwalay.

Pagpaplano at komunikasyon

Ang huling bloke ng mga kasanayan kung saan nalulutas ang mga problema sa OS ay ang organisasyon ng trabaho sa mga gawain mismo. Kasama rin dito ang pagpapalitan ng karanasan na nasa labas ng gawaing pares. Tingnan natin ang tatlong kasanayan:

1. Mga layunin sa pamamagitan ng puno ng layunin. Inayos namin ang pangkalahatang pamamahala ng proyekto sa pamamagitan ng isang puno na walang katapusan sa hinaharap. Sa teknikal, ang pagsubaybay ay ginagawa sa Miro. May isang gawain - ito ay isang intermediate na layunin. Mula dito pumunta ang alinman sa mas maliliit na layunin o grupo ng mga gawain. Ang mga gawain mismo ay nagmula sa kanila. Ang lahat ng mga gawain ay nilikha at pinananatili sa board na ito.

Nagbibigay din ang scheme na ito ng feedback, na nangyayari isang beses sa isang araw kapag nagsi-synchronize kami sa mga rally. Ang pagkakaroon ng isang karaniwang plano sa harap ng lahat, ngunit nakabalangkas at ganap na bukas, ay nagbibigay-daan sa lahat na magkaroon ng kamalayan sa kung ano ang nangyayari at kung gaano kalayo ang ating pag-unlad.

Mga kalamangan ng visual vision ng mga gawain:

• Dahilan. Ang bawat gawain ay humahantong sa ilang pandaigdigang layunin. Ang mga gawain ay pinagsama-sama sa mas maliliit na layunin. Ang domain ng imprastraktura mismo ay medyo teknikal. Hindi laging malinaw kung anong partikular na epekto, halimbawa, ang pagsusulat ng runbook sa paglipat sa ibang nginx sa negosyo. Ang pagkakaroon ng target na card sa malapit ay ginagawang mas malinaw.
  
  Ang sanhi ay isang mahalagang katangian ng mga problema. Direktang sinasagot nito ang tanong na: "Tama ba ang ginagawa ko?"
• Paralelismo. Siyam kami, at imposibleng pisikal na itapon ang lahat sa isang gawain. Maaaring hindi palaging sapat ang mga gawain mula sa isang lugar. Napipilitan tayong iparallelize ang trabaho sa pagitan ng maliliit na grupong nagtatrabaho. Kasabay nito, ang mga grupo ay nakaupo sa kanilang gawain nang ilang oras, maaari silang palakasin ng ibang tao. Minsan ang mga tao ay lumalayo sa grupong ito ng trabaho. May nagbabakasyon, may gumagawa ng report para sa DevOps conf, may nagsusulat ng artikulo sa Habr. Ang pag-alam kung anong mga layunin at gawain ang maaaring gawin nang magkatulad ay nagiging napakahalaga.

2. Mga kapalit na nagtatanghal ng mga pulong sa umaga. Sa mga stand-up mayroon tayong problemang ito - ang mga tao ay gumagawa ng maraming gawain nang magkatulad. Minsan ang mga gawain ay maluwag na konektado at walang pag-unawa sa kung sino ang gumagawa ng kung ano. At ang opinyon ng isa pang miyembro ng koponan ay napakahalaga. Ito ay karagdagang impormasyon na maaaring magbago sa kurso ng paglutas ng problema. Siyempre, kadalasan ay may kasama ka, ngunit laging nakakatulong ang mga payo at tip.

Upang mapabuti ang sitwasyong ito, ginamit namin ang diskarteng "Pagbabago sa Nangungunang Stand-Up". Ngayon sila ay pinaikot ayon sa isang tiyak na listahan, at ito ay may epekto nito. Kapag turn mo na, mapipilitan kang sumisid at maunawaan kung ano ang nangyayari para makapagpatakbo ng isang mahusay na pulong ng Scrum.

3. Panloob na demo. Ang tulong sa paglutas ng problema mula sa pares programming, visualization sa problem tree at tulong sa mga scrum meeting sa umaga ay mabuti, ngunit hindi perpekto. Bilang mag-asawa, nalilimitahan lamang kayo ng inyong kaalaman. Nakakatulong ang task tree na maunawaan sa buong mundo kung sino ang gumagawa ng ano. At ang nagtatanghal at mga kasamahan sa pulong sa umaga ay hindi sumisid nang malalim sa iyong mga problema. Tiyak na maaari silang makaligtaan ng isang bagay.

Ang solusyon ay natagpuan sa pagpapakita ng gawaing ginawa sa isa't isa at pagkatapos ay talakayin ito. Nagkikita kami minsan sa isang linggo sa loob ng isang oras at nagpapakita ng mga detalye ng mga solusyon sa mga gawaing nagawa namin sa nakalipas na linggo.

Sa panahon ng demonstrasyon, kinakailangan upang ipakita ang mga detalye ng gawain at siguraduhing ipakita ang operasyon nito.

Maaaring isagawa ang ulat gamit ang checklist.1. Ipasok sa konteksto. Saan nagmula ang gawain, bakit kailangan pa?

2. Paano nalutas ang problema noon? Halimbawa, kailangan ang napakalaking pag-click ng mouse, o imposibleng gumawa ng kahit ano.

3. Paano natin ito pinagbubuti. Halimbawa: "Tingnan mo, ngayon ay may scriptosik, narito ang readme."

4. Ipakita kung paano ito gumagana. Maipapayo na direktang ipatupad ang ilang senaryo ng user. Gusto ko X, ginagawa ko Y, nakikita ko Y (o Z). Halimbawa, nag-deploy ako ng NGINX, naninigarilyo sa url, at nakakuha ng 200 OK. Kung mahaba ang aksyon, ihanda ito nang maaga para maipakita mo ito sa ibang pagkakataon. Maipapayo na huwag itong sirain nang labis isang oras bago ang demo, kung ito ay marupok.

5. Ipaliwanag kung gaano matagumpay na nalutas ang problema, anong mga paghihirap ang natitira, ano ang hindi nakumpleto, anong mga pagpapabuti ang posible sa hinaharap. Halimbawa, ngayon CLI, pagkatapos ay magkakaroon ng ganap na automation sa CI.

Maipapayo para sa bawat tagapagsalita na panatilihin ito sa 5-10 minuto. Kung malinaw na mahalaga ang iyong pananalita at magtatagal, i-coordinate ito nang maaga sa channel ng sre-takeover.

Pagkatapos ng face-to-face part ay laging may talakayan sa thread. Dito lumalabas ang feedback na kailangan natin sa ating mga gawain.

Bilang resulta, ang isang survey ay isinasagawa upang matukoy ang pagiging kapaki-pakinabang ng kung ano ang nangyayari. Ito ay puna sa kakanyahan ng talumpati at kahalagahan ng gawain.

Mahabang konklusyon at kung ano ang susunod

Maaaring tila ang tono ng artikulo ay medyo pessimistic. Mali ito. Dalawang mas mababang antas ng feedback, katulad ng mga pagsubok at pares programming, gumagana. Hindi kasing perpekto ng tradisyonal na pag-unlad, ngunit may positibong epekto mula rito.

Ang mga pagsubok, sa kanilang kasalukuyang anyo, ay nagbibigay lamang ng bahagyang saklaw ng code. Maraming mga pag-andar sa pagsasaayos ang hindi nasusubok. Ang kanilang impluwensya sa aktwal na gawain kapag ang pagsulat ng code ay mababa. Gayunpaman, mayroong isang epekto mula sa mga pagsubok sa pagsasama, at pinapayagan ka nitong walang takot na magsagawa ng mga refactorings. Ito ay isang mahusay na tagumpay. Gayundin, sa paglipat ng pokus sa pag-unlad sa mataas na antas ng mga wika (mayroon kaming python, go), ang problema ay nawala. At hindi mo kailangan ng maraming tseke para sa "glue"; sapat na ang isang pangkalahatang integration check.

Ang pagtatrabaho nang magkapares ay higit na nakasalalay sa mga partikular na tao. Nandiyan ang task factor at ang soft skills natin. Sa ilang mga tao ito ay gumagana nang mahusay, sa iba ito ay mas masahol pa. Tiyak na may mga benepisyo mula dito. Malinaw na kahit na hindi sapat na sinusunod ang mga patakaran ng pares ng trabaho, ang mismong katotohanan ng pagsasagawa ng mga gawain nang magkasama ay may positibong epekto sa kalidad ng resulta. Sa personal, mas madali at mas kasiya-siya ang pagtatrabaho nang magkapares.

Ang mga mas mataas na antas na paraan ng pag-impluwensya sa OS - ang pagpaplano at pagtatrabaho sa mga gawain ay tiyak na gumagawa ng mga epekto: mataas na kalidad na pagpapalitan ng kaalaman at pinahusay na kalidad ng pag-unlad.

Maikling konklusyon sa isang linya

• Nagtatrabaho ang mga HR practitioner sa IaC, ngunit mas mababa ang kahusayan.
• Palakasin kung ano ang gumagana.
• Bumuo ng iyong sariling mga mekanismo at kasanayan sa pagbabayad.

Pinagmulan: www.habr.com