Infrastruttura cum'è Codice: cumu superà i prublemi cù XP

Ciao, Habr! Nanzu, aghju lagnatu di a vita in l'Infrastruttura cum'è paradigma di codice è ùn offre nunda per risolve a situazione attuale. Oghje sò tornatu per dì ciò chì avvicinamenti è pratiche vi aiuterà à scappà da l'abissu di a disperazione è guidà a situazione in a direzione ghjusta.

In l'articulu precedente "Infrastruttura cum'è codice: prima cunniscenza" Aghju spartutu e mo impressioni di questa zona, pruvatu à riflette nantu à a situazione attuale in questa zona, è ancu suggeriu chì e pratiche standard cunnisciute da tutti i sviluppatori puderanu aiutà. Puderia sembrà chì ci era assai lagnanza di a vita, ma ùn ci era micca pruposte per una manera di esce da a situazione attuale.

Quale simu, induve simu è chì prublemi avemu

Semu attualmente in u Sre Onboarding Team, chì hè custituitu da sei programatori è trè ingegneri di infrastruttura. Avemu tutti pruvà à scrive Infrastruttura cum'è codice (IaC). Facemu questu perchè sapemu in fondu cumu scrive u codice è avè una storia di esse sviluppatori "sopra à a media".

• Avemu un inseme di vantaghji: un certu sfondate, cunniscenze di pratiche, a capacità di scrive codice, un desideriu di amparà cose novi.
• E ci hè una parte sagging, chì hè ancu un minus: mancanza di cunniscenze nantu à u hardware di l'infrastruttura.

A pila di tecnulugia chì usemu in u nostru IaC.

• Terraform per creà risorse.
• Packer per l'assemblea di l'imaghjini. Quessi sò Windows, imagine CentOS 7.
• Jsonnet per fà una custruzione putente in drone.io, è ancu per generà packer json è i nostri moduli terraform.
• Azur.
• Ansible quandu preparanu l'imaghjini.
• Python per i servizii ausiliarii è i script di furnizzioni.
• È tuttu questu in VSCode cù plugins spartuti trà i membri di a squadra.

Conclusioni da u mo ultimu articulu era cusì : aghju pruvatu à inculcà (prima di tuttu in mè) ottimisimu, vulia dì chì pruveremu l'approcciu è e pratiche cunnisciute da noi per trattà e difficultà è cumplessità chì ci sò in stu spaziu.

Attualmente, avemu a lotta cù i seguenti prublemi IaC:

• Imperfezzione di l'arnesi è i mezi per u sviluppu di codice.
• Implementazione lenta. L'infrastruttura hè parti di u mondu reale, è pò esse lentu.
• Mancanza di approcci è pratiche.
• Semu novi è ùn sapemu micca assai.

Extreme Programming (XP) in salvezza

Tutti i sviluppatori sò familiarizati cù a Programmazione Extreme (XP) è e pratiche chì stanu daretu. Parechji di noi anu travagliatu cù questu approcciu, è hè successu. Allora perchè micca aduprà i principii è e pratiche stabilite quì per superà e sfide di l'infrastruttura? Avemu decisu di piglià stu approcciu è vede ciò chì succede.

Verificate l'applicabilità di l'approcciu XP à a vostra industriaEccu una descrizzione di l'ambiente chì XP hè bè adattatu per, è cumu si tratta di noi:

1. Esigenze di u software chì cambianu dinamicamente. Era chjaru per noi quale era u scopu finale. Ma i dettagli ponu varià. Noi stessi decidemu induve avemu bisognu di taxi, cusì i requisiti cambianu periodicamente (principalmente da noi stessi). Se pigliemu a squadra SRE, chì face l'automatizazione stessu, è ellu stessu limita i requisiti è u scopu di u travagliu, allora stu puntu si mette bè.

2. Risichi causati da i prughjetti di tempu fissu cù a nova tecnulugia. Pudemu scontru risichi quandu usendu cose scunnisciute per noi. È questu hè 100% u nostru casu. U nostru prughjettu tutale era l'usu di tecnulugii chì ùn eramu micca completamente familiarizati. In generale, questu hè un prublema constante, perchè ... Ci sò parechje tecnulugia novi emergenti in u settore di l'infrastruttura tuttu u tempu.

3,4. Piccola squadra di sviluppu allargata co-locata. A tecnulugia automatizata chì site aduprate permette teste unità è funziunali. Sti dui punti ùn ci cunvene micca bè. Prima, ùn simu micca una squadra coordinata, è in segundu, ci sò nove di noi, chì ponu esse cunsideratu un grande squadra. Ancu s'è, sicondu qualchi definizione di una squadra "grande", assai hè 14+ persone.

Fighjemu alcune pratiche XP è cumu affettanu a velocità è a qualità di feedback.

XP Feedback Loop Principiu

In u mo capiscimentu, u feedback hè a risposta à a quistione, aghju fattu u dirittu, andemu quì? XP hà un schema divinu per questu: un ciclu di feedback di u tempu. L'interessante hè chì u più bassu simu, u più veloce simu capaci di ottene l'OS per risponde à e dumande necessarie.

Questu hè un tema piuttostu interessante per a discussione, chì in a nostra industria IT hè pussibule di ottene rapidamente un OS. Imagine quantu dulurosu hè di fà un prughjettu per sei mesi è solu dopu scopre chì ci hè statu un sbagliu à u principiu. Questu succede in u disignu è in ogni custruzzione di sistemi cumplessi.

In u nostru casu di IaC, u feedback ci aiuta. Immediatamente fà un picculu aghjustamentu à u diagramma sopra: u pianu di liberazione ùn hà micca un ciculu mensu, ma si trova parechje volte à ghjornu. Ci sò qualchi pratiche ligati à stu ciclu OS chì avemu da fighjulà in più dettu.

Impurtante: u feedback pò esse una suluzione à tutti i prublemi dichjarati sopra. Cumminatu cù e pratiche XP, pò tirà fora di l'abissu di a disperazione.

Cumu tirà fora di l'abissu di a disperazione: trè pratiche

Testi

I testi sò citati duie volte in u ciclu di feedback XP. Ùn hè micca solu cusì. Sò assai impurtanti per tutta a tecnica di Programmazione Extreme.

Hè presumitu chì avete teste Unità è Accettazione. Certi vi danu feedback in pochi minuti, altri in pochi ghjorni, cusì piglianu più tempu per scrive è sò rivisitati menu spessu.

Ci hè una piramide di prova classica, chì mostra chì ci deve esse più teste.

Cumu si applica stu quadru à noi in un prughjettu IaC? In verità... micca in tuttu.

• I testi di unità, malgradu u fattu chì ci deve esse assai, ùn ponu esse troppu. O anu pruvatu qualcosa assai indirettu. In fatti, pudemu dì chì ùn li scrivimu micca in tuttu. Ma quì sò uni pochi di applicazioni per tali teste chì avemu pussutu fà:
  1. Pruvate u codice jsonnet. Questu, per esempiu, hè u nostru pipeline di assemblea di drone, chì hè abbastanza cumplicatu. U codice jsonnet hè ben coperto da e teste.
     Avemu aduprà questu Quadru di prova di unità per Jsonnet.
  2. Testi per i script chì sò eseguiti quandu a risorsa principia. I scripts sò scritti in Python, è dunque e teste ponu esse scritte nantu à elli.
• Hè potenziale pussibule di verificà a cunfigurazione in teste, ma ùn facemu micca. Hè ancu pussibule di cunfigurà e regule di cunfigurazione di risorsa di cuntrollu via tflint. Tuttavia, i cuntrolli sò simpliciamente troppu basi per terraform, ma assai script di teste sò scritti per AWS. È simu in Azure, cusì questu novu ùn hè micca applicatu.
• Test d'integrazione di cumpunenti: dipende da cumu si classificà è induve i mette. Ma basamente travaglianu.

  Eccu ciò chì i testi di integrazione parenu.

  
  
  Questu hè un esempiu di custruisce l'imaghjini in Drone CI. Per ghjunghje à elli, duvete aspittà 30 minuti per a forma di l'imaghjini di Packer, dopu aspittà altri 15 minuti per passà. Ma esistinu !

  Algoritmu di verificazione di l'imagine

  1. Packer deve prima preparà l'imaghjini cumpletamente.
  2. Accantu à a prova ci hè una terraforma cù un statu lucale, chì avemu usatu per implementà sta maghjina.
  3. Quandu si sviluppa, un picculu modulu chì si trova vicinu hè utilizatu per fà più faciule di travaglià cù l'imaghjini.
  4. Una volta chì a VM hè implementata da l'imaghjini, i cuntrolli ponu principià. In fondu, i cuntrolli sò realizati in vittura. Cuntrolla cumu si travagliavanu i script à l'iniziu è cumu funzionanu i demoni. Per fà questu, via ssh o winrm avemu logu in a macchina appena rialzata è verificate u statutu di cunfigurazione o se i servizii sò up.

• A situazione hè simile cù testi di integrazione in moduli per terraform. Eccu una tavula corta chì spiega e caratteristiche di tali teste.

  
  
  Feedback nantu à u pipeline hè di circa 40 minuti. Tuttu succede per un tempu assai longu. Pò esse usatu per a regressione, ma per u novu sviluppu hè generalmente irrealisticu. Sè vo site assai, assai preparatu per questu, preparanu script in esecuzione, allora pudete riduce à 10 minuti. Ma quessi ùn sò ancora testi Unità, chì facenu 5 pezzi in 100 seconde.

L'absenza di teste Unità quandu si assemblanu l'imaghjini o i moduli di terraformi incuragisce à trasfurmà u travagliu à i servizii separati chì ponu esse simpliciamente eseguiti via REST, o à script Python.

Per esempiu, avemu bisognu di assicurà chì quandu a macchina virtuale principia, si registra in u serviziu ScaleFT, è quandu a macchina virtuale hè stata distrutta, s'hè sguassata.

Siccomu avemu ScaleFT cum'è serviziu, simu furzati à travaglià cun ellu attraversu l'API. C'era un involucro scrittu quì chì pudete tirà è dì: "Entra è sguassate questu è quellu". Guarda tutti i paràmetri necessarii è accessi.

Pudemu digià scrive testi normali per questu, postu chì ùn hè micca sfarente di u software ordinariu: un tipu d'apiha hè burlatu, tira, è vede ciò chì succede.

Risultati di e teste: Unità di prova, chì deve dà u OS in un minutu, ùn dà micca. E tipi di teste più altu in a piramide sò efficaci, ma copre solu una parte di i prublemi.

Prugrammazione di coppia

I testi sò, sicuru, boni. Pudete scrive assai di elli, ponu esse di diversi tipi. Travaglieranu à i so livelli è ci daranu feedback. Ma u prublema cù i testi Unità male, chì dà u OS più veloce, ferma. À u listessu tempu, vogliu sempre un OS veloce chì hè faciule è piacevule per travaglià. Senza parlà di a qualità di a suluzione resultanti. Fortunatamente, ci sò tecniche chì ponu furnisce un feedback ancu più veloce cà e teste di unità. Questu hè un prugramma di coppia.

Quandu scrivite u codice, vulete uttene feedback nantu à a so qualità u più prestu pussibule. Iè, pudete scrive tuttu in un ramu di funziunalità (per ùn rompe nunda per nimu), fate una dumanda di pull in Github, assignalu à qualchissia chì l'opinione hà pesu, è aspettate una risposta.

Ma pudete aspittà assai tempu. A ghjente hè tutta occupata, è a risposta, ancu s'ellu ci hè una, pò esse micca di a più alta qualità. Suppone chì a risposta hè ghjunta subitu, u criticu hà capitu istantaneamente tutta l'idea, ma a risposta hè sempre tardi, dopu à u fattu. Mi piacerebbe chì era prima. Hè ciò chì u prugramma di coppia hè destinatu - subitu, à u mumentu di a scrittura.

Quì sottu sò i stili di prugrammazione di coppia è a so applicabilità in u travagliu nantu à IaC:

1. Classic, Esperienza + Esperienza, cambia per timer. Dui roli - cunduttore è navigatore. Dui parsoni. U travagliu nantu à u listessu codice è cambianu roli dopu un certu periodu di tempu predeterminatu.

Fighjemu a cumpatibilità di i nostri prublemi cù u stilu:

• Prublemu: imperfezzione di arnesi è arnesi per u sviluppu di codice.
  Impattu negativu : ci vole più longu à sviluppà, rallentemu, u ritmu/ritmu di u travagliu si perde.
  Cumu luttàmu: usemu un strumentu diversu, un IDE cumunu è ancu amparà i shortcuts.
• Prublemu: implementazione lenta.
  Impattu negativu: aumenta u tempu necessariu per creà un pezzu di codice di travagliu. Ci si annoia mentre aspittemu, e nostre mani stendenu per fà qualcosa d'altru mentre aspittemu.
  Cumu luttàmu: ùn l'avemu micca superatu.
• Prublemu: mancanza di avvicinamenti è pratiche.
  Impattu negativu: ùn ci hè micca sapè cumu fà bè è cumu fà male. Allunga a ricezione di feedback.
  Cumu luttàmu: u scambiu mutuale d'opinioni è di pratiche in u travagliu in coppia risolve quasi u prublema.

U prublema principali cù l'usu di stu stile in IaC hè u ritmu irregulare di u travagliu. In u sviluppu di software tradiziunale, avete un muvimentu assai uniforme. Pudete passà cinque minuti è scrive N. Passate 10 minuti è scrive 2N, 15 minuti - 3N. Quì pudete passà cinque minuti è scrivite N, è dopu passate altri 30 minuti è scrivite una decima di N. Quì ùn si sà nunda, site stuck, stupidu. L'investigazione piglia u tempu è distracte da u prugramma stessu.

Conclusioni: in a so forma pura ùn hè micca adattatu per noi.

2. Ping-pong. Stu approcciu implica una persona chì scrive u test è un altru chì faci l'implementazione per questu. Pigliendu u fattu chì tuttu hè cumplicatu cù e teste Unità, è avete à scrive una prova di integrazione chì piglia assai tempu per u prugramma, tutte e facilità di ping-pong si ne vanu.

Puderaghju dì chì avemu pruvatu à separà e responsabilità per u disignu di un script di prova è l'implementazione di codice per questu. Un participante ghjunse cù u script, in questa parte di u travagliu era rispunsevuli, avia l'ultima parola. È l'altru era rispunsevule per l'implementazione. Funziona bè. A qualità di u script cù questu approcciu aumenta.

Conclusioni: sfortunatamente, u ritmu di u travagliu ùn permette micca l'usu di u ping-pong cum'è una pratica di prugrammazione par in IaC.

3.Stile forte. Pratica difficiule. L'idea hè chì un participante diventa u navigatore direttu, è u sicondu piglia u rolu di u driver di esecutivu. In questu casu, u dirittu di piglià decisioni hè solu à u navigatore. U driver stampa solu è pò influenzà ciò chì succede cù una parolla. I roli ùn cambianu per un bellu pezzu.

Bonu per l'apprendimentu, ma esige forti cumpetenze dolci. Hè quì chì avemu falciatu. A tecnica era difficiule. È ùn si tratta ancu di infrastruttura.

Conclusioni: pò esse potenzialmente utilizatu, ùn rinunciamu micca à pruvà.

4. Mobbing, swarming è tutti i stili cunnisciuti ma micca listati Ùn avemu micca cunsideratu, perchè Ùn avemu micca pruvatu è hè impussibile di parlà in u cuntestu di u nostru travagliu.

Risultati generali nantu à l'usu di a prugrammazione di coppia:

• Avemu un ritmu irregulare di travagliu, chì hè cunfusu.
• Avemu intruduciutu cumpetenze soft insuffisentemente bè. È l'area di u sughjettu ùn aiuta micca à superà queste mancanze di i nostri.
• I testi longu è i prublemi cù l'arnesi facenu difficultà u sviluppu paru.

5. Malgradu questu, ci sò successi. Avemu ghjuntu cù u nostru propiu metudu "Convergenza - Divergenza". Descriveraghju brevemente cumu funziona.

Avemu partenarii permanenti per uni pochi di ghjorni (menu di una settimana). Facemu un compitu inseme. Ci si mette inseme un pocu tempu : unu scrive, l'altru si mette è fighjulà a squadra di sustegnu. Allora sparghjemu per qualchì tempu, ognuna face alcune cose indipindenti, dopu avemu riunitu di novu, sincronizemu assai rapidamente, fate qualcosa inseme è sparghjemu di novu.

Pianificazione è cumunicazione

L'ultimu bloccu di pratiche per via di quale i prublemi OS sò risolti hè l'urganizazione di u travagliu cù i travaglii stessi. Questu include ancu u scambiu di sperienza chì hè fora di u travagliu di coppia. Fighjemu trè pratiche:

1. Ugettivi attraversu l'arburu di u scopu. Avemu urganizatu a gestione generale di u prugettu per mezu di un arbre chì và senza fine in u futuru. Tecnicamente, u seguimentu hè fattu in Miro. Ci hè un compitu - hè un scopu intermediu. Da ellu passanu o scopi più chjuchi o gruppi di tarei. I travaglii stessi venenu da elli. Tutti i travaglii sò creati è mantinuti nantu à questu bordu.

Stu schema furnisce ancu feedback, chì si trova una volta à ghjornu quandu sincronizemu in manifestazioni. Avè un pianu cumunu davanti à tutti, ma strutturatu è cumpletamente apertu, permette à tutti di esse cuscenti di ciò chì succede è di quantu avemu avanzatu.

Vantaghji di a visione visuale di i travaglii:

• Causalità. Ogni compitu porta à qualchì scopu globale. I travaglii sò raggruppati in scopi più chjuchi. U duminiu di l'infrastruttura stessu hè abbastanza tecnicu. Ùn hè micca sempre chjaru immediatamente quale impattu specificu, per esempiu, scrive un runbook nantu à a migrazione à un altru nginx hà nantu à l'affari. Avè a carta di destinazione vicinu rende più chjaru.
  
  A causalità hè una pruprietà impurtante di prublemi. Risponde direttamente à a quistione: "Facciu a cosa bona?"
• Parallelismu. Ci sò nove di noi, è hè simpricimenti fisicu impussibile di scaccià tutti à una sola tarea. I compiti da una zona pò esse micca sempre abbastanza. Semu furzati à parallelizà u travagliu trà picculi gruppi di travagliu. À u listessu tempu, i gruppi si ponenu nantu à a so attività per qualchì tempu, ponu esse rinfurzati da un altru. Calchì volta a ghjente si alluntanassi da stu gruppu di travagliu. Qualchissia va in vacanze, qualchissia face un rapportu per u DevOps conf, qualchissia scrive un articulu nantu à Habr. Sapendu chì scopi è travaglii ponu esse fatti in parallelu diventa assai impurtante.

2. Presentatori di rimpiazzamentu di e riunioni di a matina. À i stand-ups avemu stu prublema - a ghjente face parechje attività in parallelu. Calchì volta i travaglii sò cunnessi cunnessi è ùn ci hè micca capitu di quale face ciò chì. È l'opinione di un altru membru di a squadra hè assai impurtante. Questa hè infurmazione supplementaria chì pò cambià u cursu di risolve u prublema. Di sicuru, di solitu ci hè qualchissia cun voi, ma cunsiglii è cunsiglii sò sempre utili.

Per migliurà sta situazione, avemu usatu a tecnica "Changing the Leading Stand-Up". Avà sò rotate secondu una certa lista, è questu hà u so effettu. Quandu hè u vostru turnu, vi sò furzati à immerse è capisce ciò chì succede per fà una bona riunione Scrum.

3. Demo interna. Aiutà à risolve un prublema da a prugrammazione di coppia, a visualizazione nantu à l'arbulu di u prublema è l'aiutu à e riunioni di scrum in a matina sò boni, ma micca ideali. Cum'è una coppia, site limitatu solu da a vostra cunniscenza. L'arburu di u travagliu aiuta à capisce globalmente quale face ciò chì. È u presentatore è i culleghi in a riunione di a matina ùn si sfondaranu micca in i vostri prublemi. Certamente puderanu mancassi qualcosa.

A suluzione hè stata truvata in dimustrà u travagliu fattu à l'altri è dopu discutendu. Ci riunitemu una volta à settimana per una ora è mostranu dettagli di suluzioni à e tarei chì avemu fattu in a settimana passata.

Durante a manifestazione, hè necessariu di revelà i dettagli di u compitu è ​​assicuratevi di dimustrà u so funziunamentu.

U rapportu pò esse realizatu cù una lista di cuntrollu.1. Entre in u cuntestu. Da induve vene u compitu, perchè era ancu necessariu?

2. Cumu era u prublema risolta prima ? Per esempiu, un clicu massivu di u mouse era necessariu, o era impussibile di fà nunda.

3. Cumu migliurà. Per esempiu: "Guardate, avà ci hè scriptosik, eccu u readme".

4. Mostra cumu si travaglia. Hè cunsigliatu di implementà direttamente qualchì scenariu d'utilizatori. Vogliu X, facciu Y, vecu Y (o Z). Per esempiu, aghju implementatu NGINX, fume l'url, è uttene 200 OK. Se l'azzione hè longa, preparate in anticipu per pudè vede più tardi. Hè cunsigliatu di ùn rompe micca troppu una ora prima di a demo, s'ellu hè fragile.

5. Spiegà quantu successu u prublema hè stata risolta, chì difficultà restanu, ciò chì ùn hè micca cumpletu, chì megliurenze sò pussibuli in u futuru. Per esempiu, avà CLI, allora ci sarà automatizazione cumpleta in CI.

Hè cunsigliatu per ogni parlante di mantene à 5-10 minuti. Se u vostru discorsu hè ovviamente impurtante è duverà più, coordinate questu in anticipu in u canali di sre-takeover.

Dopu à a parte in faccia ci hè sempre una discussione in u filu. Hè quì chì u feedback chì avemu bisognu nantu à i nostri compiti appare.

In u risultatu, un sondaghju hè realizatu per determinà l'utilità di ciò chì succede. Questu hè un feedback nantu à l'essenza di u discorsu è l'impurtanza di u compitu.

Conclusioni longu è ciò chì hè dopu

Pò esse chì u tonu di l'articulu hè un pocu pessimista. Questu hè sbagliatu. Dui livelli più bassi di feedback, vale à dì testi è prugrammazione di coppia, travaglianu. Micca perfetta cum'è in u sviluppu tradiziunale, ma ci hè un effettu pusitivu da questu.

I testi, in a so forma attuale, furnisce solu una cobertura parziale di codice. Parechje funzioni di cunfigurazione finiscinu senza teste. A so influenza nantu à u travagliu propiu quandu scrive u codice hè bassu. Tuttavia, ci hè un effettu da e teste d'integrazione, è permettenu di realizà senza paura i refactorings. Questu hè un grande successu. Inoltre, cù u cambiamentu di l'enfasi à u sviluppu in lingue d'altu livellu (avemu python, vai), u prublema si ne va. È ùn avete micca bisognu di assai cuntrolli per a "cola"; un cuntrollu di integrazione generale hè abbastanza.

U travagliu in coppie dipende più di e persone specifiche. Ci hè u fattore di compitu è ​​e nostre cumpetenze soft. Cù certi pirsuni funziuna assai bè, cù altri travaglia peggiu. Ci sò sicuramente benefici da questu. Hè chjaru chì ancu s'è i reguli di u travagliu di coppia ùn sò micca abbastanza osservati, u fattu stessu di fà i travaglii inseme hà un effettu pusitivu nantu à a qualità di u risultatu. In modu persunale, mi pare di travaglià in coppie più faciule è più piacevule.

Modi di più altu livellu di influenzà l'OS - a pianificazione è u travagliu cù i travaglii precisamente producenu effetti: scambiu di cunniscenza di alta qualità è qualità di sviluppu megliu.

Conclusioni brevi in ​​una linea

• I praticanti HR travaglianu in IaC, ma cù menu efficienza.
• Furtificà ciò chì travaglia.
• Venite cù i vostri meccanismi è e pratiche compensatorii.

Source: www.habr.com