Migliori pratiche DevOps per gli sviluppatori. Anton Boyko (2017)

Il rapporto parlerà di alcune pratiche DevOps, ma dal punto di vista di uno sviluppatore. In genere, tutti gli ingegneri che aderiscono a DevOps hanno già diversi anni di esperienza amministrativa al loro attivo. Ma questo non significa che qui non ci sia posto per lo sviluppatore. Nella maggior parte dei casi, gli sviluppatori sono impegnati a risolvere “il prossimo bug urgentemente critico della giornata” e non hanno il tempo nemmeno di dare una rapida occhiata al campo DevOps. Secondo l'autore, DevOps è, in primo luogo, buon senso. In secondo luogo, è un’opportunità per essere più efficaci. Se sei uno sviluppatore, hai buon senso e desideri essere più efficace come giocatore di squadra, questo rapporto è per te.

Mi presento, ammetto pienamente che ci sono persone nella stanza che non mi conoscono. Mi chiamo Anton Boyko, sono un Microsoft Azure MVP. Cos'è l'MVP? Questo è Model-View-Presenter. Model-View-Presenter sono esattamente io.

Inoltre, attualmente ricopro la posizione di solution architect presso Ciklum. E proprio di recente mi sono comprato un dominio così bello e ho aggiornato la mia email, che di solito mostro alle presentazioni. Puoi scrivermi a: me [dog] byokoant.pro. Puoi inviarmi un'e-mail con domande. Di solito rispondo loro. L'unica cosa è che non vorrei ricevere domande via email che riguardano due argomenti: politica e religione. Puoi scrivermi per tutto il resto via e-mail. Passerà del tempo, risponderò.

Qualche parola su di te:

• Sono in questo campo ormai da 10 anni.
• Ho lavorato presso Microsoft.
• Sono il padre fondatore della comunità ucraina Azure, che abbiamo fondato da qualche parte nel 2014. E lo abbiamo ancora e lo stiamo sviluppando.
• Sono anche il padre del fondatore della conferenza Azure, che ospitiamo in Ucraina.
• Aiuto anche a organizzare il Global Azure Bootcamp a Kiev.
• Come ho detto, sono un MVP di Microsoft Azure.
• Parlo alle conferenze abbastanza spesso. Adoro parlare alle conferenze. Nell'ultimo anno ho potuto esibirmi circa 40 volte. Se passi per Ucraina, Bielorussia, Polonia, Bulgaria, Svezia, Danimarca, Paesi Bassi, Spagna o dai o prendi un altro paese in Europa, allora è del tutto possibile che quando vai a una conferenza che ha un tema cloud nel suo flusso, potresti vedermi nell'elenco dei relatori.
• Sono anche un fan di Star Trek.

Parliamo un po' dell'Agenda. La nostra agenda è molto semplice:

• Parleremo di cos'è DevOps. Parliamo del perché questo è importante. In precedenza, DevOps era una parola chiave che scrivevi sul tuo curriculum e ricevevi immediatamente +$500 di stipendio. Ora devi scrivere, ad esempio, blockchain nel tuo curriculum per ottenere +500 dollari al tuo stipendio.
• E poi, quando capiremo un po' di cosa si tratta, parleremo di quali sono le pratiche DevOps. Ma non tanto nel contesto di DevOps in generale, ma riguardo a quelle pratiche DevOps che potrebbero interessare agli sviluppatori. Ti dirò perché potrebbero interessarti. Ti dirò perché dovresti farlo e come può aiutarti a provare meno dolore.

Un'immagine tradizionale che molte persone mostrano. Questo è ciò che accade in molti progetti. Questo è il momento in cui disponiamo di reparti di sviluppo e operazioni che supportano il nostro software. E questi dipartimenti non comunicano tra loro.

Forse, se non fossi riuscito a percepirlo così chiaramente nei dipartimenti DevOps e operativi, potresti tracciare un'analogia con i dipartimenti Dev e QA. Ci sono persone che sviluppano software e ci sono persone del QA che sono pessime dal punto di vista degli sviluppatori. Ad esempio, metto il mio meraviglioso codice nel repository e c'è qualche mascalzone seduto lì che mi restituisce questo codice e dice che il tuo codice è cattivo.

Tutto questo accade perché le persone non comunicano tra loro. E si lanciano alcuni pacchetti, alcune applicazioni l'uno verso l'altro attraverso un muro di incomprensioni e cercano di fare qualcosa con loro.

È proprio questo muro che la cultura DevOps è progettata per distruggere, ad es. costringere le persone a comunicare tra loro e almeno a capire cosa fanno le diverse persone nel progetto e perché il loro lavoro è importante.

E quando parliamo di DevOps, qualcuno ti dirà che DevOps è quando il progetto ha un'integrazione continua; qualcuno dirà che DevOps lo è se il progetto implementa la pratica “infrastructure as code”; qualcuno dirà che il primo passo verso DevOps è la ramificazione delle funzionalità, i flag delle funzionalità.

In sostanza, tutto questo è vero a modo suo. Ma queste sono solo le pratiche definitive che abbiamo. Prima di passare a queste pratiche, ti suggerisco di guardare questa slide, che mostra le 3 fasi di implementazione della metodologia Dev-Ops nel tuo progetto, nella tua azienda.

Questa diapositiva ha anche un secondo nome non ufficiale. Puoi effettuare una ricerca online per scoprire quali sono i 3 moschettieri di DevOps. È possibile che troverai questo articolo. Perché 3 moschettieri? Sotto c'è scritto: persone, processi e prodotti, cioè PPP – Porthos, Porthos e Porthos. Ecco i 3 Moschettieri di DevOps. Questo articolo descrive in modo più dettagliato perché questo è importante e cosa comporta.

Quando inizi a implementare una cultura DevOps, è molto importante che venga implementata nel seguente ordine.

Inizialmente devi parlare con le persone. E devi spiegare alle persone di cosa si tratta e come possono trarne dei benefici.

La nostra conferenza si chiama DotNet Fest. E come mi hanno detto gli organizzatori, qui abbiamo invitato principalmente un pubblico di sviluppatori, quindi spero che la maggior parte delle persone presenti nella sala siano coinvolte nello sviluppo.

Parleremo di persone, parleremo di cosa gli sviluppatori vogliono fare ogni giorno. Cosa desiderano di più? Vogliono scrivere del nuovo codice, utilizzare framework nuovi, creare nuove funzionalità. Cosa vogliono meno gli sviluppatori? Correggi vecchi bug. Spero che tu sia d'accordo con me. Questo è ciò che vogliono gli sviluppatori. Vogliono scrivere nuove funzionalità, non vogliono correggere i bug.

Il numero di bug prodotti da un particolare sviluppatore dipende da quanto sono dritte le sue braccia e da quanto crescono dalle sue spalle e non dalle sue tasche. Tuttavia, quando abbiamo un progetto di grandi dimensioni, a volte capita che sia impossibile tenere traccia di tutto, quindi sarebbe carino per noi utilizzare alcuni approcci che ci aiutino a scrivere codice più stabile e di qualità superiore.

Cosa desiderano di più i QA? Non so se sono nella sala. È difficile per me dire che voglio un QA, perché non lo sono mai stato. E senza offesa per i ragazzi, si dirà che spero di non farlo mai. Ma non perché considero il loro lavoro privo di significato e inutile, ma perché non mi considero una persona che potrebbe svolgere questo lavoro in modo efficiente, quindi non proverò nemmeno a farlo. Ma da quello che ho capito, ciò che non piace di più al QA è che funzionerà la mattina, eseguendo costantemente una sorta di test di regressione, calpestando gli stessi bug che hanno segnalato agli sviluppatori 3 sprint fa e dicendo: "Quando lo farai?" , Signor d'Artagnan, sistemate questo bug.' E il signor D'Artagnan gli risponde: "Sì, sì, sì, ho già sistemato." E come è successo che ho corretto un bug e ne ho creati 5 lungo il percorso.

Le persone che supportano questa soluzione in produzione vogliono che questa soluzione funzioni senza bug, in modo da non dover riavviare il server ogni venerdì, quando tutte le persone normali vanno al bar. Gli sviluppatori hanno effettuato la distribuzione venerdì, gli amministratori restano seduti fino a sabato, cercando di avviare e correggere questa distribuzione.

E quando spieghi alle persone che mirano a risolvere gli stessi problemi, puoi passare alla formalizzazione dei processi. È molto importante. Perché? Perché quando diciamo "formalizzazione", è importante che tu descriva come si svolgono i tuoi processi almeno da qualche parte su un tovagliolo. È necessario comprendere che se, ad esempio, si esegue la distribuzione in un ambiente di controllo qualità o in un ambiente di produzione, ciò avviene sempre in questo ordine; in queste fasi eseguiamo, ad esempio, unit test automatici e test dell'interfaccia utente. Dopo la distribuzione, controlliamo se la distribuzione è andata bene o male. Ma hai già un elenco chiaro di azioni che devono essere ripetute più e più volte durante la distribuzione in produzione.

E solo quando i tuoi processi sono formalizzati, inizi a selezionare prodotti che ti aiuteranno ad automatizzare questi processi.

Sfortunatamente, molto spesso vedo che ciò accade al contrario. Non appena qualcuno sente la parola "DevOps", suggerisce immediatamente di installare Jenkins, perché crede che non appena installerà Jenkins, avrà DevOps. Hanno installato Jenkins, hanno letto gli articoli "Come fare per" sul sito web di Jenkins, hanno provato a inserire i processi in questi articoli Come fare per, e poi si sono rivolti alle persone e si sono piegati in avanti, dicendo che il libro dice che devi farlo in questo modo, quindi lo facciamo in questo modo.

Non è che Jenkins sia un cattivo strumento. Non intendo dirlo in alcun modo. Ma questo è solo uno dei prodotti. E quale prodotto utilizzare dovrebbe essere la tua ultima decisione, e non la prima. Il tuo prodotto non dovrebbe essere guidato dall’implementazione di cultura e approcci. Questo è molto importante da capire, ed è per questo che dedico così tanto tempo a questa diapositiva e spiego tutto questo per così tanto tempo.

Parliamo delle pratiche DevOps in generale. Quali sono? Qual è la differenza? Come provarli? Perché sono importanti?

La prima pratica di cui potresti aver sentito parlare si chiama Integrazione Continua. Forse qualcuno nel progetto ha l'integrazione continua (CI).

Il problema più grande è che molto spesso quando chiedo a una persona: “Hai CI nel progetto?” e lui dice: "Sì", poi quando gli chiedo cosa fa, mi descrive assolutamente l'intero processo di automazione. Questo non è del tutto vero.

In effetti, la pratica della CI mira semplicemente a integrare il codice che persone diverse scrivono in una sorta di unica base di codice. È tutto.

Insieme alla CI, di solito ci sono altre pratiche lungo il percorso, come la distribuzione continua e la gestione del rilascio, ma ne parleremo più avanti.

La stessa CI ci dice che persone diverse scrivono codice e questo codice deve essere continuamente integrato in un'unica codebase.

Cosa ci offre questo e perché è importante? Se abbiamo DotNet, allora va bene, è un linguaggio compilato, possiamo compilare la nostra applicazione. Se viene compilato, questo è già un buon segno. Questo non significa ancora nulla, ma è il primo buon segno che possiamo almeno compilare.

Quindi possiamo eseguire alcuni test, che è anche una pratica separata. I test sono tutti verdi: questo è il secondo buon segno. Ma ancora una volta, questo non significa nulla.

Ma perché dovresti farlo? Tutte le pratiche di cui parlerò oggi hanno all'incirca lo stesso valore, ad es. approssimativamente gli stessi benefici e sono anche misurate approssimativamente allo stesso modo.

Innanzitutto, ti consente di accelerare la consegna. In che modo questo ti consente di accelerare la consegna? Quando apportiamo nuove modifiche al nostro codice base, possiamo immediatamente provare a fare qualcosa con questo codice. Non aspettiamo fino a giovedì perché giovedì lo rilasciamo a QA Environment, lo facciamo proprio qui e proprio qui.

Ti racconterò una storia triste della mia vita. È stato tanto tempo fa, quando ero ancora giovane e bello. Adesso sono già giovane, bella, intelligente e modesta. Qualche tempo fa ero in un progetto. Avevamo un grande team di circa 30 sviluppatori. E avevamo un grande, grande progetto Enterprise che si è sviluppato per circa 10 anni. E avevamo filiali diverse. Nel repository avevamo un ramo in cui camminavano gli sviluppatori. E c'era un ramo che mostrava la versione del codice in produzione.

Il ramo di produzione era indietro di 3 mesi rispetto al ramo disponibile per gli sviluppatori. Cosa significa questo? Ciò significa che non appena ho un bug da qualche parte che va in produzione per colpa degli sviluppatori, perché lo hanno permesso, e per colpa del QA, perché lo hanno esaminato, allora significa che se ricevo un attività per l'hotfix per la produzione, quindi devo ripristinare le modifiche al codice 3 mesi fa. Devo ricordare quello che avevo 3 mesi fa e provare a risolverlo lì.

Se non hai ancora avuto questa esperienza, puoi provarla nel tuo progetto di casa. La cosa principale è non provarlo su uno commerciale. Scrivi un paio di righe di codice, dimenticale per sei mesi, quindi torna indietro e prova a spiegare rapidamente di cosa trattano quelle righe di codice e come puoi correggerle o ottimizzarle. È un'esperienza molto, molto emozionante.

Se disponiamo di una pratica di integrazione continua, ciò ci consente di verificarla con una serie di strumenti automatizzati proprio qui e proprio ora, non appena avrò scritto il mio codice. Questo potrebbe non darmi un quadro completo, ma eliminerà comunque almeno alcuni dei rischi. E se c'è qualche potenziale bug, lo saprò subito, cioè letteralmente tra un paio di minuti. Non avrò bisogno di tornare indietro di 3 mesi. Dovrò tornare indietro solo di 2 minuti. Una buona macchina da caffè non avrà nemmeno il tempo di preparare il caffè in 2 minuti, quindi è piuttosto interessante.

Questo ha il pregio che può essere ripetuto più volte su ciascun progetto, ad es. non solo quello su cui l'hai impostato. Puoi ripetere sia la pratica stessa che la CI stessa verrà ripetuta per ogni nuova modifica apportata al progetto. Ciò ti consente di ottimizzare le risorse perché il tuo team lavora in modo più efficiente. Non avrai più la situazione in cui ti arriva un bug dal codice con cui hai lavorato 3 mesi fa. Non avrai più bisogno di cambiare contesto quando ti siedi e trascorri le prime due ore cercando di capire cosa è successo in quel momento e di entrare nell'essenza del contesto prima di iniziare a correggere qualcosa.

Come possiamo misurare il successo o il fallimento di questa pratica? Se riferisci al grande capo cosa abbiamo implementato nel progetto CI, sentirà blah blah blah. L'abbiamo implementato, ok, ma perché, cosa ci ha portato, come lo misuriamo, quanto correttamente o erroneamente lo stiamo implementando?

La prima è che, grazie alla CI, possiamo effettuare il deploy sempre più spesso, e sempre più spesso proprio perché il nostro codice è potenzialmente più stabile. Allo stesso modo, il nostro tempo per trovare un errore si riduce e il tempo per correggerlo si riduce proprio perché riceviamo una risposta dal sistema proprio qui e in questo momento, cosa c'è che non va nel nostro codice.

Un'altra pratica che abbiamo è la pratica del test di automazione, che molto spesso viene fornita con la pratica CI. Vanno di pari passo.

Cosa è importante capire qui? È importante capire che i nostri test sono diversi. E ogni test automatizzato ha lo scopo di risolvere i propri problemi. Abbiamo, ad esempio, test unitari che ci consentono di testare un modulo separatamente, ad es. Come funziona nel vuoto? Questo è buono.

Disponiamo anche di test di integrazione che ci permettono di capire come i diversi moduli si integrano tra loro. È anche buono.

Potremmo avere test di automazione dell'interfaccia utente che ci consentono di verificare in che misura il lavoro con l'interfaccia utente soddisfa determinati requisiti stabiliti dal cliente, ecc.

I test specifici che esegui possono influenzare la frequenza con cui li esegui. I test unitari sono generalmente scritti brevi e brevi. E possono essere lanciati regolarmente.

Se parliamo di test di automazione dell'interfaccia utente, allora va bene se il tuo progetto è piccolo. I test di automazione dell'interfaccia utente possono richiedere un tempo adeguato. Ma di solito un test di automazione dell'interfaccia utente è qualcosa che richiede diverse ore su un progetto di grandi dimensioni. E va bene se dura qualche ora. L'unica cosa è che non ha senso eseguirli per ogni build. Ha senso eseguirli di notte. E quando tutti sono venuti al lavoro la mattina: sia i tester che gli sviluppatori, hanno ricevuto una sorta di rapporto secondo cui abbiamo eseguito il test automatico dell'interfaccia utente di notte e abbiamo ottenuto questi risultati. E qui, un'ora di lavoro di un server che controllerà che il tuo prodotto soddisfi alcuni requisiti sarà molto più economica di un'ora di lavoro dello stesso ingegnere QA, anche se è un ingegnere QA Junior che lavora per cibo e ringraziamenti. Tuttavia, un’ora di funzionamento della macchina sarà più economica. Ecco perché ha senso investirci.

Ho un altro progetto su cui sto lavorando. Abbiamo avuto sprint di due settimane su questo progetto. Il progetto era grande, importante per il settore finanziario e non si poteva commettere un errore. E dopo uno sprint di due settimane, il ciclo di sviluppo è stato seguito da un processo di test che ha richiesto altre 4 settimane. Prova a immaginare la portata della tragedia. Scriviamo il codice per due settimane, poi lo eseguiamo con CodeFreeze, lo pacchettizziamo in una nuova versione dell'applicazione e lo distribuiamo ai tester. I tester lo testano per altre 4 settimane, vale a dire Mentre lo stanno testando, abbiamo tempo di preparare altre due versioni per loro. Questo è un caso davvero triste.

E abbiamo detto loro che se vuoi essere più produttivo, ha senso implementare pratiche di test automatizzati, perché questo è ciò che ti fa male proprio qui, proprio ora.

Pratica la distribuzione continua. Ottimo, hai finito di costruire. Questo è già buono. Il tuo codice è stato compilato. Ora sarebbe bello distribuire questa build su qualche ambiente. Diciamo in un ambiente per sviluppatori.

Perché è importante? Innanzitutto, puoi verificare il tuo successo con il processo di distribuzione stesso. Ho incontrato progetti come questo, quando chiedo: “Come si distribuisce una nuova versione dell'applicazione?”, i ragazzi mi dicono: “Lo assembliamo e lo comprimiamo in un archivio zip. Lo inviamo all'amministratore via mail. L'amministratore scarica ed espande questo archivio. E l’intero ufficio comincia a pregare che il server prenda la nuova versione.”

Cominciamo con qualcosa di semplice. Ad esempio, si sono dimenticati di inserire i CSS nell'archivio o si sono dimenticati di modificare l'hashtag nel nome del file java-script. E quando facciamo una richiesta al server, il browser pensa di avere già questo file java-script e decide di non scaricarlo. E c'era una vecchia versione, mancava qualcosa. In generale, i problemi possono essere molti. Pertanto, la pratica della distribuzione continua ti consente almeno di testare cosa accadrebbe se prendessi un'immagine di riferimento pulita e la caricassi in un nuovo ambiente completamente pulito. Puoi vedere dove questo porta.

Inoltre, quando integri il codice tra loro, ad es. tra i comandi, questo ti permette anche di vedere come appare sull'interfaccia utente.

Uno dei problemi che si verificano quando si utilizzano molti script Java Vanilla è che due sviluppatori hanno dichiarato avventatamente una variabile con lo stesso nome nell'oggetto finestra. E poi, a seconda della fortuna. Il file Java-script di cui viene estratto per secondo sovrascriverà le modifiche dell'altro. È anche molto emozionante. Entri tu: una cosa funziona per una persona, un'altra non funziona per un'altra. Ed è “meraviglioso” quando tutto esce in produzione.

La prossima pratica che abbiamo è la pratica del ripristino automatico, ovvero il ripristino della versione precedente dell'applicazione.

Perché questo è importante per gli sviluppatori? C'è ancora chi ricorda i lontani, lontani anni '90, quando i computer erano grandi e i programmi erano piccoli. E l'unico modo per sviluppare il web era tramite PHP. Non è che PHP sia un brutto linguaggio, anche se lo è.

Ma il problema era diverso. Quando abbiamo distribuito una nuova versione del nostro sito php, come l'abbiamo distribuita? Molto spesso abbiamo aperto Far Manager o qualcos'altro. E ho caricato questi file su FTP. E all'improvviso ci siamo resi conto che avevamo qualche piccolo, piccolo bug, ad esempio, ci siamo dimenticati di mettere un punto e virgola o ci siamo dimenticati di cambiare la password per il database, e c'è una password per il database, che si trova sull'host locale. E decidiamo di connetterci rapidamente all'FTP e modificare i file proprio lì. Questo è solo fuoco! Questo è ciò che era popolare negli anni '90.

Ma se non hai guardato il calendario, gli anni '90 sono quasi 30 anni fa. Ora tutto sta accadendo in modo leggermente diverso. E provate a immaginare la portata della tragedia quando vi dicono: “Ci siamo messi in produzione, ma lì qualcosa è andato storto. Ecco il tuo login e la tua password FTP, connettiti alla produzione e correggilo rapidamente lì." Se sei Chuck Norris, funzionerà. In caso contrario, rischi che se risolvi un bug, ne creerai altri 10. Questo è proprio il motivo per cui questa pratica di tornare alla versione precedente ti consente di ottenere molto.

Anche se qualcosa di brutto in qualche modo viene prodotto da qualche parte, allora è brutto, ma non fatale. Puoi tornare alla versione precedente che hai. Chiamatelo backup, se è più facile percepirlo in quella terminologia. Puoi tornare a questa versione precedente e gli utenti saranno ancora in grado di lavorare con il tuo prodotto e avrai un tempo di buffer adeguato. Puoi tranquillamente, senza fretta, prendere tutto questo e testarlo localmente, correggerlo e quindi caricare una nuova versione. Ha davvero senso farlo.

Ora proviamo a combinare in qualche modo insieme le due pratiche precedenti. Ne avremo un terzo chiamato Release Management.

Quando parliamo di Continuous Deployment nella sua forma classica, diciamo che dobbiamo estrarre il codice da qualche ramo del repository, compilarlo e distribuirlo. Va bene se abbiamo lo stesso ambiente. Se abbiamo più ambienti significa che dobbiamo estrarre il codice ogni volta, anche dallo stesso commit. Lo tireremo fuori ogni volta, lo costruiremo ogni volta e lo implementeremo in un nuovo ambiente. In primo luogo, questo è tempo, perché per costruire un progetto, se ne hai uno grande e vieni dagli anni '90, possono essere necessarie diverse ore.

Inoltre c'è un'altra tristezza. Quando costruisci, anche sulla stessa macchina, creerai gli stessi sorgenti, non hai ancora alcuna garanzia che questa macchina sia nello stesso stato in cui si trovava durante l'ultima compilazione.

Diciamo che qualcuno è entrato e ha aggiornato DotNet per te o, al contrario, qualcuno ha deciso di eliminare qualcosa. E poi hai una dissonanza cognitiva che da questo commit due settimane fa stavamo costruendo una build e tutto andava bene, ma ora sembra che la stessa macchina, lo stesso commit, lo stesso codice che stiamo cercando di costruire, ma non funziona . Avrai a che fare con questo per molto tempo e non è un dato di fatto che lo capirai. Per lo meno, rovinerai molto i tuoi nervi.

Pertanto, la pratica di Release Management suggerisce di introdurre un'astrazione aggiuntiva chiamata repository di artefatti, galleria o libreria. Puoi chiamarlo come vuoi.

L'idea principale è che non appena abbiamo una sorta di commit lì, diciamo, in un ramo che siamo pronti a distribuire nei nostri diversi ambienti, raccogliamo le applicazioni da questo commit e tutto ciò di cui abbiamo bisogno per questa applicazione, lo imballiamo in un archivio zip e salvarlo in un archivio affidabile. E da questo spazio di archiviazione possiamo ottenere questo archivio zip in qualsiasi momento.

Quindi lo prendiamo e lo distribuiamo automaticamente nell'ambiente di sviluppo. Corriamo lì e, se tutto va bene, ci schieriamo sul palco. Se tutto va bene, distribuiamo in produzione lo stesso archivio, gli stessi binari, compilati esattamente una volta.

Inoltre, avere una galleria come questa ci aiuta anche ad affrontare i rischi di cui abbiamo parlato nell'ultima diapositiva quando abbiamo parlato del ripristino della versione precedente. Se hai accidentalmente distribuito qualcosa di sbagliato, puoi sempre prendere qualsiasi altra versione precedente da questa galleria e annullarne la distribuzione in questi ambienti nello stesso modo. Ciò ti consente di tornare facilmente alla versione precedente se qualcosa va storto.

C'è un'altra grande pratica. Tu e io capiamo tutti che quando riportiamo le nostre applicazioni a una versione precedente, ciò potrebbe significare che abbiamo bisogno anche dell'infrastruttura della versione precedente.

Quando parliamo di infrastruttura virtuale, molte persone pensano che sia qualcosa che gli amministratori configurano. E se hai bisogno, ad esempio, di ottenere un nuovo server su cui vuoi testare una nuova versione della tua applicazione, allora devi scrivere un ticket agli amministratori o ai devops. I Devops impiegheranno 3 settimane per questo. E dopo 3 settimane ti diranno che abbiamo installato per te una macchina virtuale, con un core, due gigabyte di RAM e un server Windows senza DotNet. Dici: "Ma volevo DotNet". Loro: “Ok, torna tra 3 settimane”.

L'idea è che utilizzando le pratiche Infrastructure as Code, puoi trattare la tua infrastruttura virtuale come un'altra risorsa.

Forse, se qualcuno di voi sta sviluppando applicazioni su DotNet, potrebbe aver sentito parlare di una libreria chiamata Entity Framework. E potresti anche aver sentito che Entity Framework è uno degli approcci che Microsoft sta promuovendo attivamente. Per lavorare con un database, questo è un approccio chiamato Code First. Questo è quando descrivi nel codice come vuoi che appaia il tuo database. E poi distribuisci l'applicazione. Si connette al database, determina lui stesso quali tabelle sono presenti e quali no e crea tutto ciò di cui hai bisogno.

Puoi fare lo stesso con la tua infrastruttura. Non c'è differenza tra se hai bisogno di un database per un progetto o se hai bisogno di un server Windows per un progetto. È solo una risorsa. E puoi automatizzare la creazione di questa risorsa, puoi automatizzare la configurazione di questa risorsa. Di conseguenza, ogni volta che desideri testare qualche nuovo concetto, qualche nuovo approccio, non avrai bisogno di scrivere un ticket per devops, puoi semplicemente implementare un'infrastruttura isolata per te stesso da modelli già pronti, da script già pronti e implementarla lì tutti i tuoi esperimenti. Puoi eliminarlo, ottenere alcuni risultati e riferire ulteriormente al riguardo.

La pratica successiva, anch'essa esistente ed importante, ma utilizzata da poche persone, è l'Application Performance Monitoring.

Volevo dire solo una cosa sul monitoraggio delle prestazioni delle applicazioni. Qual è la cosa più importante in questa pratica? Questo è ciò che il monitoraggio delle prestazioni dell'applicazione è più o meno come riparare un appartamento. Questo non è uno stato finale, è un processo. Devi farlo regolarmente.

In senso positivo, sarebbe bene eseguire il monitoraggio delle prestazioni dell'applicazione su quasi tutte le build, anche se, come capisci, ciò non è sempre possibile. Ma, come minimo, deve essere eseguito per ogni rilascio.

Perché è importante? Perché se improvvisamente si verifica un calo delle prestazioni, è necessario capirne chiaramente il motivo. Se il tuo team ha, ad esempio, sprint di due settimane, almeno una volta ogni due settimane dovresti distribuire la tua applicazione su un server separato, dove hai un processore, RAM, dischi, ecc. chiaramente fissi. Ed esegui gli stessi test delle prestazioni . Ottieni il risultato. Guarda come è cambiato rispetto allo sprint precedente.

E se scopri che il prelievo è diminuito drasticamente da qualche parte, vorrà dire che è stato solo a causa dei cambiamenti avvenuti nelle ultime due settimane. Ciò ti consentirà di identificare e risolvere il problema molto più velocemente. E ancora una volta, questi sono più o meno gli stessi parametri con cui puoi misurare il successo che hai ottenuto.

La pratica successiva che abbiamo è la pratica di gestione della configurazione. Sono pochissimi quelli che prendono questa cosa sul serio. Ma credetemi, questa è in realtà una cosa molto seria.

C'è stata una storia divertente di recente. I ragazzi sono venuti da me e mi hanno detto: "Aiutaci a condurre un controllo di sicurezza della nostra applicazione". Abbiamo guardato insieme il codice per molto tempo, mi hanno parlato dell'applicazione, hanno disegnato diagrammi. E più o meno tutto era logico, comprensibile, sicuro, ma ce n'era uno MA! Avevano file di configurazione nel controllo del codice sorgente, inclusi quelli della produzione con il database IP, con accessi e password per la connessione a questi database, ecc.

E io dico: "Ragazzi, ok, avete chiuso il vostro ambiente di produzione con un firewall, ma il fatto che abbiate login e password per il database di produzione direttamente nel controllo del codice sorgente e qualsiasi sviluppatore possa leggerlo è già un enorme rischio per la sicurezza . E non importa quanto sia estremamente sicura la tua applicazione dal punto di vista del codice, se la lasci nel controllo del codice sorgente, non supererai mai alcun controllo da nessuna parte. E' di questo che sto parlando.

Gestione della configurazione. Potremmo avere configurazioni diverse in ambienti diversi. Ad esempio, potremmo avere accessi e password diversi per i database per QA, demo, ambiente di produzione, ecc.

Questa configurazione può anche essere automatizzata. Dovrebbe essere sempre separato dall'applicazione stessa. Perché? Poiché hai creato l'applicazione una volta e quindi all'applicazione non importa se ti connetti al server SQL tramite questo e quell'IP o questo e quell'IP, dovrebbe funzionare allo stesso modo. Pertanto, se all'improvviso uno di voi sta ancora codificando la stringa di connessione nel codice, ricordate che vi troverò e vi punirò se vi troverete nello stesso progetto con me. Questo viene sempre inserito in una configurazione separata, ad esempio in web.config.

E questa configurazione è già gestita separatamente, cioè questo è esattamente il momento in cui uno sviluppatore e un amministratore possono sedersi nella stessa stanza. E lo sviluppatore può dire: “Guarda, ecco i binari della mia applicazione. Lavorano. L'applicazione necessita di un database per funzionare. Qui accanto ai binari c'è un file. In questo file, questo campo è responsabile del login, questo è della password, questo è dell'IP. Distribuitelo ovunque." Ed è semplice e chiaro per l'amministratore. Può implementarlo davvero ovunque gestendo questa configurazione.

E l'ultima pratica di cui vorrei parlare è una pratica molto, molto legata alle nuvole. E porta il massimo effetto se lavori nel cloud. Questa è la rimozione automatica del tuo ambiente.

So che a questa conferenza partecipano diverse persone dei team con cui lavoro. E con tutti i team con cui lavoro usiamo questa pratica.

Perché? Naturalmente, sarebbe fantastico se ogni sviluppatore avesse una macchina virtuale in grado di funzionare 24 ore su 7, 24 giorni su 7. Ma forse questa è una novità per te, forse non hai prestato attenzione, ma lo sviluppatore stesso non lavora 8 ore su 12, 5 giorni su 7. Uno sviluppatore di solito lavora XNUMX ore al giorno. Anche se arriva presto al lavoro, fa un pranzo abbondante durante il quale va in palestra. Lascia che siano XNUMX ore al giorno in cui lo sviluppatore utilizza effettivamente queste risorse. Secondo la nostra legislazione, XNUMX giorni su XNUMX in una settimana sono considerati giorni lavorativi.

Di conseguenza, nei giorni feriali questa macchina non dovrebbe funzionare 24 ore su 12, ma solo 70, e nei fine settimana questa macchina non dovrebbe funzionare affatto. Sembrerebbe che tutto sia molto semplice, ma cosa è importante dire qui? Implementando questa semplice pratica secondo questo programma di base, puoi ridurre i costi di manutenzione di questi ambienti del 3%, ovvero hai preso il prezzo di sviluppo, QA, demo e ambiente e lo hai diviso per XNUMX.

La domanda è: cosa fare con il resto dei soldi? Ad esempio, gli sviluppatori dovrebbero acquistare ReSharper se non l'hanno già fatto. Oppure organizza un cocktail party. Se in precedenza avevi un ambiente in cui sia lo sviluppo che il QA pascolavano, e basta, ora puoi crearne 3 diversi che saranno isolati e le persone non interferiranno tra loro.

Per quanto riguarda la diapositiva con misurazione continua delle prestazioni, come possiamo confrontare le prestazioni se avessimo 1 record nel database del progetto, due mesi dopo ce ne sono un milione? Come capire perché e che senso ha misurare la performance?

Questa è una buona domanda, perché dovresti sempre misurare le prestazioni sulle stesse risorse. Cioè, distribuisci il nuovo codice, misuri le prestazioni sul nuovo codice. Ad esempio, è necessario testare diversi scenari di prestazioni, supponiamo che tu voglia testare le prestazioni dell'applicazione con un carico leggero, dove sono presenti 1 utenti e la dimensione del database è di 000 gigabyte. L'hai misurato e hai ottenuto i numeri. Successivamente prendiamo un altro scenario. Ad esempio, 5 utenti, dimensione del database 5 terabyte. Abbiamo ricevuto i risultati e li abbiamo ricordati.

Cosa è importante qui? L’importante è che a seconda dello scenario, della quantità di dati, del numero di utenti simultanei ecc. si possono incontrare determinati limiti. Ad esempio, al limite della scheda di rete, al limite del disco rigido o al limite delle capacità del processore. Questo è ciò che è importante che tu capisca. In diversi scenari ti imbatti in determinati limiti. E devi capire i numeri quando li colpisci.

Stiamo parlando di misurare le prestazioni in un ambiente di test speciale? Cioè, questa non è produzione?

Sì, questa non è produzione, questo è un ambiente di test, sempre uguale per poterlo confrontare con le misurazioni precedenti.

Capito, grazie!

Se non ci sono domande, penso che possiamo finire. Grazie!

Fonte: habr.com