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 di operazioni 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 integrare nel ciclo di vita di sviluppo del software gli input di tutti i settori interessati all'applicazione, tra cui 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.

DevOps rappresenta lo stato attuale dell'evoluzione dei cicli di fornitura di software degli ultimi 20 e passa anni, da enormi release di codice a livello applicazione ogni tot 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 di software di disporre di nuove funzioni frequenti e innovative e di poter contare su prestazioni e disponibilità ininterrotte.

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. Tra queste metodologie, si distingue per importanza la CI/CD (continuous integration / continuous delivery), ossia l'integrazione continua e la fornitura continua. In CI/CD, porzioni più piccole di nuove 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 prassi di sviluppo agile hanno accelerato lo sviluppo e la distribuzione del software, tanto più hanno esposto le operazioni IT ancora separate in silos (come ad esempio provisioning del sistema, configurazione, test di accettazione, gestione, monitoraggio) come il successivo 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.

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 riducono 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 successiva 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 implementato in 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 la fornitura di funzioni a un ambiente di produzione è definita come "Giorno 1", le operazioni del "Giorno 2" hanno luogo quando le funzioni sono in esecuzione in produzione. 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 l'esecuzione delle funzioni non presenti alcun problema e che non ci siano interruzioni nel servizio, garantendo che la rete, lo storage, la piattaforma, il calcolo e il profilo di sicurezza siano tutti 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 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 fase di "test" separata che si verifica tra l'integrazione e l'implementazione. Tuttavia, DevOps è progredito al punto che specifici elementi di test possono verificarsi in fase di pianificazione (sviluppo basato sul comportamento), sviluppo (esecuzione di unit test, test dei contratti), integrazione (scansioni di codice statico, scansioni CVE, linting), implementazione (smoke test, test di penetrazione, test di configurazione), operazioni (chaos test, test della 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 "agiscono" sui flussi di lavoro della sicurezza dopo la fornitura o l'implementazione, 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 spostamento a sinistra (o shift-left) (che è più facile da comprendere se consulti 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.

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

A livello organizzativo, DevOps richiede comunicazione, collaborazione e responsabilità condivisa continue tra tutte le parti interessate all'implementazione del software, team di sviluppo del software e operazioni IT, ma anche team responsabili della sicurezza, della conformità, della governance, dei rischi e della linea di 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 abbattere 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 ad altri team o senza aspettare le loro approvazioni. Quando sono messe nel contesto di uno sviluppo agile, la responsabilità condivisa e la collaborazione sono la base di un focus sul prodotto condiviso che produce un risultato di valore.

A livello tecnico, DevOps richiede un impegno verso l'automazione che preservi la mobilità dei progetti all'interno e tra i flussi di lavoro, e verso il feedback e la misurazione che consentono ai team di accelerare continuamente i cicli e migliorare la qualità e le prestazioni del software.

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: 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. Delle opzioni open source di uso comune includono GitHub Issues e Jira.
  
  
• Repository collaborativi di codice sorgente: 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 del 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, test di penetrazione e test dei contratti, delle prestazioni, dell'usabilità e della sicurezza. I migliori tra questi strumenti supportano più linguaggi; alcuni usano l'AI per riconfigurare automaticamente i test in risposta alle modifiche del codice. Gli strumenti e i framework di test sono 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 (IaC, infrastructure-as-code): consentono agli ingegneri di DevOps di configurare ed eseguire il provisioning di un'infrastruttura con un controllo delle versioni e una documentazione completi 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" 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.

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.
  
  
• Implementate container - 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, "container" è sinonimo di container Docker, ma esistono altri tipi di container).
  
  
• Gestite (su larga scala) utilizzando Kubernetes, una piattaforma di orchestrazione dei container 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 di IBM sugli sviluppatori e i dirigenti del settore IT ha riscontrato che il 78% degli attuali utenti di microservizi prevede di aumentare l'investimento già fatto nell'architettura in termini di tempo, risorse economiche e sforzi e il 56% dei non utenti adotterà probabilmente i microservizi entro i prossimi due anni. 

Impacchettando e correggendo in modo permanente tutte le dipendenze del sistema operativo, i container 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, offre qualche tipo di soluzione di pipeline DevOps gestita.

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 alla 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 membro 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 "What is DevSecOps?" per saperne di più su principi, vantaggi e casi di utilizzo di DevSecOps:

L'ingegneria dell'affidabilità del sito (site reliability engineering, SRE) utilizza tecniche di ingegneria del software per automatizzare le attività delle operazioni IT - ad esempio la gestione del sistema di produzione, la gestione delle modifiche, la risposta agli incidenti e persino la risposta alle emergenze - che altrimenti verrebbero eseguite manualmente dagli amministratori di sistema. SRE mira a 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)