{"id":38747,"date":"2019-10-31T22:25:42","date_gmt":"2019-10-31T19:25:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp\/"},"modified":"2019-10-31T22:25:42","modified_gmt":"2019-10-31T19:25:42","slug":"infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp","title":{"rendered":"Infrastructure as Code: come affrontare i problemi con XP","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Ciao, Habr! In passato mi sono lamentato della vita nella paradigma dell'Infrastructure as code e non ho proposto soluzioni per la situazione attuale. Oggi sono tornato per raccontare quali approcci e pratiche possono aiutare a uscire dall'abisso della disperazione e a indirizzare la situazione nel verso giusto. <\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: come affrontare i problemi con XP\" src=\"\/wp-content\/uploads\/2019\/10\/e23fbf20980e731ae1cdb4719c97eb00.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nNell'articolo precedente <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dodopizzaio\/blog\/465137\/\">\u00abInfrastructure as code: primo incontro\u00bb<\/a><\/noindex> Ho condiviso le mie impressioni su quest'area, ho tentato di riflettere sulla situazione attuale in questo campo e ho anche ipotizzato che le pratiche standard, conosciute a tutti gli sviluppatori, possono essere d'aiuto. Potrebbe sembrare che ci siano state molte lamentele sulla vita, ma poche proposte per uscire dalla situazione attuale. <\/p>\n<h2>Chi siamo, dove siamo e quali sono i nostri problemi<\/h2>\n<p>\nAl momento siamo nel Sre Onboarding Team, composto da sei programmatori e tre ingegneri di infrastruttura. Tutti noi cerchiamo di scrivere Infrastructure as code (IaC). Lo facciamo perch\u00e9, in linea di massima, sappiamo scrivere codice e nel nostro percorso abbiamo gi\u00e0 avuto esperienza come sviluppatori di livello 'superiore alla media'. <\/p>\n<ul>\n<li>Abbiamo un insieme di vantaggi: un certo background, conoscenza delle pratiche, capacit\u00e0 di scrivere codice e voglia di imparare cose nuove. <\/li>\n<li>E ci sono dei punti deboli, o svantaggi: mancanza di conoscenze sui fondamenti dell'infrastruttura. <\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Il stack tecnologico che utilizziamo nel nostro IaC.<\/b><\/p>\n<ul>\n<li>Terraform per la creazione delle risorse.<\/li>\n<li>Packer per la creazione delle immagini. Queste sono immagini Windows e CentOS 7.<\/li>\n<li>Jsonnet, per creare potenti configurazioni in drone.io, oltre per generare packer json e i nostri moduli Terraform.<\/li>\n<li>Azure.<\/li>\n<li>Ansible per la preparazione delle immagini.<\/li>\n<li>Python per i servizi ausiliari e per gli script di provisioning.<\/li>\n<li>E tutto questo in VSCode con i plugin condivisi tra i membri del team.<\/li>\n<\/ul>\n<p>La mia conclusione \u00e8 stata: cercavo di infondere (prima di tutto in me stesso) ottimismo, volevo dire che proveremo approcci e pratiche a noi noti per affrontare le difficolt\u00e0 e le complessit\u00e0 di questo campo. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dodopizzaio\/blog\/465137\/\">dell'articolo precedente<\/a><\/noindex> Attualmente stiamo affrontando i seguenti problemi dell'IaC: <\/p>\n<p>Imperfezione degli strumenti e dei mezzi per lo sviluppo del codice.<\/p>\n<ul>\n<li>Distribuzione lenta. L'infrastruttura \u00e8 una parte del mondo reale, e questo pu\u00f2 non essere veloce.<\/li>\n<li>Mancanza di approcci e pratiche.<\/li>\n<li>Siamo nuovi e non sappiamo molto.<\/li>\n<li>La programmazione estrema (XP) \u00e8 pronta a darci una mano.<\/li>\n<\/ul>\n<p><\/p>\n<h2>La programmazione estrema (XP) \u00e8 pronta a darci una mano.<\/h2>\n<p>\nA tutti gli sviluppatori \u00e8 familiare il programming estremo (XP) e le pratiche ad esso associate. Molti di noi hanno lavorato secondo questo approccio e si \u00e8 rivelato efficace. Allora perch\u00e9 non sfruttare i principi e le pratiche che vi sono alla base per superare le difficolt\u00e0 infrastrutturali? Abbiamo deciso di applicare questo approccio e vedere cosa ne risulta.<\/p>\n<p><b class=\"spoiler_title\">Verifica dell'applicabilit\u00e0 dell'approccio XP al tuo settore<\/b>Ecco una descrizione dell'ambiente per cui XP \u00e8 particolarmente adatto e come si rapporta a noi: <\/p>\n<p>1. Requisiti software che cambiano dinamicamente. Avevamo chiara quale fosse l'obiettivo finale. Ma nei dettagli si possono variare. Siamo noi a decidere dove dobbiamo indirizzarci, quindi i requisiti cambiano periodicamente (principalmente da noi stessi). Se consideriamo il team SRE, che fa automazione e al tempo stesso definisce i requisiti e l'ambito del lavoro, questo punto si adatta bene. <\/p>\n<p>2. Rischi causati da progetti a tempo fisso che utilizzano nuove tecnologie. Possiamo incontrare rischi nell'uso di alcune tecnologie a noi sconosciute. E questo \u00e8 il nostro caso al 100%. L'intero nostro progetto si basa su tecnologie con cui non eravamo completamente a nostro agio. Questo \u00e8 un problema costante, poich\u00e9 nel campo dell'infrastruttura emergono continuamente nuove tecnologie. <\/p>\n<p>3,4. Piccolo team di sviluppo collocato e ampliato. La tecnologia che stai utilizzando consente test unitari e funzionali automatizzati. Questi due punti non si adattano completamente a noi. In primo luogo, non siamo un team collocato, in secondo luogo, siamo nove persone, il che pu\u00f2 essere considerato un grande team. Anche se, secondo alcune definizioni, un grande team \u00e8 composto da 14 o pi\u00f9 persone. <\/p>\n<p>Esaminiamo alcune pratiche di XP e come influenzano la velocit\u00e0 e la qualit\u00e0 del feedback.<\/p>\n<h4>Principio del ciclo di feedback in XP<\/h4>\n<p>\nPer me, il feedback \u00e8 la risposta alla domanda se stiamo facendo le cose nel modo giusto e se stiamo andando nella giusta direzione. In XP ci sono schemi straordinari: il ciclo di feedback nel tempo. L'aspetto interessante \u00e8 che pi\u00f9 siamo in basso, pi\u00f9 rapidamente possiamo ricevere il feedback operativo per rispondere alle domande necessarie. <\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: come affrontare i problemi con XP\" src=\"\/wp-content\/uploads\/2019\/10\/e381fb2d7937cbd1978fd6740e63e790.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00c8 un argomento piuttosto interessante da discutere, poich\u00e9 nella nostra industria IT \u00e8 possibile ottenere rapidamente feedback operativo. Immagina quanto possa essere doloroso e difficile lavorare a un progetto per sei mesi e solo dopo scoprire che all'inizio era stato commesso un errore. Questo pu\u00f2 accadere sia nella progettazione sia nella costruzione di sistemi complessi. <\/p>\n<p>Nel nostro caso, IaC ci aiuta con il feedback. Faccio subito una piccola correzione allo schema sopra: il piano di rilascio non \u00e8 basato su cicli mensili, ma avviene pi\u00f9 volte al giorno. A questo ciclo sono legate alcune pratiche che esamineremo pi\u00f9 in dettaglio.<\/p>\n<blockquote><p>Importante: il feedback pu\u00f2 risolvere tutti i problemi citati sopra. Combinato con le pratiche XP, pu\u00f2 tirarti fuori dal baratro della disperazione.<\/p><\/blockquote>\n<p><\/p>\n<h2>Come tirarsi fuori dal baratro della disperazione: tre pratiche<\/h2>\n<p><\/p>\n<h4>Test <\/h4>\n<p>\nI test vengono menzionati due volte nel ciclo di feedback XP. Non \u00e8 affatto casuale. Sono estremamente importanti per tutta la tecnica della programmazione estrema. <\/p>\n<p>Si presume che tu abbia test Unit e di Accettazione. I primi ti danno feedback in pochi minuti, i secondi in qualche giorno, perci\u00f2 scriverli richiede pi\u00f9 tempo, ma vengono eseguiti meno frequentemente. <\/p>\n<p>C'\u00e8 una classica piramide dei test che mostra che ci devono essere pi\u00f9 test di quel tipo. <\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: come affrontare i problemi con XP\" src=\"\/wp-content\/uploads\/2019\/10\/29f3217f11b67378c9c0c3f14fab9d61.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCome si applica questo schema al nostro progetto IaC? In realt\u00e0... non si applica affatto. <\/p>\n<ul>\n<li>Non possono esserci troppi test Unit, anche se dovrebbero essercene molti. O testano qualcosa in modo molto indiretto. Di fatto, possiamo dire che non li scriviamo affatto. Ma ecco alcune applicazioni per tali test che siamo riusciti comunque a realizzare:\n<ol>\n<li>Test del codice su jsonnet. Questo \u00e8, ad esempio, il nostro pipeline di build in drone, che \u00e8 piuttosto complesso. Il codice in jsonnet \u00e8 ben coperto dai test. <br \/>\n Utilizziamo questo <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/yugui\/jsonnetunit\">Unit testing framework for Jsonnet<\/a><\/noindex>. <\/li>\n<li> Test sugli script che vengono eseguiti all'avvio della risorsa. Gli script sono in Python, quindi possiamo scriverci test.<\/li>\n<\/ol>\n<\/li>\n<li>\u00c8 potenzialmente possibile controllare la configurazione nei test, ma noi non facciamo cos\u00ec. C'\u00e8 anche la possibilit\u00e0 di configurare il controllo delle regole di configurazione delle risorse tramite <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/wata727\/tflint\">tflint<\/a><\/noindex>. Tuttavia, per Terraform ci sono solo controlli molto basilari, ma sono stati scritti molti scenari di test per AWS. E noi siamo su Azure, quindi di nuovo non va bene.<\/li>\n<li>Test di integrazione dei componenti: qui dipende da come li classifichi e dove li assegni. Ma in linea di principio funzionano.\n<p>Ecco come appaiono i test di integrazione. <\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: come affrontare i problemi con XP\" src=\"\/wp-content\/uploads\/2019\/10\/b4771e9e5d329ffb2ba565ead7fdddfd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQuesto \u00e8 un esempio durante la costruzione delle immagini in Drone CI. Per arrivarci, bisogna aspettare 30 minuti affinch\u00e9 si costruisca l'immagine Packer, poi altri 15 minuti per i test. Ma ci sono! <\/p>\n<p><b class=\"spoiler_title\">Algoritmo di verifica delle immagini<\/b> <\/p>\n<ol>\n<li>Prima Packer deve preparare completamente l'immagine.<\/li>\n<li>Accanto al test c'\u00e8 un terraforming con uno stato locale, con cui dispieghiamo questa immagine. <\/li>\n<li>Durante il dispiegamento viene utilizzato un piccolo modulo, situato nelle vicinanze, per lavorare pi\u00f9 facilmente con l'immagine. <\/li>\n<li>Quando \u00e8 stata dispiegata una VM dall'immagine, si possono iniziare i controlli. Principalmente, i controlli vengono effettuati sulla macchina. Si verifica come hanno funzionato gli script all'avvio, come operano i demoni. A tal fine, tramite ssh o winrm, accediamo alla macchina appena avviata e controlliamo lo stato della configurazione o se i servizi sono stati avviati.<\/li>\n<\/ol>\n<p>\n <\/li>\n<li>Situazione simile con i test di integrazione e nei moduli per Terraform. Ecco una breve tabella che chiarisce le peculiarit\u00e0 di tali test.\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: come affrontare i problemi con XP\" src=\"\/wp-content\/uploads\/2019\/10\/e2624fb97831701e374a7e8e7fe39a16.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl feedback nel pipeline \u00e8 di circa 40 minuti. Tutto avviene molto lentamente. Pu\u00f2 essere usato per il regresso, ma per un nuovo sviluppo \u00e8 totalmente irrealizzabile. Se ci si prepara molto, prepara i running e gli script, si pu\u00f2 ridurre a 10 minuti. Ma non si tratta comunque di unit test, che possono essere fatti 100 in 5 secondi. <\/li>\n<\/ul>\n<p>\nL'assenza di unit test durante la creazione di immagini o moduli Terraform spinge a delegare il lavoro a servizi separati, che possono semplicemente essere chiamati tramite REST, o a script Python.<\/p>\n<p>Ad esempio, avevamo bisogno di fare in modo che all'avvio della macchina virtuale si registrasse nel servizio <noindex><a rel=\"nofollow\" href=\"https:\/\/www.scaleft.com\/\">ScaleFT<\/a><\/noindex>, e che alla sua distruzione si cancellasse.<\/p>\n<p>Poich\u00e9 ScaleFT \u00e8 per noi un servizio, siamo costretti a lavorare con esso tramite API. Qui \u00e8 stata scritta una wrapper, che pu\u00f2 essere chiamata per dire: \"Vai e cancella questo e quello\". Essa conserva tutte le configurazioni e gli accessi necessari. <\/p>\n<p>Su questo possiamo gi\u00e0 scrivere test normali, poich\u00e9 non si differenzia affatto dal software normale: viene mockato qualche API, lo chiami e vediamo cosa succede. <\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: come affrontare i problemi con XP\" src=\"\/wp-content\/uploads\/2019\/10\/dc17aaa64038acb080669d31fe8ecfe0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<blockquote><p>Risultati dei test: il test unitario, che dovrebbe fornire il sistema operativo in un minuto, non lo fa. E tipi di test di livello superiore nella piramide danno effetti, ma coprono solo una parte dei problemi. <\/p><\/blockquote>\n<h4>Programmazione a coppie<\/h4>\n<p>\nI test sono, naturalmente, utili. Possono essere scritti in gran quantit\u00e0 e possono assumere forme diverse. Funzioneranno ai loro livelli e forniranno feedback. Tuttavia, il problema dei test unitari scadenti, che offrono il sistema operativo pi\u00f9 veloce, rimane. Eppure si continua a desiderare un sistema operativo veloce, con il quale sia facile e piacevole lavorare. Senza contare la qualit\u00e0 della soluzione ottenuta. Fortunatamente, ci sono tecniche che consentono di fornire un feedback ancora pi\u00f9 veloce rispetto ai test modulari. Questo \u00e8 il pair programming.<\/p>\n<p>Quando si scrive codice, si desidera ricevere feedback sulla sua qualit\u00e0 il pi\u00f9 velocemente possibile. S\u00ec, \u00e8 possibile scrivere tutto in un branch di funzionalit\u00e0 (per non rompere nulla a nessuno), fare una pull request su GitHub, assegnarla a qualcuno il cui parere conta, e aspettare una risposta. <\/p>\n<p>Ma si pu\u00f2 aspettare a lungo. Le persone sono tutte occupate e una risposta, anche se arriva, potrebbe non essere della massima qualit\u00e0. Supponiamo che la risposta arrivi subito, il revisore capisca immediatamente l'intera idea, ma la risposta comunque arriva con un ritardo, a posteriori. E si vorrebbe riceverla prima. Ecco perch\u00e9 il pair programming \u00e8 mirato a questo: per ricevere feedback immediato, mentre si scrive.<\/p>\n<p>Di seguito vengono presentati gli stili di pair programming e la loro applicabilit\u00e0 nel lavoro su IaC: <\/p>\n<p><b>1. Classico, Esperto + esperto, cambio al timer.<\/b> Due ruoli: driver e navigator. Due persone. Lavorano su un unico codice e cambiano ruolo dopo un intervallo di tempo prestabilito. <\/p>\n<p>Consideriamo la compatibilit\u00e0 dei nostri problemi con lo stile: <\/p>\n<ul>\n<li>Problema: imperfezione degli strumenti e dei mezzi per lo sviluppo del codice. <br \/>\nImpatto negativo: sviluppiamo pi\u00f9 a lungo, ci rallentiamo, perdiamo il ritmo di lavoro.<br \/>\n Come affrontiamo il problema: utilizziamo strumenti diversi, un IDE condiviso e apprendiamo anche le scorciatoie.<\/li>\n<li> Problema: distribuzione lenta. <br \/>\nImpatto negativo: aumenta il tempo per creare un pezzo di codice funzionante. Ci annoiamo mentre aspettiamo, le mani si allungano per fare qualcos'altro mentre aspetti. <br \/>\nCome affrontiamo il problema: non abbiamo trovato una soluzione.<\/li>\n<li> Problema: mancanza di approcci e pratiche. <br \/>\nImpatto negativo: non c'\u00e8 conoscenza su come fare bene e come fare male. Allunga il tempo per ricevere feedback. <br \/>\nCome affrontiamo il problema: lo scambio di opinioni e pratiche nel lavoro in coppia risolve quasi completamente il problema.<\/li>\n<\/ul>\n<p>\nIl principale problema nell'applicazione di questo stile in IaC \u00e8 il ritmo di lavoro irregolare. Nello sviluppo software tradizionale hai un movimento molto uniforme. Puoi impiegare cinque minuti e scrivere N. Impiegare dieci minuti e scrivere 2N, quindici minuti \u2013 3N. Qui, invece, puoi impiegare cinque minuti e scrivere N, e poi impiegare altri trenta minuti e scrivere un decimo di N. Qui non sai niente, hai un blocco, un'impasse. L'analisi richiede tempo e distrae dalla programmazione diretta. <\/p>\n<blockquote><p>Conclusione: in forma pura non ci adatta.<\/p><\/blockquote>\n<p><b>2. Ping-pong. Questo approccio prevede che un partecipante scriva un test, mentre l'altro ne realizza l'implementazione.<\/b> Considerando che con i test unitari \u00e8 tutto complicato, e che \u00e8 necessario scrivere un lungo test di integrazione, tutta la leggerezza del ping-pong svanisce. <\/p>\n<p>Posso dire che abbiamo provato a separare le responsabilit\u00e0 per la progettazione dello scenario di test e l'implementazione del codice per esso. Un partecipante ha ideato lo scenario, in questo aspetto del lavoro era responsabile, aveva l'ultima parola. L'altro era responsabile per l'implementazione. Questo funzionava bene. La qualit\u00e0 dello scenario con questo approccio aumenta. <\/p>\n<blockquote><p>Conclusione: ahim\u00e8, il ritmo di lavoro non consente di utilizzare il ping-pong come pratica di programmazione in coppia in IaC.<\/p><\/blockquote>\n<p>\n <b>3. Strong Style.<\/b> <noindex><a rel=\"nofollow\" href=\"http:\/\/llewellynfalco.blogspot.com\/2014\/06\/llewellyns-strong-style-pairing.html\">Pratica complessa.<\/a><\/noindex>L'idea \u00e8 che un partecipante diventa un navigatore direttivo, mentre l'altro assume il ruolo di driver esecutivo. In questo caso, il diritto delle decisioni spetta esclusivamente al navigatore. Il driver si limita a digitare e pu\u00f2 influenzare ci\u00f2 che accade con le parole. I ruoli non cambiano per lungo tempo. <\/p>\n<p>\u00c8 molto adatto per l'apprendimento, ma richiede forti soft skills. Su questo ci siamo inceppati. La tecnica si \u00e8 rivelata difficile. E non si tratta nemmeno dell'infrastruttura. <\/p>\n<blockquote><p>Conclusione: potenzialmente pu\u00f2 essere applicato, non abbandoniamo i tentativi.<\/p><\/blockquote>\n<p>\n<b>4. Mobbing, swarming e tutti gli stili noti ma non elencati qui.<\/b> non vengono considerati, poich\u00e9 non abbiamo provato e non possiamo dire nulla in relazione al nostro lavoro.<\/p>\n<blockquote><p>Risultati generali sull'uso della programmazione in coppia:<\/p>\n<ul>\n<li>Abbiamo un ritmo di lavoro irregolare che crea confusione.<\/li>\n<li>Ci siamo scontrati con soft skills non sufficientemente buone. E l'area tematica non aiuta a superare queste nostre carenze.<\/li>\n<li>Test lunghi e problemi con gli strumenti rendono lo sviluppo in coppia faticoso.<\/li>\n<\/ul>\n<\/blockquote>\n<p><b>5. Nonostante ci\u00f2, ci sono stati anche dei successi. Abbiamo ideato il nostro metodo \"Convergenza - Divergenza\".<\/b> Brevemente spiegher\u00f2 come funziona. <\/p>\n<p>Abbiamo partner permanenti per alcuni giorni (meno di una settimana). Facciamo un compito insieme. Per un certo periodo stiamo insieme: uno scrive, l'altro osserva come un team di supporto. Poi ci separiamo per un po', ognuno si occupa di cose indipendenti, poi ci ritroviamo, ci sincronizziamo molto rapidamente, facciamo qualcosa insieme e ci separiamo di nuovo. <\/p>\n<h4>Pianificazione e comunicazione<\/h4>\n<p>\nL'ultimo blocco di pratiche per risolvere i problemi del sistema operativo \u00e8 l'organizzazione del lavoro con le stesse attivit\u00e0. Qui rientra anche lo scambio di esperienze che si svolge al di fuori del lavoro in coppia. Consideriamo tre pratiche:<\/p>\n<p><b>1. Attivit\u00e0 tramite albero degli obiettivi.<\/b> Per la gestione generale del progetto abbiamo organizzato un albero che si estende all'infinito nel futuro. Tecnicalmente, la gestione avviene in Miro. C'\u00e8 un'attivit\u00e0 - \u00e8 un obiettivo intermedio. Da essa partono obiettivi pi\u00f9 piccoli o gruppi di attivit\u00e0. Da loro, ci sono gi\u00e0 le singole attivit\u00e0. Tutte le attivit\u00e0 vengono create e gestite su questa bacheca. <\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: come affrontare i problemi con XP\" src=\"\/wp-content\/uploads\/2019\/10\/fe601e959f0055de4f7f4c39ae713c31.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQuesto schema fornisce anche un feedback che avviene una volta al giorno, quando ci sincronizziamo nelle riunioni. Avere un piano comune visibile a tutti, strutturato e completamente aperto, permette a ciascuno di essere aggiornato su ci\u00f2 che accade e su quanto siamo progrediti. <\/p>\n<p>Vantaggi della visione visiva delle attivit\u00e0:<\/p>\n<ul>\n<li>Causalit\u00e0. Ogni attivit\u00e0 porta a un obiettivo globale. Le attivit\u00e0 sono raggruppate per obiettivi pi\u00f9 piccoli. Il dominio delle infrastrutture \u00e8 di per s\u00e9 abbastanza tecnico. Non \u00e8 sempre immediatamente chiaro quale impatto abbia sul business, ad esempio, la scrittura di un runbook per la migrazione su un altro nginx. Avere accanto una scheda obiettivo rende tutto pi\u00f9 chiaro.<br \/>\n <img decoding=\"async\" alt=\"Infrastructure as Code: come affrontare i problemi con XP\" src=\"\/wp-content\/uploads\/2019\/10\/fc4da9d277f7dc186a5710cf2be4419c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n La causalit\u00e0 \u00e8 una propriet\u00e0 importante delle attivit\u00e0. Risponde direttamente alla domanda: \"Sto facendo la cosa giusta?\" <\/li>\n<li>Parallelo. Siamo nove persone, e non \u00e8 fisicamente possibile che tutti si concentrino su un unico compito. Non sempre ci sono abbastanza compiti in un'unica area. Siamo costretti a parallelizzare il lavoro tra piccoli gruppi di lavoro. In questo modo, i gruppi si dedicano per un certo periodo al proprio compito, e possono essere rinforzati da qualcun altro. Da questo gruppo di lavoro a volte si distaccano persone. Qualcuno va in vacanza, qualcun altro fa una relazione per la conferenza DevOps conf, qualcun altro scrive un articolo su Habr. \u00c8 molto importante sapere quali obiettivi e compiti possono essere eseguiti in parallelo. <\/li>\n<\/ul>\n<p>\n<b>2. Leader alternati per le riunioni del mattino.<\/b> Nei meeting stand-up \u00e8 emerso un problema: molte persone svolgono compiti in parallelo. A volte i compiti sono debolmente collegati e non c'\u00e8 comprensione di cosa stia facendo ciascuno. E l'opinione di un ulteriore membro del team \u00e8 molto importante. \u00c8 un'informazione aggiuntiva che pu\u00f2 cambiare l'andamento della soluzione del compito. Certamente, di solito c'\u00e8 qualcuno con te in coppia, ma consulenze e suggerimenti sono sempre utili. <\/p>\n<p>Per migliorare questa situazione, abbiamo applicato la tecnica \"Cambio del leader dello stand-up\". Ora ruotano secondo un elenco prestabilito, e questo ha un effetto. Quando arriva il tuo turno, sei costretto a immergerti e capire cosa sta succedendo, per condurre bene il meeting scrum. <\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: come affrontare i problemi con XP\" src=\"\/wp-content\/uploads\/2019\/10\/622973a654ecd3e27a7a366596814ffc.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>3. Demo interna.<\/b> L'assistenza nella risoluzione dei compiti dal pair programming, la visualizzazione nell'albero delle attivit\u00e0 e l'aiuto nei meeting scrum del mattino \u00e8 buona, ma non \u00e8 ideale. In coppia sei limitato solo alle tue conoscenze. L'albero delle attivit\u00e0 aiuta a comprendere globalmente chi fa cosa. E il leader e i colleghi durante l'incontro del mattino non si immergeranno profondamente nei tuoi problemi. Possono sicuramente trascurare qualcosa. <\/p>\n<p>La soluzione \u00e8 stata trovata nella dimostrazione del lavoro svolto l'uno all'altro e nella successiva discussione. Ci incontriamo una volta alla settimana per un'ora e mostriamo i dettagli delle soluzioni ai compiti che abbiamo realizzato nell'ultima settimana. <\/p>\n<p>Durante la dimostrazione, \u00e8 necessario rivelare i dettagli del compito e dimostrare obbligatoriamente il suo funzionamento. <\/p>\n<p><b class=\"spoiler_title\">La relazione pu\u00f2 essere condotta seguendo una lista di controllo.<\/b>1. Introduciti nel contesto. Da dove \u00e8 venuto il compito, perch\u00e9 era necessario?<\/p>\n<p>2. Come \u00e8 stato risolto il compito prima? Ad esempio, era necessario un massiccio clic sul mouse, o era del tutto impossibile fare qualcosa.<\/p>\n<p>3. Come miglioriamo questo. Ad esempio: \"Guardate, ora c'\u00e8 uno script, ecco il readme\".<\/p>\n<p>4. Mostratemi come funziona. \u00c8 preferibile realizzare direttamente uno scenario utente. Voglio X, faccio Y, vedo \u0419 (o Z). Ad esempio, faccio il deploy di NGINX, nella mia url vedo 200 OK. Se l'operazione richiede tempo, preparatela in anticipo in modo da poterla mostrare. \u00c8 preferibile non rompere nulla un'ora prima della demo, se \u00e8 fragile.<\/p>\n<p>5. Spiegate quanto bene \u00e8 stata risolta la questione, quali difficolt\u00e0 sono rimaste, cosa non \u00e8 stato completato, quali miglioramenti sono possibili in futuro. Ad esempio, ora c'\u00e8 la cli, poi ci sar\u00e0 l'automazione completa nel CI.<\/p>\n<p>\u00c8 auspicabile che ciascun relatore si attenga ai 5-10 minuti. Se la vostra presentazione \u00e8 di fondamentale importanza e richieder\u00e0 pi\u00f9 tempo, concordatelo in anticipo nel canale sre-takeover.<\/p>\n<p>Dopo la parte dal vivo segue necessariamente una discussione nel thread. \u00c8 proprio qui che appare il feedback necessario sui propri compiti. <\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: come affrontare i problemi con XP\" src=\"\/wp-content\/uploads\/2019\/10\/77da888d24b52c7eea7e65d2400e152c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nAlla fine viene condotto un sondaggio per identificare l'utilit\u00e0 di quanto avvenuto. Questo costituisce gi\u00e0 un feedback in merito all'essenza della presentazione e all'importanza del compito.<\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: come affrontare i problemi con XP\" src=\"\/wp-content\/uploads\/2019\/10\/7642cd87050171cc4a6bf278329dd283.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Conclusioni lunghe e quali sono i prossimi passi<\/h2>\n<p>\nPu\u00f2 sembrare che il tono dell'articolo sia piuttosto pessimista. Non \u00e8 cos\u00ec. I due livelli inferiori di ricezione del feedback, ovvero i test e la programmazione a coppie, funzionano. Non cos\u00ec perfettamente come nella programmazione tradizionale, ma ci sono effetti positivi. <\/p>\n<p>I test, nella loro forma attuale, forniscono solo una copertura parziale del codice. Molte funzioni di configurazione si rivelano non testate. Il loro impatto sul lavoro immediato durante la scrittura del codice \u00e8 minimo. Tuttavia, gli effetti dei test di integrazione sono evidenti, e proprio questi permettono di effettuare refactoring senza timori. Questo \u00e8 un grande traguardo. Inoltre, con il cambio di focus verso lo sviluppo in linguaggi ad alto livello (noi usiamo python, go), il problema si riduce. E per il 'collante' ci sono molte verifiche e non \u00e8 necessario, basta una verifica integrativa generale.<\/p>\n<p>Il lavoro a coppie dipende maggiormente dalle persone specifiche. Ci sono il fattore compito e le nostre soft skills. Con alcuni funziona molto bene, con altri meno. Ma i benefici ci sono di sicuro. \u00c8 chiaro che anche in caso di rispetto insufficiente delle regole del lavoro a coppie, il semplice fatto di svolgere insieme i compiti influisce positivamente sulla qualit\u00e0 del risultato. Personalmente, lavorare a coppie risulta pi\u00f9 facile e piacevole.<\/p>\n<p>Metodi pi\u00f9 ad alto livello di influenza sul OS \u2013 la pianificazione e il lavoro con i compiti danno sicuramente effetti: uno scambio di conoscenze di qualit\u00e0 e un miglioramento della qualit\u00e0 dello sviluppo. <\/p>\n<h4>Conclusioni brevi in una riga <\/h4>\n<p><\/p>\n<ul>\n<li>Le pratiche XP funzionano in IaC, ma con un'efficienza inferiore.<\/li>\n<li>Rafforza ci\u00f2 che funziona.<\/li>\n<li>Inventa i tuoi meccanismi e pratiche compensative.<\/li>\n<\/ul>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dodopizzaio\/blog\/470620\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0420\u0430\u043d\u044c\u0448\u0435 \u044f \u0436\u0430\u043b\u043e\u0432\u0430\u043b\u0441\u044f \u043d\u0430 \u0436\u0438\u0437\u043d\u044c \u0432 \u043f\u0430\u0440\u0430\u0434\u0438\u0433\u043c\u0435 Infrastructure as code \u0438 \u043d\u0438\u0447\u0435\u0433\u043e \u043d\u0435 \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u043b \u0434\u043b\u044f \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0441\u043b\u043e\u0436\u0438\u0432\u0448\u0435\u0439\u0441\u044f \u0441\u0438\u0442\u0443\u0430\u0446\u0438\u0438. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u0432\u0435\u0440\u043d\u0443\u043b\u0441\u044f, \u0447\u0442\u043e\u0431\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c, \u043a\u0430\u043a\u0438\u0435 \u043f\u043e\u0434\u0445\u043e\u0434\u044b \u0438 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0438 \u043f\u043e\u043c\u043e\u0433\u0443\u0442 \u0432\u044b\u0440\u0432\u0430\u0442\u044c\u0441\u044f \u0438\u0437 \u0431\u0435\u0437\u0434\u043d\u044b \u043e\u0442\u0447\u0430\u044f\u043d\u0438\u044f \u0438 \u0432\u044b\u0440\u0443\u043b\u0438\u0442\u044c \u0441\u0438\u0442\u0443\u0430\u0446\u0438\u044e \u0432 \u043f\u0440\u0430\u0432\u0438\u043b\u044c\u043d\u043e\u0435 \u0440\u0443\u0441\u043b\u043e. \u0412 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u00abInfrastructure as code: \u043f\u0435\u0440\u0432\u043e\u0435 \u0437\u043d\u0430\u043a\u043e\u043c\u0441\u0442\u0432\u043e\u00bb \u044f \u0434\u0435\u043b\u0438\u043b\u0441\u044f \u0441\u0432\u043e\u0438\u043c \u0432\u043f\u0435\u0447\u0430\u0442\u043b\u0435\u043d\u0438\u0435\u043c \u043e\u0442 \u044d\u0442\u043e\u0439 \u0441\u0444\u0435\u0440\u044b, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29066,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38747","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0420\u0430\u043d\u044c\u0448\u0435 \u044f \u0436\u0430\u043b\u043e\u0432\u0430\u043b\u0441\u044f \u043d\u0430 \u0436\u0438\u0437\u043d\u044c \u0432 \u043f\u0430\u0440\u0430\u0434\u0438\u0433\u043c\u0435 Infrastructure as code \u0438 \u043d\u0438\u0447\u0435\u0433\u043e \u043d\u0435 \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u043b \u0434\u043b\u044f \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0441\u043b\u043e\u0436\u0438\u0432\u0448\u0435\u0439\u0441\u044f \u0441\u0438\u0442\u0443\u0430\u0446\u0438\u0438.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Infrastructure as Code: \u043a\u0430\u043a \u043f\u043e\u0431\u043e\u0440\u043e\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u044b \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e XP | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0420\u0430\u043d\u044c\u0448\u0435 \u044f \u0436\u0430\u043b\u043e\u0432\u0430\u043b\u0441\u044f \u043d\u0430 \u0436\u0438\u0437\u043d\u044c \u0432 \u043f\u0430\u0440\u0430\u0434\u0438\u0433\u043c\u0435 Infrastructure as code \u0438 \u043d\u0438\u0447\u0435\u0433\u043e \u043d\u0435 \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u043b \u0434\u043b\u044f \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0441\u043b\u043e\u0436\u0438\u0432\u0448\u0435\u0439\u0441\u044f \u0441\u0438\u0442\u0443\u0430\u0446\u0438\u0438.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:25:42+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:25:42+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Infrastructure as Code: come affrontare i problemi con XP | ProHoster","description":"Ciao, Habr! In passato mi lamentavo della vita nella paradigma Infrastructure as Code e non proponevo soluzioni alla situazione attuale.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Infrastructure as Code: \u043a\u0430\u043a \u043f\u043e\u0431\u043e\u0440\u043e\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u044b \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e XP | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0420\u0430\u043d\u044c\u0448\u0435 \u044f \u0436\u0430\u043b\u043e\u0432\u0430\u043b\u0441\u044f \u043d\u0430 \u0436\u0438\u0437\u043d\u044c \u0432 \u043f\u0430\u0440\u0430\u0434\u0438\u0433\u043c\u0435 Infrastructure as code \u0438 \u043d\u0438\u0447\u0435\u0433\u043e \u043d\u0435 \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u043b \u0434\u043b\u044f \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0441\u043b\u043e\u0436\u0438\u0432\u0448\u0435\u0439\u0441\u044f \u0441\u0438\u0442\u0443\u0430\u0446\u0438\u0438.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:25:42+00:00","article:modified_time":"2019-10-31T19:25:42+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38747","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 23:16:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:04:30","updated":"2026-01-23 23:16:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/38747","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=38747"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/38747\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/29066"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=38747"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=38747"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=38747"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}