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.

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.

È 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.

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.

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.

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