Introduzione a DevOps e Azure DevOps
Citando l'articolo introduttivo a questo nuovo canale, che andiamo ad inaugurare ufficialmente oggi, è evidente che il mondo che ruota attorno al software è cambiato notevolmente nel corso degli ultimi anni e cambierà ancor più esponenzialmente nei prossimi. La velocità con cui si scrive e si rilascia il software, gli accorgimenti sulla security, l'introduzione dei container sono solo alcune delle novità che ci hanno portato ad avere sempre di più le persone al centro di tutto, lasciando strumenti e processi in secondo piano.
DevOps è proprio questo, un sistema che ci aiuta nella trasformazione digitale per evolvere il modo in cui lavoriamo, un insieme di pratiche che aiutano a gestire meglio le persone e i prodotti che sviluppiamo. DevOps, o la figura del DevOps engineer, non sono solo buzzword del momento: segnano un netto cambio di passo e all'interno di questo articolo cercheremo di capire meglio quali sono le pratiche che stanno dietro a questo "nuovo mondo" e quali sono gli strumenti che ci possono dare una mano per essere più moderni e al passo coi tempi.
Che cos'è DevOps?
Possiamo a tutti gli effetti introdurre DevOps, anche se in modo leggermente improprio, come una nuova modalità di lavoro per tutti quelli che sono i team che si occupano o hanno almeno una componente software. Non esiste una definizione precisa di cosa sia DevOps, ma questo è dovuto al fatto che ogni persona che pensa di fare DevOps, adotta strategie e processi differenti perché, alla fine, tutto è basato sulle applicazioni che andiamo a rilasciare sui clienti e queste, per definizione, sono diverse una dall'altra. Tra le varie definizioni che si possono trovare, si può incorrere in questa:
DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.
Il "problema" di una definizione come questa è semplice: il processo di sviluppo (identificato come service lifecycle, design e supporto in produzione) sembra avere sulla priorità su tutto il resto. Sfortunatamente però il punto focale sono le persone, che sono i veri "strumenti" che sono in grado di rilasciare valore (incrementi di prodotto, piuttosto che bug fix, ad esempio) verso i propri clienti che useranno i servizi. Proprio per questo, pensiamo sia più indicato citare Donovan Brown, Principal DevOps Manager in Microsoft e la sua definizione:
Nonostante non ci sia una definizione ben precisa, cercheremo di capire all'interno di questo articolo quelle che sono alcune delle pratiche e i primi strumenti da adottare per "fare DevOps". Dalla definizione data, però, è evidente che le persone sono al centro di tutto e gli strumenti, che fino ad oggi sono stati il punto centrale delle discussioni tecniche, diventano l'ultimo dei problemi.
Perché si sente il bisogno di un nuovo modello? La risposta è, in realtà, più banale del previsto: i tempi cambiano. Pensiamo solamente a com'era scrivere software e quali erano le figure necessarie a creare un prodotto meno di 10 anni fa. Sicuramente fra queste comparivano:
- Gli sviluppatori, il cui obiettivo è esclusivamente quello di scrivere software, focalizzandosi su quella che è considerata la "business logic";
- I tester, che hanno come compito la scrittura e la manutenzione dei test che, però, sono spesso eseguiti in modalità manuale poiché i tester si installano il prodotto direttamente sui loro PC che rispettano una configurazione ben precisa;
- I sistemisti, responsabili di tutta l'area infrastrutturale, di sicurezza sia sui dati che a livello di rete tramite la gestione di VPN, si occupano anche di tutta quella che è la parte di patching di eventuali virtual machine, sistemi operativi, schede madri che si rompono, dischi da sostituire etc.;
- I DBA, presenti spesso solo nelle aziende "più fortunate", si occupano della manutenzione di tutte le pipeline di ETL principalmente su dati strutturati.
Benché tutto questo funzioni tutt'ora oggi, probabilmente anche per la maggior parte delle aziende, tecnologicamente parlando sono stati fatti passi da gigante e, di fatto, sono cambiate sia le tecnologie e i software veri e propri che vengono usati dai vari engineer, che i processi dato che devono essere ben strutturati, le modalità di lavoro, che devono prevedere rilasci sempre a cadenze più veloci e, di conseguenza, sono cambiati anche i ruoli delle persone che lavorano sui progetti, per adeguarsi a tutte queste modifiche.
Facendo qualche paragone tecnologico, fino a pochissimi anni fa, non si parlava mai di strumenti come Docker, per containerizzare le nostre applicazioni o di Kubernetes, per orchestrare i container. Pochi adottavano il cloud per via dei costi, quando invece, tramite l'avvento dei servizi gestiti, si è rivelato essere molto più economico se sfruttato come si deve. Per chi viene dal mondo .NET invece, noterà grossi cambiamenti anche a livello di framework, in quanto, grazie all'introduzione di ASP.NET Core, non si è più obbligati ad avere macchine Windows per fare il deploy ma si può anche rilasciare in ambiente Linux o macOS, il framework può essere installato side-by-side e non più machine-wide e, soprattutto, non è più necessario conoscere solamente IIS.
Se guardiamo anche com'è evoluto il mercato nel corso di quest'ultimo decennio, noteremo che anche in questo caso ci sono molteplici differenze: la prima è che il cliente adesso è più centrale che mai e quindi le applicazioni devono essere disegnate con un certo focus verso quella che è la user experience migliore, ma, allo stesso tempo, in caso di eventuali malfunzionamenti bisogna essere in grado di fare il delivery degli aggiornamenti nel più breve tempo possibile e questo è fattibile solo sfruttando dei processi ben definiti e avendo a supporto di questi processi un team di persone che sa coordinarsi e lavorare bene in squadra. Stessa cosa vale per uno scenario diverso, il feedback, che ora è continuo, dal cliente fino al team di sviluppo, che deve però diventare proattivo per monitorare l'uso delle applicazioni e arrivare a capire che cosa vorrà il cliente nella prossima versione del prodotto così che l'effort (e il budget) vengano concentrati su alcune aree piuttosto che su altre.
In un mondo in cui tutto cambia così velocemente, le persone non possono fare altro che cambiare i loro ruoli per soddisfare queste nuove esigenze e, da qui, nasce appunto il termine DevOps. Non parliamo più, infatti, di ruoli troppo definiti e troppo verticali, tutte le persone del team lavorano insieme per fare la delivery verso il cliente il prima possibile, con un prodotto che abbia la più alta qualità e, se tutte (o almeno la maggior parte) delle procedure è automatizzata, tutto quello che ora sembra complesso per chi non adotta queste pratiche (anche se è solo una questione mentale), dovrebbe diventare più semplice. Per dimostrare quanto beneficio porti l'adottare pratiche DevOps nei processi aziendali, DORA, un'azienda americana il cui acronimo sta per DevOps Research and Assessment, rilascia ogni anno un report con quelli che sono i risultati dovuti alla ricerca. Il grafico parla chiaro:
Sebbene abbiamo ripetuto più volte che DevOps non è solo strumenti e processi, non è possibile, per brevità, includere all'interno di questo articolo quelle che sono le tematiche più importanti riguardo alla gestione delle persone o alle modalità di lavoro. Nonostante questo lo vedremo con articoli dedicati, per ora ci limitiamo a capire le parti "più semplici" riguardanti pratiche comuni che possono essere adottate per chi deve ancora "fare lo switch a DevOps".
Contenuti dell'articolo
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Usare le navigation property in QuickGrid di Blazor
Utilizzare un service principal per accedere a Azure Container Registry
Potenziare Azure AI Search con la ricerca vettoriale
Eseguire i worklow di GitHub su runner potenziati
Hosting di componenti WebAssembly in un'applicazione Blazor static
Utilizzare database e servizi con gli add-on di Container App
Recuperare l'ultima versione di una release di GitHub
Popolare una classe a partire dal testo, con Semantic Kernel e ASP.NET Core Web API
Miglioramenti nell'accessibilità con Angular CDK
Migliorare i tempi di risposta di GPT tramite lo streaming endpoint in ASP.NET Core
Eseguire una ricerca avanzata per recuperare le issue di GitHub
Implementare l'infinite scroll con QuickGrid in Blazor Server
Sommario
Top Ten Articoli
- Realizzare una Progressive Web Application con Blazor e ASP.NET Core
di Giampaolo Tucci - Gestire le chiamate a servizi esterni in ASP.NET Core e Blazor tramite Polly
di Morgan Pizzini - Usare gRPC come infrastruttura per i nostri servizi web
di Morgan Pizzini - Abilitare e gestire il prerendering nelle applicazioni Blazor WebAssembly
di Marco De Sanctis - Creare API GraphQL con ASP.NET Core e HotChocolate
di Moreno Gentili - Le novità di Blazor in .NET 6.0
di Morgan Pizzini - Blazor e il pattern Model-View-ViewModel
di Giampaolo Tucci - Le novità in ASP.NET Core e Blazor con .NET 7
di Morgan Pizzini - Introduzione a Blazor WebAssembly
di Marco De Sanctis, Moreno Gentili - Le novità di ASP.NET Core 5
di Marco De Sanctis
Articoli via e-mail
Iscriviti alla nostra newsletter nuoviarticoli per ricevere via e-mail le notifiche!
In primo piano
I più letti di oggi
- Effettuare il log delle chiamate a function di GPT in ASP.NET Web API
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- Utilizzare il metodo CountBy di LINQ per semplificare raggruppamenti e i conteggi
- Creare una libreria CSS universale: Cards
- Eseguire script pre e post esecuzione di un workflow di GitHub
In evidenza
- Il meglio della settimana
- Utilizzare il metodo CountBy di LINQ per semplificare raggruppamenti e i conteggi
- Eseguire script pre e post esecuzione di un workflow di GitHub
- Creare una libreria CSS universale: Cards
- Migliorare l'organizzazione delle risorse con Azure Policy
- Effettuare il log delle chiamate a function di GPT in ASP.NET Web API
- Leggere la posta usando il protocollo IMAP tramite la libreria MailKit
- Eseguire una ricerca avanzata per recuperare le issue di GitHub