LFCA: apprendi i concetti di base di DevOps - Parte 21
DevOps è da tempo un argomento di tendenza ed è riuscito ad attirare l'attenzione sia dei professionisti della tecnologia che delle aziende. Come principiante, può essere difficile comprendere il concetto di DevOps e in questo argomento approfondiremo i concetti di base di questa parola d'ordine di Internet.
Per iniziare, DevOps è l'unione di due parole: Sviluppo e Operazioni. Si tratta di un insieme di pratiche e strumenti che promuovono la collaborazione tra i team di sviluppo (Devs) e le operazioni (Ops). L'obiettivo di DevOps è semplificare il ciclo di vita dello sviluppo del software, ridurre al minimo i tassi di errore, aumentare la frequenza delle implementazioni e ottenere software di alta qualità.
Per comprendere meglio DevOps nel moderno ambiente IT di oggi, diamo un'occhiata a come era il modello di distribuzione prima dell'avvento di DevOps.
Pratiche informatiche tradizionali
Prima di DevOps, i team di sviluppo e gli ingegneri del QA utilizzavano il classico modello a cascata. Il panorama lavorativo era in gran parte isolato e il test e la distribuzione delle applicazioni avvenivano in completo isolamento. Ciò ha comportato sovrapposizioni di compiti, lacune, ritardi nel feedback e altre inefficienze che hanno richiesto tempo aggiuntivo per completare il progetto. Il feedback limitato e ritardato ha fatto sì che la qualità del software non venisse controllata approfonditamente fino all'ultima fase di sviluppo.
Inoltre, la distribuzione manuale del codice era causata da errori umani e pertanto richiedeva più tempo per il debug delle applicazioni. Inoltre, i diversi team avevano diverse tempistiche per completare le proprie attività e non era raro che le tempistiche non fossero sincronizzate portando a ulteriori ritardi nella realizzazione del prodotto finale.
Entra in DevOps
Il concetto di DevOps è stato concepito tra il 2007 e il 2010 da due sviluppatori: Andrew Shafer e Patrick Debois. Fin dalla sua nascita, ha promosso una collaborazione fluida tra i team operativi e di sviluppo in ogni fase del ciclo di vita dello sviluppo del software. Ciò ha annunciato nuovi concetti come Integrazione continua ( CI ) e Consegna continua ( CD ) e molti altri che contribuiscono alla consegna rapida del software.
Modello e pratiche DevOps
DevOps non significa solo collaborazione e avere la giusta mentalità per raggiungere un obiettivo. Comprende le migliori pratiche volte a contribuire a fornire software di qualità e pronto per il mercato nel più breve tempo possibile. Diamo un'occhiata ad alcune di queste best practice che ti aiuteranno a aumentare l'efficienza e la consegna rapida del codice.
Integrazione continua (CI)
L'integrazione continua è una pratica di sviluppo software in cui gli sviluppatori uniscono le modifiche al codice in un unico repository centrale. Successivamente, sul codice vengono eseguiti test e build automatizzati. L'obiettivo dell'integrazione continua è accelerare il debug delle applicazioni, ridurre il tempo necessario per rilasciare nuovi aggiornamenti software e migliorare la qualità del software.
Consegna continua (CD)
La distribuzione continua (CD) è un'altra pratica in cui le modifiche al codice vengono create automaticamente e distribuite per test rigorosi. Successivamente, vengono eseguiti test automatizzati sul codice distribuito per consentire agli sviluppatori di identificare e correggere i bug. Di solito, il codice viene progressivamente sottoposto a molteplici ambienti di test dove, attraverso una procedura automatizzata standard, il codice raggiunge il massimo marchio di qualità.
Gli strumenti CI/CD più diffusi includono Jenkins, Travis CI, Circle CI, Azure DevOps e AWS Code build.
Test continui
L'obiettivo dei test continui è identificare bug e potenziali rischi nelle prime fasi del ciclo di vita dello sviluppo del software al fine di ridurre al minimo gli errori che si manifesterebbero nel prodotto finale. Quando il codice non supera i test rigorosi, viene solitamente rimandato allo sviluppatore per la revisione prima di essere trasmesso al dipartimento di controllo qualità per valutazioni e test funzionali. Gli strumenti di test continui ampiamente utilizzati includono Travis e Selenium.
Monitoraggio e accesso continui
Come ci si aspetterebbe, le applicazioni e l'infrastruttura sottostante richiedono un monitoraggio continuo per verificare l'identità delle prestazioni, eventuali errori o difetti e garantire la conformità ai vari standard di settore. Viene monitorata un'ampia varietà di parametri, tra cui:
- Utilizzo della memoria e della CPU
- Utilizzo dello spazio su disco
- Utilizzo della larghezza di banda
- Interazione con il cliente
Monitorando e analizzando dati e log generati dalle applicazioni, gli sviluppatori possono facilmente ottenere informazioni dettagliate sull'impatto delle funzionalità o delle configurazioni sugli utenti. Inoltre, la configurazione degli avvisi aiuterà a identificare errori o modifiche indesiderate in ogni fase del processo. In definitiva, il monitoraggio continuo garantisce l'elevata disponibilità delle applicazioni e ispira fiducia che le cose funzionino come previsto.
Gli strumenti di monitoraggio più diffusi includono Prometheus, Grafana, Nagios, Zabbix e Netdata per citarne alcuni.
Infrastrutture come codice
Abbreviato come IaC, Infrastructure as Code è descritto come l'implementazione e la gestione di risorse come server virtuali e bilanciatori del carico che utilizzano file di configurazione leggibili dalla macchina invece di strumenti di configurazione interattivi . Ciò è particolarmente essenziale negli ambienti cloud come AWS, dove puoi avviare facilmente istanze di calcolo definendo i dettagli dell'istanza in un file di configurazione e sfruttando strumenti come Terraform per distribuire le risorse.
Ad esempio, Amazon AWS fornisce API che consentono agli utenti di interagire in modo programmatico con la piattaforma cloud dalla riga di comando. Ciò facilita la rapida implementazione delle risorse eliminando processi manuali e rallentamenti. In poche parole, IaC riesce a svolgere più lavoro in un breve periodo di tempo.
Microservizi
L'architettura dei microservizi è quella in cui una singola applicazione è un'integrazione o una fusione di vari servizi più piccoli e liberamente accoppiati. Ogni servizio viene eseguito in modo indipendente e comunica con il resto delle applicazioni utilizzando API basate su HTTP. I microservizi possono essere distribuiti come gruppo di servizi o come singolo servizio
L'architettura dei microservizi è molto diversa dall'architettura monolitica tradizionale. Nell'architettura tradizionale, le applicazioni sono a livello singolo e tutti i componenti, inclusi il codice e l'interfaccia utente, sono raggruppati in un unico programma.
I microservizi facilitano la distribuzione e la gestione indipendente delle risorse. Garantiscono inoltre un'elevata disponibilità prevenendo un singolo punto di errore. quando una singola applicazione si arresta in modo anomalo, il resto continuerà a funzionare.
Vantaggi del modello DevOps
Dopo aver esaminato le best practice DevOps, concentriamoci ora sui vantaggi derivanti dall'adozione del modello DevOps.
Maggiore efficienza e produttività tra i team
La collaborazione tra i team di sviluppo e operativi si traduce in una responsabilità congiunta, che in definitiva aumenta la produttività e favorisce il coinvolgimento del team.
Probabilità ridotte di guasto del prodotto
La collaborazione consente inoltre ai team di eseguire facilmente il debug del codice in ogni fase prima di arrivare alla fase finale. Ciò produce software di alta qualità e pronto per il mercato.
Consegna rapida del software
La distribuzione delle applicazioni è più snella e molto più veloce grazie agli strumenti di automazione forniti da DevOps (come Ansible, Chef e Puppet) e all'integrazione continua avanzata (CI).
Maggiore trasparenza del prodotto
Poiché la conoscenza del prodotto è diffusa tra vari reparti, esiste un obiettivo e una visione chiari sul prodotto, che si traducono in un migliore processo decisionale in ogni fase dello sviluppo
Riepilogo
La convinzione radicata che i team di sviluppo e quelli operativi debbano lavorare sempre separatamente è obsoleta da tempo ed è difettosa. La filosofia dei compartimenti stagni può essere ancora viva in alcuni settori, ma ciò ha comportato evidenti inefficienze lungo il percorso.
DevOps mira a integrare i team di sviluppo e operativi e a promuovere un cambiamento culturale dal vecchio modo di lavorare in silos al lavoro in tandem per ridurre gli errori nel codice, migliorare la qualità del software, accelerare i tempi di consegna e aumentare la produttività complessiva. Alla fine l'utente finale si ritrova con un prodotto di alta qualità in modo tempestivo.