Cos'è DevOps?
sfondo blu
Cos'è DevOps?

DevOps velocizza la fornitura di software di qualità superiore combinando e automatizzando il lavoro dei team di sviluppo software e di operazioni IT.

Per definizione, DevOps delinea un processo di sviluppo del software e un cambiamento di cultura organizzativa che accelera la distribuzione di software di qualità superiore automatizzando e integrando gli sforzi dei team di sviluppo e funzionamento IT , due gruppi che tradizionalmente operano separatamente l'uno dall'altro, o in silos.

In pratica, i processi e le culture DevOps migliori si estendono oltre lo sviluppo e le operazioni per incorporare gli input di tutti i soggetti interessati dell'applicazione, compresi l'ingegneria della piattaforma e dell'infrastruttura, la sicurezza, la conformità, la governance, la gestione del rischio, la linea di business, gli utenti finali e i clienti, nel  ciclo di vita di sviluppo del software.

DevOps rappresenta lo stato attuale dell'evoluzione dei cicli di fornitura di software degli ultimi 20 anni e oltre, da enormi release di codice a livello applicazione per un certo numero di mesi o anche anni ad aggiornamenti funzionali o di funzioni iterativi di dimensioni più contenute, rilasciati con una frequenza giornaliera o diverse volte al giorno.

In definitiva, DevOps è la risposta alla sempre crescente esigenza degli utenti software di disporre di nuove funzioni frequenti e innovative e di poter contare su prestazioni e disponibilità ininterrotte.

Microservizi in ambito aziendale, 2021 - La nuova ricerca IBM rivela i vantaggi e le sfide derivanti dall'adozione dei microservizi.

Scarica l'ebook


Come siamo arrivati a DevOps

Fino a poco prima del 2000, la maggior parte dei software veniva sviluppato e aggiornato utilizzando la metodologia waterfall, un approccio lineare ai progetti di sviluppo su vasta scala. I team di sviluppo del software dedicavano mesi a sviluppare ampie porzioni di nuovo codice che avevano un impatto su gran parte dell'applicazione, se non su tutta. Poiché le modifiche erano così estese, dedicavano poi ancora diversi mesi a integrare il nuovo codice nella base di codice. 

I team di QA (quality assurance), di sicurezza e delle operazioni dedicavano quindi ancora altri mesi a testare il codice. Tutto questo si traduceva in mesi o anche anni tra le release di software e, spesso, anche in diverse patch o correzioni di bug di una certa entità tra le release. E questo approccio "big bang" alla fornitura di funzioni era spesso caratterizzato da piani di implementazione complessi e rischiosi, incastri di difficile pianificazione con i sistemi upstream e downstream e una "grande speranza" dell'IT che i requisiti di business non fossero cambiati drasticamente nei mesi necessari alla produzione per essere finalmente pronta.

Per accelerare lo sviluppo e migliorare la qualità, i team di sviluppo hanno iniziato ad adottare delle metodologie di sviluppo del software agili, iterative piuttosto che lineari, e si concentrano sulla creazione di aggiornamenti più piccoli e frequenti alla base di codice delle applicazioni. Le principali tra queste metodologie sono integrazione continua e distribuzione continua, o CI/CD. In CI/CD, porzioni più piccole di nuovo codice vengono incorporate nel codice di base con cadenza settimanale o quattordicinale e quindi integrate, testate e preparate per l'implementazione nell'ambiente di produzione in modo automatico. Questo approccio agile ha fatto evolvere quello di tipo "big bang" in una serie di "scatti più piccoli" che hanno anche compartimentato i rischi.

Quanto più efficacemente queste pratiche di sviluppo agile hanno accelerato lo sviluppo e la distribuzione del software, tanto più hanno esposto le operazioni IT ancora in sospeso, quali fornitura del sistema, configurazione, test di accettazione, gestione, monitoraggio, come il prossimo collo di bottiglia nel ciclo di vita della distribuzione del software. 

Quindi DevOps trae origine dall'agilità. Ha aggiunto nuovi processi e strumenti che estendono l'iterazione e l'automazione continue di CI/CD al resto del ciclo di vita di fornitura del software. E ha implementato una stretta collaborazione tra sviluppo e operazioni a ogni passo del processo.

Prodotti in evidenza

UrbanCode Deploy

UrbanCode Velocity

Rational Test Workbench

IBM Architecture Room Live

IBM Cloud Pak for Watson AIOps


Come funziona DevOps: il ciclo di vita di DevOps

Il ciclo di vita di DevOps (a volte denominato pipeline di fornitura continua, quando è rappresentato in modo lineare) consiste in una serie di flussi di lavoro o processi di sviluppo iterativi e automatizzati, eseguiti all'interno di un più ampio ciclo di vita di sviluppo automatizzato e iterativo progettato per ottimizzare la rapida fornitura di software di alta qualità. Il nome e il numero dei flussi di lavoro possono variare a seconda dell'interlocutore, ma si riduce sostanzialmente ai sei indicati di seguito:

  • Progettazione (o ideazione). In questo flusso di lavoro, i team valutano il potenziale delle nuove funzioni e della nuova funzionalità nella prossima release, traendo spunto dai case study e dal feedback degli utenti finali a cui è stata assegnata la priorità e dai contributi di tutte le parti interessate interne. L'obiettivo nella fase di pianificazione è quello di massimizzare il valore di business del prodotto creando un backlog di funzioni che, quando fornite, produrranno un risultato desiderato che abbia valore.
  • Sviluppo. Questa è la fase di programmazione, quando gli sviluppatori testano, codificano e creano funzioni nuove e migliorate, basate sulle storie degli utenti e sugli elementi di lavoro presenti nel backlog. È comune una combinazione di prassi quali, tra le altre, lo sviluppo basato su test (TDD), la programmazione in coppia e le revisioni paritarie del codice. Gli sviluppatori spesso utilizzano le loro workstation locali per eseguire il "loop interno" di scrittura e test del codice prima di farlo proseguire lungo la pipeline di fornitura continua.
  • Integrazione (o creazione o integrazione continua e fornitura continua (CI/CD). Come osservato in precedenza, in questo flusso di lavoro il nuovo codice viene integrato e impacchettato in un eseguibile per l'implementazione. Le attività di automazione comuni includono l'incorporazione delle modifiche del codice in una copia "master", l'estrazione (check-out) di tale codice da un repository di codice sorgente e l'automazione di compilazione, unit test e impacchettamento in un eseguibile. La best practice consiste nell'archiviare l'output della fase CI in un repository binario per la fase successiva.
  • Implementazione (in genere chiamata implementazione continua). Qui l'output di compilazione di runtime (dall'integrazione) viene distribuito a un ambiente di runtime, in genere un ambiente di sviluppo dove vengono eseguiti test di runtime per la qualità, la conformità e la sicurezza. Se vengono trovati degli errori o dei difetti, gli sviluppatori hanno la possibilità di intercettarli e correggerli prima che vengano riscontrati dagli utenti finali. Esistono generalmente degli ambienti per lo sviluppo, i test e la produzione, ciascuno dei quali richiede, in modo progressivo, delle misure di qualità più stringenti. Una buona prassi per l'implementazione in un ambiente di produzione consiste generalmente nell'eseguire l'implementazione prima presso un sottoinsieme di utenti finali e infine, una volta conseguita la stabilità, presso tutti gli utenti.
  • Operazioni. Se ottenere caratteristiche consegnate ad un ambiente di produzione è caratterizzato come "Giorno 1", allora una volta che le caratteristiche sono in esecuzione in produzione si verificano le operazioni del "Giorno 2". Il monitoraggio delle prestazioni, del comportamento e della disponibilità delle funzioni garantisce che siano in grado di fornire valore aggiunto agli utenti finali. Le operazioni assicurano che le caratteristiche funzionino senza problemi e che non ci siano interruzioni nel servizio, assicurandosi che la rete, lo storage, la piattaforma, il calcolo e la posizione in materia di sicurezza siano integri. Se qualcosa va male, le fase delle operazioni assicura che gli incidenti vengano identificati, che venga avvisato il personale adeguato, che i problemi vengano determinati e che le correzioni vengano applicate.
  • Apprendimento (a volte chiamato feedback continuo). Si tratta della raccolta dei feedback dagli utenti finali e dai clienti relativi a funzioni, funzionalità, prestazioni e valore di business di cui poi servirsi in fase di pianificazione dei miglioramenti e delle funzioni della release successiva. Questo include anche gli elementi di apprendimento e di backlog dalle attività della fase delle operazioni, che possono consentire agli sviluppatori di evitare in modo proattivo gli eventuali incidenti passati che potrebbero verificarsi di nuovo in futuro. Questo è il punto in cui avviene il cosiddetto "wraparound" della fase di pianificazione e che noi "miglioriamo continuamente".

Tra questi flussi di lavoro si verificano altri tre importanti flussi di lavoro continui:

Test continuo: i classici cicli di vita di DevOps includono una discreta fase di "test" che si verifica tra l'integrazione e l'implementazione. Tuttavia, DevOps è avanzato in modo tale che alcuni elementi di test possono verificarsi nella pianificazione (sviluppo guidato dal comportamento), sviluppo (test delle unità, test dei contratti), integrazione (scansioni statiche del codice, scansioni CVE, linting), implementazione (smoke test, test di penetrazione, test di configurazione), operazioni (test del caos, test di conformità) e apprendimento (test A/B). L'esecuzione di test è una potente forma di identificazione di rischi e vulnerabilità e offre all'IT un'opportunità per accettare, mitigare o correggere i rischi.

Sicurezza: mentre le metodologie a cascata e le implementazioni agili "attaccano" i flussi di lavoro sulla sicurezza dopo la consegna o la distribuzione, DevOps si sforza di incorporare la sicurezza dall'inizio (pianificazione), quando i problemi di sicurezza sono più facili e meno costosi da affrontare, e continuamente durante il resto del ciclo di sviluppo. Questo approccio alla sicurezza è indicato come shift-left (che è più facile guardando la Figura 1). Alcune organizzazioni hanno avuto meno successo con lo shift-left rispetto ad altre, e questo ha portato allo sviluppo di DevSecOps (vedi di seguito).

Conformità. La conformità normativa  (governance e rischio) si affronta meglio nella fase iniziale e nel corso dell'intero ciclo di vita dello sviluppo. I settori regolamentati sono spesso tenuti a fornire un certo livello di osservabilità, tracciabilità e accesso al modo in cui le funzioni vengono fornite e gestite nel loro ambiente operativo di runtime. Ciò richiede pianificazione, sviluppo, verifica e implementazione di politiche nella pipeline di fornitura continua e nell'ambiente di runtime. La verificabilità delle misure di conformità è estremamente importante per provare la conformità ad auditor esterni.


Cultura DevOps

È generalmente accettato che i metodi DevOps non possono funzionare senza un impegno nella cultura DevOps, che può essere riassunta come un diverso approccio organizzativo e tecnico allo sviluppo del software.

A livello organizzativo, DevOps richiede comunicazione continua, collaborazione e responsabilità condivisa tra tutte le parti interessate alla distribuzione del software, team di sviluppo del software e operazioni IT, ma anche team responsabili della sicurezza, della conformità, della governance, dei rischi e della line-of-business, per innovare rapidamente e continuamente e per favorire la qualità nel software fin dall'inizio.

Nella maggior parte dei casi, il modo migliore per raggiungere questo obiettivo è quello di rompere questi silos e riorganizzarli in team DevOps autonomi e interfunzionali che possono lavorare su progetti di codice dall'inizio alla fine, vale a dire dalla pianificazione al feedback, senza passaggi o senza aspettare le approvazioni di altri team. Quando sono messe nel contesto di uno sviluppo agile, la responsabilità condivisa e la collaborazione sono la base di un focus sul prodottocondiviso che produce un risultato di valore.

A livello tecnico, DevOps richiede un impegno per l'automazione che mantiene i progetti in movimento all'interno e tra i flussi di lavoro, e per il feedback e la misurazione che permettono ai team di accelerare continuamente i cicli e migliorare la qualità e le prestazioni del software.


Strumenti DevOps: creazione di una toolchain DevOps

Le esigenze di DevOps e della cultura DevOps attribuiscono un valore fondamentale a una strumentazione che supporti la collaborazione asincrona, integri senza soluzione di continuità i flussi di lavoro DevOps e automatizzi il più possibile l'intero ciclo di vita di DevOps. Le categorie di strumenti DevOps includono:

  • Strumenti di gestione dei progetti: gli strumenti che consentono ai team di creare un backlog delle storie degli utenti (requisiti) che formano dei progetti di codifica, suddividerli in attività più piccole e tracciare le attività fino al loro completamento. Molti supportano delle prassi di gestione dei processi agili, come Scrum, Lean e Kanban, che gli sviluppatori portano a DevOps. Le opzioni open source di uso comune includono GitHub Issues e Jira.
  • Archivi collaborativi del codice di origine: ambienti di codifica controllati dalle versioni che consentono a più sviluppatori di lavorare sulla stessa base di codice. I repository di codice devono integrarsi con CI/CD, test e strumenti di sicurezza in modo tale che, quando ne viene eseguito il commit con il repository, il codice possa passare automaticamente alla fase successiva. I repository di codice open source includono GiHub e GitLab.
  • Pipeline CI/CD: strumenti che automatizzano l'estrazione (check-out), la creazione, il test e l'implementazione di codice. Jenkins è lo strumento open source più diffuso in questa categoria; molte alternative che un tempo erano open source, come CircleCI, sono ora disponibili solo nelle versioni commerciali. Nell'ambito degli strumenti di implementazione continua (CD), Spinnaker si colloca tra i livelli di applicazione e IaC (infrastructure-as-code). ArgoCD è un'altra scelta open source comune per il CI/CD nativo di Kubernetes.
  • Framework di automazione dei test: includono strumenti software, librerie e best practice per l'automazione di unit test, penetration test e test dei contratti, delle prestazioni, dell'usabilità, e della sicurezza. I migliori tra questi strumenti supportano più lingue; alcuni usano l'IA per riconfigurare automaticamente i test in risposta alle modifiche del codice. Gli strumenti e i framework di test sono veramente tantissimi. Dei framework di automazione dei test open source ampiamente diffusi includono Selenium, Appium, Katalon, Robot Framework e Serenity (precedentemente noto come Thucydides).
  • Strumenti di gestione della configurazione (infrastruttura come codice: questi strumenti consentono agli ingegneri DevOps di configurare ed eseguire il provisioning di un'infrastruttura con un controllo delle versioni completo e pienamente documentata eseguendo uno script. Le opzioni open source includono Ansible (Red Hat), Chef, Puppet e Terraform. Kubernetes esegue la stessa funzione per le applicazioni containerizzate (vedi 'DevOps e sviluppo nativo del cloud' qui di seguito).
  • Strumenti di monitoraggio: aiutano i team DevOps a identificare e risolvere i problemi di sistema; inoltre raccolgono e analizzano i dati in tempo reale per rivelare in che modo le modifiche del codice si ripercuotono sulle prestazioni delle applicazioni. Gli strumenti di monitoraggio open source includono Datadog, Nagios, Prometheus e Splunk.
  • Strumenti di feedback continuo: strumenti che raccolgono il feedback dagli utenti, servendosi della tecnica delle mappe termiche (la registrazione delle azioni a schermo degli utenti), di sondaggi o della creazione self-service di ticket per i problemi.

DevOps e sviluppo nativo del cloud
Quello

nativo del cloud è un approccio per creare applicazioni che sfruttano le tecnologie fondamentali del cloud computing. L'obiettivo dell'approccio nativo del cloud è quello di consentire uno sviluppo, un'implementazione, una gestione e delle prestazioni delle applicazioni ottimali negli ambienti pubblici, privati e multicloud. 

Attualmente, le applicazioni native del cloud sono generalmente

  • Create utilizzando microservizi: componenti ad accoppiamento lasco implementabili indipendentemente che hanno un loro stack autonomo e che comunicano tra loro tramite API REST; streaming di eventi o broker di messaggi.
  • Distribuite in contenitori: unità eseguibili di codice che contengono tutto il codice, i runtime e le dipendenze del sistema operativo necessarie per eseguire l'applicazione. (Per la maggior parte delle organizzazioni, "contenitore" è sinonimo di contenitore Docker,  ma esistono altri tipi di contenitore.)
  • Gestite (su vasta scala) utilizzando Kubernetes, una piattaforma di orchestrazione dei contenitori open-source per pianificare e automatizzare l'implementazione, la gestione e la scalabilità delle applicazioni containerizzate.

In molti modi, lo sviluppo nativo del cloud e DevOps sono fatti l'uno per l'altro. 

Ad esempio, lo sviluppo e l'aggiornamento di microservizi, cioè la distribuzione iterativa di piccole unità di codice in una piccola base di codice, si adatta perfettamente ai cicli di rilascio e gestione rapidi di DevOps. E sarebbe difficile occuparsi della complessità dell'architettura dei microservizi senza l'implementazione e la gestione di DevOps. Un recente sondaggio IBM tra sviluppatori e dirigenti IT ha rilevato che il 78% degli attuali utenti di microservizi prevede di aumentare il tempo, il denaro e lo sforzo investiti nell'architettura e il 56% dei non utenti è probabile che adotti i microservizi entro i prossimi due anni. 

Impacchettando e correggendo in modo permanente tutte le dipendenze del sistema operativo, i contenitori consentono dei rapidi cicli di CI/CD e implementazione perché tutta l'integrazione, tutti i test e tutta l'implementazione si verifica nello stesso ambiente. L'orchestrazione di Kubernetes, inoltre, esegue le stesse attività di configurazione continua per le applicazioni containerizzate che vengono eseguite da Ansible, Puppet e Chef per le applicazioni non containerizzate.

La maggior parte dei principali fornitori di cloud computing, tra cui AWS, Google, Microsoft Azure e IBM Cloud, offrono una sorta di soluzione di pipeline DevOps gestita.


Cos'è DevSecOps?

DevSecOps è DevOps che integra e automatizza continuamente la sicurezza in tutto il ciclo di vita di DevOps, dall'inizio alla fine, dalla pianificazione attraverso il feedback e di nuovo verso la pianificazione.

Per dirla in altro modo, DevSecOps è quello che DevOps doveva essere fin dall'inizio. Due però delle prime sfide significative (e all'epoca insormontabili) dell'adozione di DevOps erano l'integrazione della competenza nel campo della sicurezza in team interfunzionali (un problema culturale) e l'implementazione dell'automazione della sicurezza nel ciclo di vita di DevOps (un problema tecnico). La sicurezza arrivò a essere percepita come "il team dei no" e come un costoso collo di bottiglia in molte prassi di DevOps.

DevSecOps è nato come uno sforzo specifico per integrare e automatizzare la sicurezza come originariamente previsto. In DevSecOps, la sicurezza è un cittadino e una parte interessata "di prima classe" insieme allo sviluppo e alle operazioni, e porta la sicurezza nel processo di sviluppo con un focus sul prodotto.

Guarda "Cos'è DevSecOps?" per ulteriori informazioni su principi, vantaggi e casi d'uso

di DevSecOps:

DevOps e SRE (site reliability engineering)

L'ingegneria di affidabilità del sito (SRE) utilizza tecniche di ingegneria del software per automatizzare le attività delle operazioni IT, ad esempio la gestione del sistema di produzione, la gestione dei cambiamenti, la risposta agli incidenti e persino la risposta alle emergenze, che altrimenti potrebbero essere eseguiti manualmente dagli amministratori di sistema. SRE cerca di trasformare il classico amministratore di sistema in un ingegnere.

L'obiettivo finale di SRE è simile a quello di DevOps, ma più specifico: SRE mira a bilanciare il desiderio di un'organizzazione di sviluppare rapidamente le applicazioni con la sua necessità di soddisfare i livelli di prestazioni e disponibilità specificati negli accordi di livello di servizio (SLA) con i clienti e gli utenti finali. 

Gli ingegneri dell'affidabilità del sito raggiungono questo equilibrio determinando un livello accettabile di rischio operativo causato dalle applicazioni, chiamato "budget di errore", e automatizzando le operazioni per soddisfare tale livello. 

In un team DevOps interfunzionale, SRE può fungere da ponte tra sviluppo e operazioni, fornendo le metriche e l'automazione di cui il team ha bisogno per eseguire il push delle modifiche del codice e delle nuove funzioni attraverso la pipeline DevOps il più rapidamente possibile, senza 'violare' i termini degli SLA delle organizzazioni. 

Scopri di più su SRE (site reliability engineering)

DevOps e IBM Cloud

DevOps richiede la collaborazione tra le parti interessate di business, sviluppo e operazioni per fornire ed eseguire rapidamente del software affidabile. Le organizzazioni che utilizzano strumenti e prassi DevOps mentre trasformano la loro cultura creano una solida base per la trasformazione digitale e per la  modernizzazione delle applicazioni  mentre cresce l'esigenza di automazione nelle operazioni di business e in quelle IT.

Un passo verso una maggiore automazione deve iniziare con piccoli progetti di successo e misurabili, che puoi quindi ridimensionare e ottimizzare per altri processi e in altre parti della tua organizzazione.

Lavorando con IBM, avrai accesso a funzionalità di automazione alimentate da IA, compresi dei flussi di lavoro predefiniti, per rendere ogni processo dei servizi IT più intelligente, consentendo ai team di concentrarsi sui problemi IT più importanti e di accelerare l'innovazione.

Passa alla fase successiva:

Inizia con un  account IBM Cloud oggi stesso.

IBM Cloud Pak for Watson AIOps utilizza il machine learning e l'NLU (natural language understanding) per correlare i dati strutturati e non strutturati nella tua toolchain delle operazioni in tempo reale per scoprire insight nascosti e contribuire a identificare le cause principali più rapidamente. Eliminando la necessità di più dashboard, Watson AIOps passa gli insight e i consigli direttamente nei flussi di lavoro del tuo team per accelerare la risoluzione degli incidenti.


Soluzioni correlate

Automazione intelligente

Dai flussi di lavoro di business alle operazioni IT, la nostra automazione con tecnologia AI può aiutarti. Scopri come si stanno trasformando le aziende leader.


Crea e modernizza le tue applicazioni

Crea, modernizza e gestisci le applicazioni in modo sicuro su qualsiasi cloud con fiducia.


Automazione con tecnologia AI

Dai flussi di lavoro di business alle operazioni IT, la nostra automazione con tecnologia AI può aiutarti.