Parliamo del motivo per cui gli strumenti CI e CI sono cose completamente diverse.
Quale dolore intende risolvere CI, da dove è nata l'idea, quali sono le ultime conferme che funziona, come capire che hai uno studio e non solo Jenkins installato.
L’idea di realizzare un reportage sull’Integrazione Continua è nata un anno fa, mentre stavo facendo colloqui e cercando lavoro. Ho parlato con 10-15 aziende, solo una di loro è stata in grado di rispondere chiaramente cos'è la CI e spiegare come si è accorta di non averla. Gli altri dicevano sciocchezze incomprensibili su Jenkins :) Bene, abbiamo Jenkins, costruisce, CI! Durante il rapporto cercherò di spiegare cos'è effettivamente l'integrazione continua e perché Jenkins e strumenti simili hanno un rapporto molto debole con questa.
Allora, cosa ti viene in mente di solito quando senti la parola CI? La maggior parte delle persone penserà a Jenkins, Gitlab CI, Travis, ecc.
Anche se lo cerchiamo su Google, ci fornirà questi strumenti.
Se hai familiarità con le domande, subito dopo aver elencato gli strumenti, ti diranno che CI è quando crei ed esegui test in una richiesta pull per un commit.
L'integrazione continua non riguarda strumenti, né assemblaggi con test in filiale! La Continuous Integration è la pratica di integrazione molto frequente di nuovo codice e per utilizzarla non è affatto necessario recintare Jenkins, GitLab, ecc.
Prima di capire come si presenta un CI a tutti gli effetti, immergiamoci nel contesto delle persone che lo hanno inventato e sentiamo il dolore che stavano cercando di risolvere.
E hanno risolto il dolore di lavorare insieme come una squadra!
Diamo un'occhiata ad esempi delle difficoltà che gli sviluppatori devono affrontare quando sviluppano in team. Qui abbiamo un progetto, un ramo master in git e due sviluppatori.
E andarono a lavorare come tutti erano abituati da tempo. Abbiamo intrapreso un compito nel grande schema delle cose, creato un ramo di funzionalità e scritto il codice.
Uno ha terminato la funzionalità più velocemente e l'ha unita al master.
Il secondo ha avuto bisogno di più tempo, si è fuso più tardi ed è finito in conflitto. Ora, invece di scrivere le funzionalità di cui l'azienda ha bisogno, lo sviluppatore dedica tempo ed energie alla risoluzione dei conflitti.
Più è difficile combinare la tua funzionalità con un master comune, più tempo ci dedichiamo. E l'ho dimostrato con un esempio abbastanza semplice. Questo è un esempio in cui ci sono solo 2 sviluppatori. Immagina se 10, 15 o 100 persone in un'azienda scrivono su un repository. Impazzirai per risolvere tutti questi conflitti.
C'è un caso leggermente diverso. Abbiamo un master e alcuni sviluppatori che fanno qualcosa.
Hanno creato un ramoscello.
Uno è morto, è andato tutto bene, ha superato l'incarico.
Il secondo sviluppatore, nel frattempo, ha consegnato il suo compito. Diciamo che lo ha inviato per la revisione. Molte aziende hanno una pratica chiamata revisione. Da un lato questa pratica è buona e utile, dall’altro ci rallenta sotto molti aspetti. Non entreremo in questo argomento, ma ecco un ottimo esempio di ciò che può portare una recensione negativa. Hai inviato una richiesta pull per la revisione. Non c'è altro da fare per lo sviluppatore. Cosa inizia a fare? Comincia ad assumere altri compiti.
Durante questo periodo, il secondo sviluppatore ha fatto qualcos'altro.
Il primo ha completato il terzo compito.
E dopo molto tempo, la sua recensione è stata messa alla prova e sta cercando di venire a patti. Allora cosa sta succedendo? Cattura un numero enorme di conflitti. Perché? Perché mentre la sua richiesta pull era sospesa nella revisione, molte cose erano già cambiate nel codice.
Oltre alla storia dei conflitti, c'è una storia delle comunicazioni. Mentre il tuo thread è in attesa di revisione, mentre è in attesa di qualcosa, mentre lavori su una funzionalità per molto tempo, smetti di monitorare cos'altro sta cambiando nella base di codice del tuo servizio. Forse quello che stai cercando di risolvere ora è già stato risolto ieri e puoi prendere un metodo e riutilizzarlo. Ma non lo vedrai perché lavori sempre con un ramo obsoleto. E questo ramo obsoleto comporta sempre la necessità di risolvere un conflitto di unione.
Si scopre che se lavoriamo in squadra, cioè non una persona fruga nel repository, ma 5-10 persone, più a lungo non aggiungiamo il nostro codice al master, più soffriamo perché alla fine abbiamo bisogno qualcosa e poi unirlo. E più conflitti abbiamo e più vecchia versione con cui lavoriamo, più problemi avremo.
Fare qualcosa insieme è doloroso! Ci intralciamo sempre a vicenda.
Questo problema è stato notato più di 20 anni fa. Ho trovato la prima menzione della pratica dell'Integrazione Continua in Extreme Programming.
Extreme Programming è il primo framework agile. La pagina è apparsa nel 96. E l'idea era quella di utilizzare qualche tipo di pratica di programmazione, pianificazione e altre cose, in modo che lo sviluppo fosse il più flessibile possibile, in modo da poter rispondere rapidamente a qualsiasi cambiamento o richiesta dei nostri clienti. E hanno iniziato ad affrontare questo problema 24 anni fa, che se fai qualcosa per molto tempo e in disparte, ci dedichi più tempo perché hai dei conflitti.
Ora analizzeremo singolarmente la frase “Integrazione continua”. Se lo traduciamo direttamente, otteniamo un'integrazione continua. Ma quanto sia continuo non è molto chiaro; è molto discontinuo. Ma anche quanta integrazione abbia non è molto ovvia.
Ed è per questo che ora ti fornisco citazioni da Extreme Programming. E analizzeremo entrambe le parole separatamente.
Integrazione - Come ho già detto, ci impegniamo a garantire che ogni ingegnere lavori con la versione più recente del codice, in modo che si sforzi di aggiungere il suo codice il più spesso possibile a un ramo comune, in modo che si tratti di rami piccoli. Perché se sono grandi, possiamo facilmente rimanere bloccati con conflitti di unione per una settimana. Ciò è particolarmente vero se abbiamo un ciclo di sviluppo lungo come quello a cascata, in cui lo sviluppatore si allontana per un mese per tagliare alcune funzionalità enormi. E rimarrà bloccato nella fase di integrazione per molto tempo.
L'integrazione è quando prendiamo il nostro ramo e lo integriamo con il master, lo uniamo. Esiste un'opzione definitiva quando siamo sviluppatori transbase, in cui ci sforziamo di garantire di scrivere immediatamente al master senza rami aggiuntivi.
In generale, integrazione significa prendere il tuo codice e trascinarlo nel master.
Cosa si intende qui con la parola “continuo”, cosa si chiama continuità? La pratica implica che lo sviluppatore si sforzi di integrare il suo codice il più rapidamente possibile. Questo è il suo obiettivo quando esegue qualsiasi attività: inserire il suo codice nel master il più rapidamente possibile. In un mondo ideale, gli sviluppatori lo farebbero ogni poche ore. Cioè, prendi un piccolo problema e lo unisci al master. È tutto bellissimo. Questo è ciò per cui ti sforzi. E questo deve essere fatto con continuità. Non appena fai qualcosa, lo inserisci immediatamente nel master.
E lo sviluppatore che realizza qualcosa è responsabile di ciò che ha fatto per farlo funzionare e non rompere nulla. È qui che di solito esce la storia di prova. Vogliamo eseguire alcuni test sul nostro commit, sulla nostra unione, per assicurarci che funzioni. Ed è qui che Jenkins può aiutarti.
Ma con le storie: apportiamo piccole modifiche, lasciamo che i compiti siano piccoli, creiamo un problema e proviamo immediatamente a incorporarlo in qualche modo nel master: nessun Jenkins aiuterà qui. Perché Jenkins ti aiuterà solo a fare i test.
Puoi farne a meno. Questo non ti farà affatto male. Perché l'obiettivo della pratica è misurare il più spesso possibile, in modo da non sprecare un'enorme quantità di tempo in eventuali conflitti in futuro.
Immaginiamo che per qualche motivo siamo nel 2020 senza Internet. E lavoriamo localmente. Non abbiamo Jenkins. Questo va bene. Puoi ancora andare avanti e creare una filiale locale. Ci hai scritto del codice. Abbiamo completato l'attività in 3-4 ore. Siamo passati a master, abbiamo eseguito un git pull e abbiamo unito lì il nostro ramo. Pronto. Se lo fai spesso, congratulazioni, hai l'Integrazione Continua!
Quali prove esistono nel mondo moderno per cui vale la pena spendere energia? Perché in generale è difficile. Se provi a lavorare in questo modo, capirai che ora parte della pianificazione verrà influenzata, dovrai dedicare più tempo alla scomposizione dei compiti. Perché se fai amico..., allora non potrai venire a patti velocemente e quindi finirai nei guai. Non avrai più pratica.
E sarà costoso. Non sarà possibile lavorare subito da domani utilizzando la Continuous Integration. Ci vorrà molto tempo per abituarvi, ci vorrà molto tempo per abituarvi alla scomposizione dei compiti, ci vorrà molto tempo per abituarvi a rifare la pratica di revisione, se ne avete una . Perché il nostro obiettivo è che si sciolga oggi. E se esegui una revisione entro tre giorni, avrai problemi e l'integrazione continua non funzionerà per te.
Ma al momento disponiamo di prove rilevanti che ci dicano che investire in questa pratica ha senso?
La prima cosa che mi è venuta in mente è stata State of DevOps. Questo è uno studio che i ragazzi conducono da 7 anni. Ora lo fanno come organizzazione indipendente, ma sotto Google.
E il loro studio del 2018 ha mostrato una correlazione tra le aziende che cercano di utilizzare filiali di breve durata che si integrano rapidamente, si integrano frequentemente e hanno indicatori di prestazioni IT migliori.
Quali sono questi indicatori? Questi sono i 4 parametri che prendono da tutte le aziende nei loro questionari: frequenza di implementazione, tempi di consegna per le modifiche, tempo per ripristinare il servizio, tasso di fallimento delle modifiche.
E, in primo luogo, esiste questa correlazione, sappiamo che le aziende che misurano frequentemente hanno parametri molto migliori. E hanno una divisione delle aziende in diverse categorie: si tratta di aziende lente che producono qualcosa lentamente, a medio rendimento, ad alto rendimento ed elite. Le élite sono Netflix e Amazon, che sono super veloci, fanno tutto in modo rapido, bello ed efficiente.
La seconda storia, accaduta appena un mese fa. Technology Radar ha un ottimo articolo su Gitflow. Gitflow è diverso da tutti gli altri in quanto i suoi rami sono longevi. Esistono rami di rilascio che durano a lungo e rami di funzionalità che durano a lungo. Questa pratica presso Technology Radar è stata spostata in ATTESA. Perché? Perché le persone affrontano il dolore dell’integrazione.
Se il tuo ramo vive per molto tempo, si blocca, marcisce e iniziamo a dedicare più tempo a cercare di apportarvi qualche tipo di cambiamento.
E recentemente l'autore di Gitflow ha affermato che se il tuo obiettivo è l'integrazione continua, se il tuo obiettivo è voler eseguire il più spesso possibile, allora Gitflow è una cattiva idea. Ha aggiunto separatamente all'articolo che se hai un backend in cui puoi lottare per questo, allora Gitflow è superfluo per te, perché Gitflow ti rallenterà, Gitflow ti creerà problemi con l'integrazione.
Ciò non significa che Gitflow sia dannoso e non dovrebbe essere utilizzato. È per altre occasioni. Ad esempio, quando è necessario supportare più versioni di un servizio o di un'applicazione, ovvero quando è necessario supporto per un lungo periodo di tempo.
Ma se parli con persone che supportano tali servizi, sentirai molto dolore per il fatto che questa versione era la 3.2, ovvero 4 mesi fa, ma questa correzione non era inclusa in essa e ora, per realizzarla, devi apportare un sacco di modifiche. E ora sono di nuovo bloccati e stanno armeggiando da una settimana cercando di implementare qualche nuova funzionalità.
Come ha giustamente notato Alexander Kovalev nella chat, la correlazione non è la stessa cosa della causalità. Questo è vero. Cioè, non esiste una connessione diretta al fatto che se si dispone dell'integrazione continua, tutti i parametri saranno ottimi. Ma esiste una correlazione positiva secondo cui se uno è uno, molto probabilmente lo è anche l'altro. Non è un dato di fatto, ma molto probabilmente. E' solo una correlazione.
Sembra che stiamo già facendo qualcosa, sembra che ci stiamo già unendo, ma come possiamo capire che abbiamo ancora l'Integrazione Continua, che ci stiamo unendo abbastanza spesso?
Jez Humble è l'autore di Handbook, Accelerate, del sito Web Continuous Delivery e del libro Continuous Delivery. Offre questo test:
- Il codice dell'ingegnere arriva al master ogni giorno.
- Per ogni commit esegui unit test.
- La build nel master è caduta, è stata riparata in circa 10 minuti.
Suggerisce di utilizzare un test come questo per assicurarsi di avere abbastanza pratica.
Trovo quest'ultimo un po' controverso. Cioè, se riesci a risolverlo in 10 minuti, allora hai l'integrazione continua, sembra un po' strano, secondo me, ma ha senso. Perché? Perché se ti blocchi spesso, significa che i tuoi cambiamenti sono piccoli. Se una piccola modifica significa che la build principale non funziona correttamente, puoi trovare rapidamente un esempio perché la modifica è piccola. Qui hai avuto una piccola fusione, 20-30 righe sono cambiate. E, di conseguenza, puoi capire rapidamente quale fosse il motivo, poiché i cambiamenti sono piccoli, hai un'area molto piccola per cercare il problema.
E anche se la nostra produzione va in pezzi dopo il rilascio, se abbiamo la pratica dell'Integrazione Continua, sarà molto più facile per noi agire, perché i cambiamenti sono minimi. Sì, ciò influenzerà la pianificazione. Questo farà male. E, probabilmente, la cosa più difficile in questa pratica è abituarsi a suddividere i compiti, cioè come farlo in modo da poter prendere qualcosa e farlo in poche ore e allo stesso tempo superare una revisione, se Ne hai uno. La revisione è un dolore separato.
I test unitari sono solo un assistente che ti aiuta a capire se la tua integrazione ha avuto successo e se non si è verificato alcun problema. A mio avviso, anche questo non è del tutto obbligatorio, perché non è questo il punto della pratica.
Questa è una breve introduzione all'integrazione continua. Questo è tutto ciò che riguarda questa pratica. Sono pronto per le domande.
Mi limiterò a riassumere ancora brevemente:
- L'integrazione continua non è Jenkins, non è Gitlab.
- Questo non è uno strumento, è una pratica che uniamo il nostro codice al master il più spesso possibile.
- Lo facciamo per evitare l'enorme dolore che sorgerà con le fusioni in futuro, cioè sperimentiamo un po' di dolore ora per non sperimentarne di più in futuro. Questo è il punto.
- A lato c'è la comunicazione tramite codice, ma la vedo molto raramente, ma è anche per questo che è stata progettata.
domande
Cosa fare con le attività non scomposte?
Decomporsi. Qual è il problema? Puoi fornire un esempio in cui esiste un'attività e non è scomposta?
Ci sono compiti che non possono essere scomposti dalla parola "completamente", ad esempio quelli che richiedono competenze molto approfondite e che possono effettivamente essere risolti nel corso di un mese per ottenere un risultato digeribile.
Se ho capito bene, allora c'è un compito grande e complesso, il cui risultato sarà visibile solo tra un mese?
Sì, è giusto. Sì, sarà possibile valutare il risultato non prima di un mese.
Bene. In generale questo non è un problema. Perché? Perché in questo caso, quando parliamo di ramoscelli, non parliamo di un ramoscello con una caratteristica. Le funzionalità possono essere grandi e complesse. Possono influenzare un gran numero di componenti. E forse non possiamo realizzarli completamente in un unico ramo. Questo va bene. Dobbiamo solo raccontare questa storia. Se una funzionalità non è completamente pronta, ciò non significa che alcune parti del suo codice non possano essere unite. Hai aggiunto, ad esempio, la migrazione e ci sono alcune fasi all'interno della funzionalità. Supponiamo che tu abbia una fase: esegui una migrazione, aggiungi un nuovo metodo. E puoi già misurare queste cose ogni giorno.
Bene. Qual è il punto allora?
Che senso ha uccidere piccole cose ogni giorno?
Sì.
Se rompono qualcosa, lo vedi subito. Hai un piccolo pezzo che ha rotto qualcosa, è più facile per te ripararlo. Il punto è che unire un piccolo pezzo adesso è molto più semplice che unire qualcosa di grande tra qualche settimana. E il terzo punto è che altri ingegneri lavoreranno con la versione attuale del codice. Vedranno che qui sono state aggiunte alcune migrazioni e quindi è apparso qualche metodo che potrebbero voler utilizzare. Tutti vedranno cosa sta succedendo nel tuo codice. È per queste tre cose che si fa pratica.
Grazie, la questione è chiusa!
(Oleg Soroka) Posso aggiungere? Hai detto tutto correttamente, voglio solo aggiungere una frase.
Così.
Con l'integrazione continua, il codice viene unito in un ramo comune non quando la funzionalità è completamente pronta, ma quando la build smette di rompersi. E puoi tranquillamente impegnarti a padroneggiare tutte le volte che vuoi al giorno. Il secondo aspetto è che se per qualche motivo non riesci a suddividere l'attività mensile in attività per almeno tre giorni, taccio per circa tre ore, allora hai un grosso problema. E il fatto di non avere l'integrazione continua è l'ultimo di questi problemi. Ciò significa che hai problemi con l'architettura e zero pratiche di ingegneria. Perché anche se si tratta di ricerca, in ogni caso deve essere formulata sotto forma di ipotesi o di ciclo.
Abbiamo parlato di 4 parametri che distinguono le aziende di successo da quelle in ritardo. Dobbiamo ancora vivere per vedere questi 4 parametri. Se il completamento della tua attività media richiede un mese, mi concentrerei prima su questa metrica. Prima lo abbasserei a 3 giorni. E dopo ho iniziato a pensare a Continuous.
Ho capito bene che ritieni che in generale non abbia senso investire in pratiche di ingegneria se un'attività richiede un mese per essere completata?
Hai l'integrazione continua. E c'è un argomento tale che in 10 minuti puoi correggere una correzione o ripristinarla. Immagina di averlo steso. Inoltre, hai anche una distribuzione continua, l'hai distribuita alla produzione e solo allora hai notato che qualcosa è andato storto. E devi ripristinarlo, ma hai già migrato il tuo database. Hai già lo schema del database della versione successiva, inoltre, avevi anche una sorta di backup e anche i dati sono stati scritti lì.
E tu che alternativa hai? Se esegui il rollback del codice, non potrà più funzionare con questo database aggiornato.
La base va solo avanti, sì.
Le persone che hanno scarse pratiche ingegneristiche molto probabilmente non hanno nemmeno letto il grosso libro su.... Cosa fare con il backup? Se ripristini da un backup, significa che perdi i dati che hai accumulato in quel momento. Ad esempio, abbiamo lavorato per tre ore con la nuova versione del database, gli utenti si sono registrati lì. Rifiuti il vecchio backup perché lo schema non funziona con la nuova versione, quindi hai perso questi utenti. E sono insoddisfatti, giurano.
Per padroneggiare l’intera gamma di pratiche che supportano la Continuous Integration e la Continuous Delivery, non è sufficiente semplicemente imparare a scrivere.... In primo luogo, potrebbero essercene molti, non sarà pratico. Inoltre ci sono un sacco di altre pratiche come Scientific. Esiste una pratica del genere, GitHub l'ha resa popolare contemporaneamente. Questo è quando hai sia il vecchio codice che il nuovo codice in esecuzione contemporaneamente. Questo è quando crei una funzionalità incompleta, ma può restituire un valore: come funzione o come API Rest. Esegui sia il nuovo codice che il vecchio codice e confronti la differenza tra loro. E se c'è una differenza, registri questo evento. In questo modo sai di avere una nuova funzionalità pronta per essere implementata sopra quella vecchia se non hai avuto una discrepanza tra le due per un certo tempo.
Esistono centinaia di pratiche simili. Suggerirei di iniziare con lo sviluppo di transbase. Non è al 100% sull'integrazione continua, ma le pratiche sono le stesse, non si può vivere bene senza l'altra.
Hai fornito lo sviluppo di transbase come esempio in cui puoi vedere le pratiche o suggerisci alle persone di iniziare a utilizzare lo sviluppo di transbase?
Dai un'occhiata, perché non saranno in grado di usarlo. Per usarli, devi leggere molto. E quando una persona chiede: "Cosa fare con una funzionalità che richiede un mese, significa che non ha letto dello sviluppo di transbase". Non lo consiglierei ancora. Consiglierei di concentrarsi esclusivamente sull'argomento su come suddividere correttamente dal punto di vista architettonico le attività di grandi dimensioni in attività più piccole. Questa è l'essenza della decomposizione.
La decomposizione è uno degli strumenti dell'architetto. Prima facciamo l'analisi, poi la scomposizione, poi la sintesi, poi l'integrazione. Ed è così che tutto funziona per noi. E dobbiamo ancora crescere verso l’integrazione continua attraverso la decomposizione. Le domande sorgono nella prima fase e stiamo già parlando della quarta fase, vale a dire quanto più spesso facciamo l'integrazione, meglio è. È ancora troppo presto per farlo; sarebbe bello abbattere prima il tuo monolite.
Devi disegnare un numero di frecce e quadrati su qualche diagramma. Non si può dire che ora mostrerò il diagramma architettonico di una nuova applicazione e mostrerò un quadrato, all'interno del quale c'è un pulsante verde per l'applicazione. In ogni caso, ci saranno più quadrati e frecce. Ogni diagramma che ho visto ne aveva più di uno. E la decomposizione, anche a livello di rappresentazione grafica, è già in atto. Pertanto, i quadrati possono essere resi indipendenti. In caso contrario, allora ho grandi domande per l'architetto.
Dalla chat arriva una domanda: “Se una revisione è obbligatoria e richiede molto tempo, forse un giorno o più?”
Hai problemi con la pratica. La revisione non dovrebbe durare un giorno o più. Questa è la stessa storia della domanda precedente, solo un po' più morbida. Se una revisione dura un giorno, molto probabilmente sta apportando grandi cambiamenti. Ciò significa che deve essere rimpicciolito. Nello sviluppo transbase, consigliato da Oleg, c'è una storia chiamata revisione continua. La sua idea è che facciamo apposta una richiesta pull così piccola, perché ci sforziamo di unirci costantemente e un po' alla volta. E quindi la richiesta pull modifica un'astrazione o 10 righe. Grazie a questa recensione, ci impieghiamo un paio di minuti.
Se la revisione dura un giorno o più, qualcosa non va. Innanzitutto, potresti avere dei problemi con l'architettura. Oppure si tratta di una grande porzione di codice, ad esempio 1 righe. Oppure la tua architettura è così complessa che una persona non riesce a capirla. Questo è un problema leggermente laterale, ma dovrà anche essere risolto. Forse non c'è affatto bisogno di una revisione. Dobbiamo pensare anche a questo. La revisione è la cosa che ti rallenta. In generale ha i suoi vantaggi, ma devi capire perché lo stai facendo. È questo un modo per trasmettere rapidamente le informazioni, è un modo per stabilire alcuni standard internamente o cosa? Perchè ti serve? Perché la revisione deve essere eseguita molto rapidamente o annullata del tutto. È come lo sviluppo di Transbase: la storia è molto bella, ma solo per ragazzi maturi.
Per quanto riguarda le 4 metriche, consiglierei comunque di rimuoverle per capire a cosa porta. Guarda i numeri, guarda la foto, quanto è brutto tutto.
(Dmitrij) Sono pronto ad avviare una discussione su questo argomento con te. I numeri e le metriche sono fantastici, le pratiche sono fantastiche. Ma bisogna capire se l'azienda ne ha bisogno. Ci sono aziende che non hanno bisogno di questo tipo di velocità di cambiamento. Conosco aziende in cui non è possibile apportare modifiche ogni 15 minuti. E non perché siano così cattivi. Questo è un ciclo di vita del genere. E per rendere la funzionalità dei rami, la funzionalità di attivazione/disattivazione, è necessaria una conoscenza approfondita.
È complicato. Se vuoi leggere la storia sulla funzione di attivazione/disattivazione in modo più dettagliato, lo consiglio vivamente . E c'è un meraviglioso articolo di Martin Fowler sulle funzionalità di attivazione/disattivazione: quali tipi esistono, cicli di vita, ecc. La funzionalità di attivazione/disattivazione è complicata.
E non hai ancora risposto alla domanda: "Jenkins è necessario o no?"
In ogni caso Jenkins non è davvero necessario. Scherzi a parte, gli strumenti: Jenkins, Gitlab ti offriranno comodità. Vedrai che l'assieme è assemblato o non assemblato. Possono aiutarti, ma non ti daranno pratica. Possono solo darti un cerchio: Ok, non Ok. E poi se scrivi anche dei test, perché se non ci sono i test allora è quasi inutile. Quindi serve perché è più conveniente, ma in generale puoi farne a meno, non ci perdi molto.
Cioè, se hai delle pratiche, significa che non ne hai bisogno?
Giusto. Raccomando il test Jez Humble. Lì ho un atteggiamento ambivalente nei confronti dell’ultimo punto. Ma in generale, se hai tre cose, le unisci costantemente, esegui test sui commit nel master, correggi rapidamente la build nel master, quindi forse non hai bisogno di nient'altro.
Mentre aspettiamo le domande dei partecipanti, ho una domanda. Stavamo proprio parlando del codice prodotto. L'hai usato per il codice dell'infrastruttura? È lo stesso codice, ha gli stessi principi e lo stesso ciclo di vita oppure esistono cicli di vita e principi diversi? Di solito, quando tutti parlano di integrazione e sviluppo continui, tutti dimenticano che esiste anche un codice infrastrutturale. E ultimamente ce ne sono sempre di più. E tutte queste regole dovrebbero essere portate lì?
Nemmeno che dovrebbe essere, sarebbe bellissimo perché renderebbe la vita più semplice allo stesso modo. Non appena lavoriamo con il codice, non con gli script bash, ma abbiamo un codice normale.
Stop, stop, anche uno script bash è codice. Non toccare il mio vecchio amore.
Ok, non calpesterò i tuoi ricordi. Ho un'antipatia personale per bash. Si rompe in modo brutto e spaventoso tutto il tempo. E spesso si rompe in modo imprevedibile, motivo per cui non mi piace. Ma ok, diciamo che hai il codice bash. Forse davvero non capisco e ci sono normali framework di test là fuori. È solo che non lo so. E otteniamo gli stessi vantaggi.
Non appena lavoriamo con l'infrastruttura come codice, incontriamo tutti gli stessi problemi degli sviluppatori. Alcuni mesi fa, mi sono imbattuto in una situazione in cui un collega mi ha inviato una richiesta pull di 1 righe in bash. E rimani alla revisione per 000 ore. Si presentano gli stessi problemi. E' ancora in codice. Ed è pur sempre una collaborazione. Rimaniamo bloccati con la richiesta pull e rimaniamo bloccati con il fatto che stiamo risolvendo gli stessi conflitti di unione nella stessa bash, ad esempio.
Ora sto guardando molto attivamente tutta questa faccenda sulla più bella programmazione infra. Ora ho portato Pulumi nell'infrastruttura. Questa è programmazione nella sua forma più pura. Lì è ancora più bello, perché ho tutte le capacità di un linguaggio di programmazione, cioè ho fatto all'improvviso dei bellissimi toggle con gli stessi se e va tutto bene. Cioè, la mia modifica è già nel master. Tutti possono già vederlo. Altri ingegneri lo sanno. Ha già influenzato qualcosa lì. Tuttavia non era abilitato per tutte le infrastrutture. Si è acceso, ad esempio, sui miei banchi prova. Pertanto, per rispondere nuovamente alla tua domanda, è necessario. Allo stesso modo semplifica la vita a noi ingegneri che lavorano con il codice.
Se qualcun altro ha domande?
Ho una domanda. Voglio continuare la discussione con Oleg. In generale, penso che tu abbia ragione, che se un compito richiede un mese per essere completato, allora hai un problema con l'architettura, hai un problema con l'analisi, la scomposizione, la pianificazione, ecc. Ma ho la sensazione che se inizi provando a vivere secondo l'Integrazione Continua, allora inizierai a correggere il dolore con la pianificazione, perché non te ne libererai da nessun'altra parte.
(Oleg) Sì, è vero. Questa pratica è paragonabile in termini di impegno a qualsiasi altra pratica seria che cambia la cultura. La cosa più difficile da superare sono le abitudini, soprattutto quelle cattive. E se per attuare questa pratica è necessario un serio cambiamento nelle abitudini di chi ti circonda: sviluppatori, management, direttore di produzione, allora ti aspettano sorprese.
Che sorprese potrebbero esserci? Diciamo che decidi che ti integrerai più spesso. E ci sono altre cose legate all'integrazione, ad esempio gli artefatti. E nella tua azienda, ad esempio, esiste una politica secondo cui ogni artefatto deve essere contabilizzato in qualche modo in una sorta di sistema di archiviazione degli artefatti. E ci vuole un po' di tempo. Una persona deve selezionare la casella che, in qualità di responsabile del rilascio, ha testato questo artefatto per assicurarsi che sia pronto per il rilascio in produzione. Se ci vogliono 5-10-15 minuti, ma fai il layout una volta alla settimana, spendere mezz'ora una volta alla settimana è una piccola tassa.
Se esegui l'integrazione continua 10 volte al giorno, è necessario moltiplicare 10 volte per 30 minuti. E questo supera la quantità di tempo di lavoro di questo gestore di rilascio. Si stanca semplicemente di farlo. Per alcune pratiche sono previsti costi fissi. È tutto.
E devi annullare questa regola in modo da non fare più tale spazzatura, ad es. non assegnare manualmente un grado per corrispondere a qualcosa. Ti affidi interamente a una serie automatizzata di test di preparazione.
E se hai bisogno di una prova da qualcuno, in modo che il capo la firmi e non entri in produzione senza che Vasya dica che lo consente, ecc. - tutte queste sciocchezze ostacolano il professionista. Perché se ci sono delle attività legate ad una tassa, allora tutto aumenta di 100 volte. Pertanto, il cambiamento spesso non sarà accolto con gioia da tutti. Perché le abitudini delle persone sono difficili da cambiare.
Quando una persona fa il suo solito lavoro, lo fa quasi senza pensare. Il suo carico cognitivo è zero. Ci gioca e basta, ha già una lista di controllo in testa, l'ha fatto mille volte. E appena vieni a dirgli: “Cancelliamo questa pratica e ne introduciamo una nuova da lunedì”, per lui diventa un carico cognitivo potente. E arriva a tutti in una volta.
Pertanto, la cosa più semplice, anche se non tutti possono permettersi questo lusso, ma questo è quello che faccio sempre, questa è la seguente. Se inizia un nuovo progetto, di solito tutte le pratiche non testate vengono immediatamente inserite in questo progetto. Sebbene il progetto sia giovane, non rischiamo davvero nulla. Non c'è ancora Prod, non c'è niente da distruggere. Pertanto, può essere utilizzato come allenamento. Questo approccio funziona. Ma non tutte le aziende hanno spesso l’opportunità di avviare tali progetti. Anche se anche questo è un po’ strano, perché ormai c’è una trasformazione digitale completa, tutti devono sperimentare per stare al passo con la concorrenza.
Qui arrivi alla conclusione che devi prima avere una comprensione di ciò che devi fare. Il mondo non è l’ideale, e nemmeno la produzione lo è.
Sì, queste cose sono interconnesse.
Inoltre, le aziende non sempre capiscono che devono seguire questa strada.
C'è una situazione in cui non è possibile alcun cambiamento. Questa è una situazione in cui c’è più pressione sulla squadra. La squadra è già abbastanza esaurita. Non ha tempo libero per nessun esperimento. Lavorano sulle funzionalità dalla mattina alla sera. E la gestione ha sempre meno funzionalità. Ne servono sempre di più. In una situazione del genere, non è possibile alcun cambiamento. Alla squadra si può solo dire che domani faremo come ieri, dobbiamo solo apportare qualche novità in più. In questo senso non è possibile alcun passaggio ad alcuna pratica. Questa è una situazione classica in cui non c'è tempo per affilare l'ascia, gli alberi devono essere abbattuti, quindi vengono tagliati con un'ascia smussata. Non ci sono consigli semplici qui.
(Dmitry) Leggerò un chiarimento dalla chat: “Ma abbiamo bisogno di molta copertura dei test a diversi livelli. Quanto tempo è assegnato ai test? È un po’ costoso e richiede molto tempo”.
(Oleg) Questo è un classico malinteso. Dovrebbero esserci abbastanza test per essere sicuro. L'integrazione continua non è una cosa in cui il 100% dei test viene eseguito prima e solo dopo si inizia ad applicare questa pratica. L'Integrazione Continua riduce il tuo carico cognitivo perché ognuno dei cambiamenti che vedi con i tuoi occhi è così evidente che capisci se romperà qualcosa oppure no, anche senza test. Puoi testarlo rapidamente nella tua testa perché i cambiamenti sono piccoli. Anche se disponi solo di tester manuali, anche per loro è più facile. Ti sei alzato e hai detto: "Guarda, c'è qualcosa di rotto?" Hanno controllato e hanno detto: "No, non è rotto nulla". Perché il tester sa dove guardare. Hai un commit associato a un pezzo di codice. E questo viene sfruttato da comportamenti specifici.
Qui tu, ovviamente, abbellito.
(Dmitry) Non sono d'accordo qui. Esiste uno sviluppo pratico basato sui test che ti salverà da questo.
(Oleg) Beh, non sono ancora arrivato a quel punto. La prima illusione è che devi scrivere il 100% dei test o non hai bisogno di fare l’integrazione continua. Non è vero. Si tratta di due pratiche parallele. E non sono direttamente dipendenti. La copertura del test deve essere ottimale. Ottimale: ciò significa che tu stesso sei sicuro che la qualità del master in cui è rimasto il tuo master dopo il commit ti consente di premere con sicurezza il pulsante "Distribuisci" in un venerdì sera ubriaco. Come si ottiene questo risultato? Attraverso la revisione, attraverso la copertura, attraverso un buon monitoraggio.
Un buon monitoraggio è indistinguibile dai test. Se esegui i test una volta in pre-produzione, controllano tutti gli script utente una volta e il gioco è fatto. E se li esegui in un ciclo infinito, allora questo è il tuo sistema di monitoraggio distribuito, che testa tutto all'infinito, indipendentemente dal fatto che si sia bloccato o meno. In questo caso, l’unica differenza è se viene eseguito una o due volte. Un'ottima serie di test... eseguiti all'infinito, questo è il monitoraggio. E un monitoraggio adeguato dovrebbe essere così.
E quindi, come raggiungerai esattamente questo stato quando ti preparerai venerdì sera e tornerai a casa è un'altra domanda. Forse sei solo un cialtrone audace.
Torniamo un po' all'integrazione continua. Siamo scappati in una pratica complessa leggermente diversa.
E la seconda illusione è che l'MVP, dicono, debba essere fatto rapidamente, quindi i test lì non sono affatto necessari. Non certamente in quel modo. Il fatto è che quando scrivi una user story in un MVP, puoi svilupparla sulla palla, cioè hai sentito che esiste una sorta di user story e sei subito corso a codificarla, oppure puoi lavorare utilizzando TDD. E secondo TDD, come dimostra la pratica, non ci vuole più tempo, cioè i test sono un effetto collaterale. La pratica del TDD non riguarda i test. Nonostante quello che viene chiamato Test Driven Development, non si tratta affatto di test. Anche questo è piuttosto un approccio architettonico. Questo è un approccio per scrivere esattamente ciò che è necessario e non scrivere ciò che non è necessario. Questa è una pratica che ti consente di concentrarti sulla successiva iterazione del tuo pensiero in termini di creazione di un'architettura applicativa.
Pertanto, non è così facile sbarazzarsi di queste illusioni. MVP e test non si contraddicono a vicenda. Anzi, al contrario, se esegui MVP usando la pratica TDD, lo farai meglio e più velocemente che se lo fai senza pratica, ma su una palla.
Questa è un'idea molto non ovvia e complessa. Quando senti dire che ora scriverò più test e allo stesso tempo farò qualcosa più velocemente, sembra assolutamente inadeguato.
(Dmitry) Molte persone qui, quando chiamano MVP, sono troppo pigre per scrivere qualcosa di normale. E queste sono cose ancora diverse. Non è necessario trasformare MVP in qualcosa di negativo che non funziona.
Sì, sì, hai ragione.
E poi all'improvviso MVP in prod.
Per sempre.
E TDD sembra molto insolito quando senti che scrivi test e sembra che tu faccia più lavoro. Sembra molto strano, ma in realtà in questo modo risulta più veloce e più carino. Quando scrivi un test, pensi già molto nella tua testa a come verrà chiamato il codice e come, nonché al comportamento che ci aspettiamo da esso. Non dici semplicemente che ho scritto una funzione e fa qualcosa. All'inizio pensavi che avesse queste e quelle condizioni, sarebbe stata chiamata in questo e quel modo. Lo copri con dei test e da questo capisci come appariranno le tue interfacce all'interno del tuo codice. Ciò ha un enorme impatto sull’architettura. Il tuo codice diventa automaticamente più modulare, perché prima cerchi di capire come testarlo e solo dopo lo scrivi.
Quello che mi è successo con TDD è che ad un certo punto ho assunto un mentore di Ruby quando ero ancora un programmatore di Ruby. E dice: “Facciamolo secondo TDD”. Ho pensato: “Cavolo, adesso devo scrivere qualcosa in più”. E abbiamo concordato che entro due settimane avrei scritto tutto il codice funzionante in Python usando TDD. Dopo due settimane, ho capito che non volevo tornare indietro. Dopo due settimane di tentativi di applicarlo ovunque, ti rendi conto di quanto sia diventato più facile per te anche solo pensare. Ma questo non è ovvio, quindi consiglio a tutti che, se avete la sensazione che il TDD sia difficile, dispendioso in termini di tempo e non necessario, provate a seguirlo solo per due settimane. A me ne sono bastati due.
(Dmitry) Possiamo espandere questa idea dal punto di vista del funzionamento dell'infrastruttura. Prima di lanciare qualcosa di nuovo, eseguiamo il monitoraggio e poi lanciamo. In questo caso il monitoraggio diventa per noi un normale test. E c'è sviluppo attraverso il monitoraggio. Ma quasi tutti dicono che è lungo, sono pigro, ho fatto una bozza provvisoria. Se abbiamo effettuato un monitoraggio normale, comprendiamo lo stato del sistema CI. E il sistema CI ha molto monitoraggio. Comprendiamo lo stato del sistema, capiamo cosa c'è al suo interno. E durante lo sviluppo, stiamo semplicemente realizzando il sistema in modo che raggiunga lo stato desiderato.
Queste pratiche sono note da molto tempo. Ne abbiamo parlato circa 4 anni fa. Ma in 4 anni praticamente non è cambiato nulla.
Ma con questa nota propongo di concludere la discussione ufficiale.
Video (inserito come elemento multimediale, ma per qualche motivo non funziona):
Fonte: habr.com