Panoramica di DevOps

1. Panoramica

In questo articolo, comprenderemo le basi dei principi e delle pratiche DevOps. Vedremo perché questo è rilevante e utile nello sviluppo del software. Capiremo anche come possiamo adottare DevOps in modo significativo e quali strumenti sono disponibili per aiutarci in questo viaggio.

2. Contesto storico

Non saremo in grado di apprezzare DevOps così com'è oggi senza guardare un po 'indietro alla storia. I primi giorni di sviluppo del software sono stati per lo più caratterizzati da quella che chiamiamo metodologia a cascata. Ciò che questo significa effettivamente è che il software è stato concettualizzato, progettato, sviluppato, testato e distribuito in successione .

Ogni passaggio era il più dettagliato possibile, poiché tornare indietro era molto costoso . Ciò che questo significava effettivamente era un periodo di attesa molto più lungo tra il pensiero e l'azione. Tuttavia, questo non era un problema in quanto il panorama tecnologico era molto meno volatile e le interruzioni erano troppo diffuse.

È interessante notare che questo modello non è durato a lungo. Poiché il ritmo della tecnologia è cambiato e le interruzioni hanno iniziato a verificarsi spesso, le aziende hanno iniziato a sentire il calore. Avevano bisogno di nuove idee per essere testate più velocemente . Ciò significava cambiamenti più rapidi in tutti gli aspetti del business, incluso il software.

Ciò ha dato vita a un mondo completamente nuovo di metodologie di sviluppo software che sono vagamente viste sotto l'ombrello di Agile. Il manifesto agile stabilisce una serie di principi da seguire per la consegna del software in piccoli incrementi con un ciclo di feedback più veloce . Nella pratica esistono diversi framework agili come Scrum e Kanban.

3. Che cos'è DevOps ?

Abbiamo visto che lo sviluppo incrementale con feedback più rapido è diventato la pietra angolare della distribuzione del software oggi. Ma come lo otteniamo? Sebbene le metodologie agili tradizionali ci portino a un punto ragionevole, non è ancora l'ideale?

Le metodologie agili continuano a perfezionarsi mentre si sforzano continuamente di rompere i silos.

Tradizionalmente, abbiamo sempre avuto team diversi responsabili dello sviluppo e della distribuzione del software. Queste squadre spesso operavano nei loro silos. Ciò si è effettivamente tradotto in un ciclo di feedback molto più lungo, che non è qualcosa che desideriamo con metodologie agili.

Quindi, non è necessario ragionare molto per capire che i team agili ben integrati e interfunzionali sono molto più adatti a raggiungere i loro obiettivi. DevOps è la pratica che incoraggia la comunicazione, la collaborazione, l'integrazione e l'automazione tra lo sviluppo del software e i team operativi . Questo ci consente di realizzare uno sviluppo incrementale con feedback più rapidi.

Il diagramma seguente spiega un possibile flusso di lavoro per praticare DevOps:

Mentre esamineremo i dettagli di questi passaggi più avanti nel tutorial, comprendiamo alcuni dei principi chiave di DevOps:

  • Approccio incentrato sul valore (realizzato dall'utente finale)
  • Cultura collaborativa (con comunicazione, processi e strumenti efficaci)
  • Automazione dei processi (per migliorare l'efficienza e ridurre gli errori)
  • Risultati misurabili (da misurare rispetto agli obiettivi)
  • Feedback continuo (con la tendenza a migliorare rapidamente)

4. Come iniziare il viaggio?

Sebbene la teoria sia semplice e accattivante, le vere sfide risiedono nel praticare DevOps in modo significativo. Come abbiamo raccolto finora, DevOps riguarda principalmente le persone, piuttosto che i team .

Obiettivi comuni, comunicazione efficace e abilità interfunzionali sono i tratti distintivi di tali team. Poiché gran parte di questo cambiamento è culturale, spesso è lento e non privo di attriti.

4.1. Motivazione

Solo perché c'è una pratica popolare là fuori non necessariamente la rende adatta a noi. Dobbiamo capire la nostra motivazione per qualsiasi cambiamento, soprattutto se stiamo apportando un cambiamento verso l'agile. È utile partire definendo gli obiettivi che vogliamo raggiungere .

Gli obiettivi di DevOps in qualsiasi organizzazione dipendono dall'ambizione, dalla cultura e dalla maturità dell'organizzazione. Ecco alcuni degli obiettivi DevOps più comuni:

  • Migliore esperienza per gli utenti finali
  • Time to market più veloce
  • Tempo medio di recupero migliorato

4.2. Adozione

Ricorda che DevOps non è uno stato finale ma un processo continuo di miglioramento per raggiungere gli obiettivi. Quindi, tutti i membri del team devono sforzarsi di identificare gli ostacoli e rimuoverli rapidamente . Ecco alcune attività che possono aiutarci a iniziare:

  • Comprendere chiaramente lo stato attuale dell'ideazione del ciclo produttivo
  • Raccogli alcuni degli ovvi colli di bottiglia e utilizza le metriche per prendere decisioni concrete
  • Dai la priorità ai colli di bottiglia che aggiungeranno il maggior valore quando vengono rimossi
  • Definire un piano iterativo per fornire valore in modo incrementale agli articoli prioritari
  • Segui i brevi cicli di sviluppo-distribuzione-misura per raggiungere gli obiettivi

5. Pratiche DevOps

Ci sono diverse pratiche da seguire, ma l'idea non dovrebbe usarne nessuna come gold standard. Dobbiamo esaminare attentamente ogni pratica sullo sfondo del nostro stato e dei nostri obiettivi e quindi prendere decisioni informate. Tuttavia, quasi tutte le pratiche tendono a concentrarsi sull'automazione dei processi il più possibile.

5.1. Pianificazione agile

La pianificazione agile è la pratica di definire il lavoro in brevi incrementi. Sebbene l'obiettivo finale dovrebbe essere chiaro, non è necessario definire e dettagliare l'intera applicazione in anticipo. La chiave qui è dare la priorità al lavoro in base al valore che può offrire .

Quindi, dovrebbe essere interrotto in un'iterazione di incrementi brevi ma funzionanti.

5.2. Infrastructure-as-Code (IaC)

Questa è la pratica della gestione e del provisioning dell'infrastruttura tramite file di configurazione leggibili dalla macchina . Gestiamo anche queste configurazioni in un sistema di controllo delle versioni come gestiamo la nostra base di codice. Sono disponibili molte lingue specifiche del dominio per creare questi file di configurazione in modo dichiarativo.

5.3. Automazione del test

Il test del software è stato tradizionalmente uno sforzo manuale spesso condotto in silos. Questo non si sposa bene con i principi agili. Pertanto, è imperativo tentare di automatizzare i test del software a tutti i livelli, come i test di unità, i test funzionali, i test di sicurezza e i test delle prestazioni .

5.4. Integrazione continua (CI)

L'integrazione continua è la pratica di unire il codice funzionante più spesso in piccoli incrementi in un repository condiviso . Di solito, ci sono build automatiche e controlli che vengono eseguiti frequentemente su questo repository condiviso per avvisarci di eventuali interruzioni del codice il prima possibile.

5.5. Distribuzione / distribuzione continua (CD)

La consegna continua è la pratica di rilasciare il software in piccoli incrementi non appena supera tutti i controlli . Questo è spesso praticato insieme all'integrazione continua e può trarre vantaggio da un meccanismo di rilascio automatizzato (denominato distribuzione continua).

5.6. Monitoraggio continuo

Il monitoraggio, forse il centro di DevOps, consente cicli di feedback più rapidi. Identificare le metriche corrette per monitorare tutti gli aspetti del software, inclusa l'infrastruttura, è fondamentale . Avere le metriche giuste, insieme ad analisi efficaci e in tempo reale, può aiutare a identificare e risolvere i problemi più velocemente. Inoltre, alimenta direttamente la pianificazione agile.

Questo elenco è lungi dall'essere completo ed è in continua evoluzione. I team che praticano DevOps cercano continuamente modi migliori per raggiungere i propri obiettivi. Alcune delle altre pratiche degne di nota sono containerizzazione, sviluppo nativo del cloud e microservizi, solo per citarne alcuni.

6. Strumenti del mestiere

Nessuna discussione su DevOps può essere completa senza parlare degli strumenti. Questa è un'area in cui c'è stata un'esplosione negli ultimi anni. Potrebbe esserci un nuovo strumento là fuori quando finiremo di leggere questo tutorial! Sebbene sia allettante e opprimente allo stesso tempo, è necessario prestare attenzione.

Non dobbiamo iniziare il nostro viaggio DevOps con gli strumenti come prima cosa nella nostra mente. Dobbiamo esplorare e stabilire i nostri obiettivi, persone (cultura) e pratiche prima di trovare gli strumenti giusti . Essendo chiaro su questo, vediamo quali sono alcuni degli strumenti testati nel tempo a nostra disposizione.

6.1. Pianificazione

Come abbiamo visto, un DevOps maturo inizia sempre con una pianificazione agile. Sebbene siano chiari sugli obiettivi, è solo necessario dare priorità e definire il lavoro per poche brevi iterazioni. Il feedback di queste prime iterazioni è inestimabile per plasmare quelle future e alla fine l'intero software. Uno strumento efficace qui ci aiuterebbe a esercitare questo processo con facilità.

Jira è un prodotto di monitoraggio dei problemi di prim'ordine sviluppato da Atlassian. Ha molti strumenti integrati di pianificazione e monitoraggio agili. In gran parte, è un prodotto commerciale che possiamo eseguire in sede o utilizzare come applicazione ospitata.

6.2. Sviluppo

L'idea alla base di Agile è creare prototipi più velocemente e cercare feedback sul software reale. Gli sviluppatori devono apportare modifiche e unire più velocemente in una versione condivisa del software. È ancora più importante che la comunicazione tra i membri del team sia fluida e veloce.

Diamo un'occhiata ad alcuni degli strumenti onnipresenti in questo dominio.

Git è un sistema di controllo della versione distribuito. È abbastanza popolare e ci sono numerosi servizi ospitati che forniscono repository Git e funzioni a valore aggiunto. Sviluppato originariamente da Linus Torvalds, rende la collaborazione tra gli sviluppatori di software abbastanza conveniente.

Confluence è uno strumento di collaborazione sviluppato da Atlassian . La collaborazione è la chiave del successo per qualsiasi team agile. La semantica effettiva della collaborazione è piuttosto contestuale, ma uno strumento che renda uno sforzo continuo è comunque inestimabile. Confluence si adatta perfettamente a questo punto. Inoltre, si integra bene con Jira!

Slack è una piattaforma di messaggistica istantanea sviluppata da Slack Technologies. Come abbiamo discusso, i team agili dovrebbero essere in grado di collaborare e comunicare, preferibilmente in tempo reale . Oltre alla messaggistica istantanea, Slack offre molti modi per comunicare con un singolo utente o un gruppo di utenti e si integra bene con altri strumenti come Jira e GitHub!

6.3. Integrazione

Le modifiche unite dagli sviluppatori dovrebbero essere continuamente controllate per verificarne la conformità. Ciò che costituisce la conformità è specifico del team e dell'applicazione. Tuttavia, è comune vedere l'analisi del codice statica e dinamica, nonché le misurazioni metriche funzionali e non funzionali, come componenti della conformità.

Diamo un'occhiata brevemente ad un paio di popolari strumenti di integrazione.

Jenkins è un server di automazione avvincente, open source e gratuito. È nel settore da anni ed è maturato abbastanza da soddisfare un ampio spettro di casi d'uso dell'automazione. Offre un modo dichiarativo per definire una routine di automazione e una varietà di modi per attivarla automaticamente o manualmente. Inoltre, ha un ricco set di plugin che servono diverse funzionalità aggiuntive per creare potenti pipeline di automazione.

SonarQube è una piattaforma di ispezione continua open source sviluppata da SonarSource. SonarQube ha un ricco set di regole di analisi statica per molti linguaggi di programmazione. Questo aiuta a rilevare gli odori di codice il prima possibile. Inoltre, SonarQube offre una dashboard che può integrare altre metriche come la copertura del codice, la complessità del codice e molti altri. E funziona bene con Jenkins Server.

6.4. Consegna

Fornire rapidamente modifiche e nuove funzionalità al software è importante. Non appena abbiamo stabilito che le modifiche unite nel repository sono conformi ai nostri standard e politiche, dovremmo essere in grado di fornirle rapidamente agli utenti finali. Questo ci aiuta a raccogliere feedback e modellare meglio il software.

Ci sono diversi strumenti qui che possono aiutarci ad automatizzare alcuni aspetti della consegna fino al punto in cui otteniamo una distribuzione continua.

Docker è uno strumento prevalente per containerizzare rapidamente qualsiasi tipo di applicazione. Sfrutta la virtualizzazione a livello di sistema operativo per isolare il software in pacchetti chiamati contenitori. La containerizzazione ha un vantaggio immediato in termini di consegna del software più affidabile . I Docker Containers parlano tra loro attraverso canali ben definiti. Inoltre, questo è piuttosto leggero rispetto ad altri modi di isolamento come le macchine virtuali.

Chef / Puppet / Ansible sono strumenti di gestione della configurazione. Come sappiamo, un'istanza in esecuzione effettiva di un'applicazione software è una combinazione della build della base di codice e delle sue configurazioni. E mentre la build della base di codice è spesso immutabile in tutti gli ambienti, le configurazioni non lo sono. È qui che abbiamo bisogno di uno strumento di gestione della configurazione per distribuire la nostra applicazione con facilità e velocità . Ci sono diversi strumenti popolari in questo spazio, ognuno con le proprie peculiarità, ma Chef, Puppet e Ansible coprono praticamente le basi.

HashiCorp Terraform può aiutarci con il provisioning dell'infrastruttura , che è stato un compito noioso e dispendioso in termini di tempo sin dai tempi dei data center privati. Ma con una sempre maggiore adozione del cloud, l'infrastruttura è spesso vista come un costrutto usa e getta e ripetibile. Tuttavia, questo può essere ottenuto solo se disponiamo di uno strumento con il quale possiamo definire in modo dichiarativo infrastrutture da semplici a complesse e crearle con un clic di un pulsante . Può sembrare una sequenza da sogno, ma Terraform sta attivamente cercando di colmare questa lacuna!

6.5. Monitoraggio

Infine, essere in grado di osservare il dispiegamento e misurarlo rispetto agli obiettivi è essenziale. Ci può essere una serie di metriche che possiamo raccogliere da sistemi e applicazioni. Questi includono alcune delle metriche aziendali specifiche della nostra applicazione.

L'idea qui è quella di essere in grado di raccogliere, curare, archiviare e analizzare queste metriche quasi in tempo reale. Ci sono diversi nuovi prodotti, sia open source che commerciali, disponibili in questo spazio.

Elastic-Logstash-Kibana (ELK) è uno stack di tre progetti open source : Elasticsearch, Logstash e Kibana. Elasticsearch è un motore di ricerca e analisi altamente scalabile. Logstash ci fornisce una pipeline di elaborazione dati lato server in grado di consumare dati da un'ampia varietà di fonti. Infine, Kibana ci aiuta a visualizzare questi dati. Insieme, questo stack può essere utilizzato per aggregare dati come i registri di tutte le applicazioni e analizzarli in tempo reale .

Prometheus è uno strumento di monitoraggio e avviso di sistema open source originariamente sviluppato da SoundCloud. Viene fornito con un modello di dati multidimensionale, un linguaggio di query flessibile e può estrarre dati di serie temporali su HTTP. Grafana è un'altra soluzione di analisi e monitoraggio open source che funziona con diversi database. Insieme, Prometheus e Grafana possono fornirci un controllo in tempo reale su praticamente qualsiasi metrica che i nostri sistemi sono in grado di produrre .

7. Estensioni DevOps (o lo sono davvero!)

Abbiamo visto che DevOp, fondamentalmente, è uno sforzo continuo per rimuovere gli ostacoli verso una consegna più rapida e iterativa del software basata sul valore. Ora, una delle conclusioni immediate è che non può esserci uno stato finale qui.

Ciò che le persone hanno capito come attrito tra i team di sviluppo e operativi non è l'unico attrito. Rompere i silos all'interno di un'organizzazione per aumentare la collaborazione è l'idea centrale. Ora, le persone hanno presto iniziato a rendersi conto che esistono attriti simili tra i team di sviluppo e test e tra i team di sviluppo e sicurezza . Molte configurazioni tradizionali hanno team dedicati per la sicurezza e le prestazioni.

Il pieno potenziale di DevOps non potrà mai essere realizzato finché non saremo in grado di superare quasi tutti i confini tra i team e aiutarli a collaborare in modo molto più efficiente. Ciò significa intrinsecamente portare team come test, sicurezza e prestazioni nell'ovile .

La confusione è in gran parte nella sua nomenclatura. DevOps ci fa capire che si tratta principalmente di team di sviluppo e operativi. Quindi, nel tempo, sono emersi nuovi termini, che comprendono altre squadre. Ma in gran parte, è solo DevOps che viene realizzato in modo più efficace!

7.1. DevTestOps

La pietra angolare di DevOps è fornire software di alta qualità in piccoli incrementi e più spesso. Ci sono molti aspetti nell'enfasi sulla qualità qui. In un certo senso, spesso presumiamo che le pratiche DevOps che adottiamo ci aiuteranno a raggiungere questo obiettivo. Ed è anche vero che molte delle pratiche che abbiamo discusso in precedenza si concentrano sull'assicurazione di alta qualità in ogni momento.

Ma il test funzionale del software ha una portata molto più ampia. Molto spesso, tendiamo a mantenere i test di ordine superiore come i test end-to-end verso la fine della consegna del software. Ancora più importante, questa è spesso responsabilità di un team separato che si impegna nelle fasi finali del processo. È qui che le cose iniziano a deviare dai principi DevOps.

Quello che dovremmo fare piuttosto è integrare il test del software, a tutti i livelli, fin dall'inizio . Fin dalla fase di pianificazione, il test del software dovrebbe essere considerato un aspetto integrante della consegna. Inoltre, lo stesso team dovrebbe essere responsabile dello sviluppo e del test del software. Questo è ciò che la pratica di DevTestOps è ampiamente nota. Questo è spesso indicato anche come Test continuo e spostamento a sinistra.

7.2. DevSecOps

La sicurezza è parte integrante di qualsiasi sviluppo software e ha la sua parte di complessità. Questo spesso significa che abbiamo un team separato di specialisti della sicurezza con cui collaboriamo non appena siamo pronti a spedire il prodotto. Le vulnerabilità che identificano in questa fase possono essere costose da correggere. Anche in questo caso non risuona bene con i principi di DevOps.

A questo punto, dovremmo già avere la soluzione che dobbiamo applicare, e cioè dovremmo far emergere i problemi di sicurezza e il personale all'inizio del gioco . Dobbiamo motivare i team a pensare alla sicurezza in ogni fase. La sicurezza è senza dubbio un settore molto specializzato e quindi potrebbe essere necessario coinvolgere uno specialista all'interno del team. Ma l'idea qui è di considerare alcune delle migliori pratiche fin dall'inizio.

Man mano che procediamo, sono disponibili diversi strumenti in grado di automatizzare la scansione per la maggior parte delle vulnerabilità . Possiamo anche inserirlo nei nostri cicli di integrazione continua per ottenere un feedback rapido! Ora, non possiamo integrare tutto nell'integrazione continua poiché dobbiamo mantenerlo leggero, ma possono sempre esserci altre scansioni periodiche eseguite separatamente.

8. Conclusione

In questo articolo, abbiamo esaminato le basi dei principi, delle pratiche e degli strumenti DevOps disponibili per l'uso. Abbiamo compreso il contesto in cui DevOps è rilevante e le ragioni per cui può esserci utile. Abbiamo anche discusso brevemente da dove iniziare nel percorso di adozione di DevOps.

Inoltre, abbiamo accennato ad alcune delle pratiche e degli strumenti popolari che possiamo utilizzare in questo viaggio. Abbiamo anche compreso alcuni degli altri termini popolari intorno a DevOps come DevTestOps e DevSecOps.

Infine, dobbiamo capire che DevOps non è uno stato finale, ma piuttosto un viaggio che potrebbe non finire mai! Ma la parte divertente qui è il viaggio stesso. Nel frattempo, non dobbiamo mai perdere di vista i nostri obiettivi e dovremmo concentrarci sui principi chiave. È abbastanza facile innamorarsi dello splendore di uno strumento o termine popolare nel settore. Ma dobbiamo sempre ricordare che qualsiasi cosa è utile solo se ci aiuta a fornire valore al nostro pubblico in modo più efficiente.