Cultura DevOps che cambia la vita alle aziende, potenziando le risorse e aggiungendo valore all’organizzazione. L’obiettivo? Promuovere lo sviluppo e la consegna del software in modalità continua progettando applicazioni composite basate su microservizi che spesso condividono funzionalità e automazione, semplificando il flusso dei processi IT. Il problema è che, nel momento in cui il personale IT scrive il codice dell’applicazione e programma automazioni ad hoc, le organizzazioni rischiano di perdersi le conoscenze specifiche dei singoli membri del team.
Cultura DevOps significa includere l’azienda nelle discussioni
Un ambiente che incoraggia la collaborazione intraziendale dovrebbe essere capace di fornire un modello di supporto end-to-end. La cultura DevOps, infatti, per sua stessa definizione (Dev + Ops) deve includere il lato aziendale, non solo i team IT. Per garantire che l’azienda sia coinvolta, è fondamentale applicare il paradigma di sviluppo Agile basato su Scrum, un framework per la gestione dei progetti che enfatizza il lavoro di squadra, la responsabilità e il progresso iterativo verso un obiettivo ben definito.
È nelle riunioni Scrum, infatti, che il personale IT informa i rappresentanti aziendali, offrendo loro l’opportunità di fornire tutti gli input utili a ottimizzare lo sviluppo e i suoi risultati. Un team Scrum efficace include non solo gli sviluppatori, ma anche i portatori di interesse operativi lato business dell’organizzazione.
Allineare i modi e i tempi del lavoro a beneficio di tutti
Il concetto di Daily Scrum, altrimenti chiamato stand-up, rischia di scoraggiare il personale aziendale, in particolare quando la discussione è altamente tecnica. La breve riunione quotidiana progettata per consentire al team di pianificare il proprio lavoro per la giornata e identificare eventuali ostacoli che potrebbero influire sul lavoro non è scontata per gli Ops.
È difficile che le altre linee di business aziendali coinvolte si adattino a queste riunioni flash al mattino che in 10 o 15 minuti espongono sinteticamente problemi e obiettivi. Per favorire la cultura DevOps è opportuno programmare le riunioni specificando ai membri coinvolti quando è necessario prendere decisioni aziendali, assicurandosi che la parte commerciale della discussione avvenga all’inizio della riunione. Questo permette a chi si occupa del business di liberarsi prima lasciando al team DevOps il resto del tempo per occuparsi degli aspetti più tecnici del lavoro.
L’importanza di continuare a condividere la conoscenza
Gli Scrum produttivi richiedono strumenti di reporting DevOps concisi ed efficaci. Questi strumenti sono fondamentali per sviluppare una buona cultura DevOsp, fornendo informazioni:
- sullo stato dello sviluppo del codice
- sulle implementazioni del codice operativo
- sugli effetti sugli obiettivi aziendali,
- su tutto ciò che accade nell’intera funzione DevOps
Piattaforme collaborative a supporto della cultura DevOps
Per facilitare la reportistica, gli esperti consigliano di adottare una piattaforma DevOps o un sistema di gestione come, ad esempio, quelli offerti da ServiceNow e Atlassian. Questi strumenti, favoriscono la Cultura DevOps nelle aziende, fornendo ai team un ecosistema di riferimento per condividere le conoscenze e lavorare insieme, indipendentemente da dove si trovino o dal loro ruolo nel processo DevOps.
Dopo aver scelto una piattaforma DevOps, è bene assicurarsi che i team DevOps possano tenere traccia del processo e condividere le conoscenze, acquisendo e salvando codice e funzionalità. L’idea di base è quella di creare un ambiente dove altri possano trovare ciò che è già stato creato, eliminando la necessità di reinventare la ruota per ogni funzionalità o regola di automazione.
Gestione e riutilizzo del codice
Gli ambienti di gestione del codice come GitHub e Bitbucket forniscono la gestione del codice sorgente e funzioni di libreria che possono essere inserite in altri strumenti DevOps basati sui processi. Fornitori come Atlassian e Terraform, insieme ai fornitori di servizi cloud AWS, Microsoft Azure e Google Cloud, offrono funzionalità per creare una directory che consenta il riutilizzo del codice.
Come ribadiscono gli esperti, dove è possibile è importante incentivare gli sviluppatori a rendere riutilizzabile il codice originale e riutilizzare il codice esistente per controbilanciare la tendenza a credere che il loro codice sarà migliore di quello di uno sviluppatore precedente. Promuovere una cultura DevOps significa infatti condividere quanto più possibile le conoscenze sul codice per evitare di duplicare gli sforzi pregressi, risparmiando tempo e denaro.
Gestire l’evolutiva dei Microservizi richiede massima cooperazione
Un trasferimento efficace delle conoscenze per le architetture di microservizi richiede una directory di servizio o una libreria funzionale. Una directory di microservizi consente agli sviluppatori di descrivere e archiviare formalmente il nuovo codice, inclusi i dettagli su come chiamare un servizio e i relativi risultati. Altri sviluppatori possono facilmente cercare nella directory per vedere se possono usare qualcosa che è già stato creato, piuttosto che scrivere una nuova funzione da zero.
Quando scelgono un microservizio per una nuova applicazione composita, gli sviluppatori devono essere consapevoli dell’impatto che le modifiche future possono avere sulle operazioni della propria app. I programmatori che lavorano su microservizi devono considerare che le dinamiche di programmazione potrebbero cambiare sostanzialmente nel tempo e, proprio per questo, devono indicarlo nella directory per evitare errori imprevisti.
Considerare anche script di automazione personalizzati
La maggior parte degli strumenti DevOps sul mercato offre notevoli capacità di automazione, ma a volte i team potrebbero aver bisogno di uno script di automazione più personalizzato. È fondamentale mettere a sistema anche questo tipo di script di automazione e, una volta dimostrata la loro solida replicabilità, renderli disponibili ad altri che desiderano svolgere la stessa attività o lo stesso processo. La stessa directory o funzione di libreria dovrebbe essere in grado di gestire sia il codice che gli script; avere due sistemi separati non aiuterà a creare un ambiente di condivisione delle conoscenze DevOps efficace.
Creare e rivedere regolarmente la documentazione
Per incrementare una cultura DevOps in azienda, la documentazione DevOps è una necessità, dal momento che è impossibile scoprire codice o script che non hanno descrizioni.
A un livello base, la documentazione per gli script di automazione e il codice dell’applicazione dovrebbe descrivere le funzioni di alto livello che eseguono. Dovrebbe inoltre includere tutti gli input richiesti, gli output forniti e gli standard utilizzati, come API RESTful o JSON. Fornire queste informazioni rende molto più probabile che tali articoli vengano riutilizzati. Un consiglio alle organizzazioni è di identificare un professionista assegnandogli il ruolo di bibliotecario che si occuperà di rivedere regolarmente la libreria della documentazione e identificare le ridondanze nelle funzioni o nelle capacità. Il bibliotecario avrà anche un ruolo interlocutorio, sollevando eventuali ridondanze con gli sviluppatori o gli amministratori coinvolti per decidere quale sia l’opzione migliore. In alcuni casi, potrebbero essere necessari entrambi, ma la riduzione del numero di elementi nella libreria andrà a vantaggio sia della funzione DevOps che dell’azienda.
L’importanza della Leggibilità della documentazione DevOps
La documentazione per l’utente finale deve essere leggibile e comprensibile anche da un utente finale, il che significa che non deve essere espressa in termini esclusivamente tecnici. Evitare anche di produrre volumi di copie cartacee rilegate o PDF online di sola lettura: una cultura DevOps è agile di nome e di fatto, il che significa che la documentazione deve essere disponibile dove è necessario, direttamente all’interno dell’applicazione, in un solo clic contestuale per gli utenti.
A questo proposito, la maggior parte degli strumenti DevOps che offrono un ambiente visivo, come Chef e Puppet, consentono approcci di trascinamento della selezione per progettare un modello di primo livello. Gli strumenti creano il flusso di dati e i modelli di entità insieme ai flussi funzionali e di processo. Gli strumenti di orchestrazione, come quelli di HashiCorp, BMC e Stonebranch, forniscono funzioni aggiuntive con capacità più approfondite per mappare le interfacce API.
Le piattaforme cloud, come AWS e Azure, tendono ad avere front-end che aiutano a creare e mantenere le basi necessarie per documentare un ambiente DevOps.
Automatizzare non esclude i controlli manuali
Una cultura DevOps sa come armonizzare persone e automazioni e, proprio per questo, non dipende esclusivamente dagli strumenti per fornire una documentazione solida. Gli amministratori IT devono controllare tutto manualmente. La documentazione automatizzata di base dovrebbe eliminare la necessità di creare da zero la documentazione, ma richiede la supervisione umana per garantire che la documentazione dell’utente, dell’amministratore e dell’help desk non portino a un “effetto domino” di problemi dovuti a un singolo progetto di automazione scadente in una fase iniziale.
La collaborazione tra i team DevOps presuppone strategie di engagement
L’automazione della documentazione DevOps è ancora a uno stato nascente, ma è una pietra miliare della cultura DevOps. Le organizzazioni IT devono assicurarsi di scegliere strumenti capaci di integrarsi tra loro. Le aziende devono cercare strumenti flessibili che consentano l’approccio più semplice con front-end visivi e modalità di acquisizione collaborativa, con una capacità di accesso decentralizzato da parte degli amministratori di sistema e del personale dell’help desk.
Ecco perché i sistemi di collaborazione, come GitHub, Slack o i sistemi di acquisizione della chat all’interno dei pacchetti DevOps sottostanti, e le funzionalità di gestione dei progetti dei pacchetti, come Jira di Atlassian sono strategici.
