Un percorso pratico per la maturità DevOps

Qualsiasi metodologia agile è inutile senza pratiche DevOps reali. La parola d’ordine è stata usata in modo improprio in molte organizzazioni. Se dici di aver maturato team agili e hai un ingegnere DevOps o un team DevOps, che probabilmente non stanno andando nella giusta direzione. DevOps è una cultura piuttosto che un nome o una designazione del team. Prendendo spunto da CMM (Capability Maturity Model) questo tentativo è quello di aiutare un’organizzazione a sapere dove si trova in un percorso DevOps e la via da seguire. Con un po ‘ di brainstorm tra team di sviluppo e Ops questo può essere ampliato e personalizzato in base alle esigenze dell’organizzazione.

Nessun numero è male in quanto aiuta un individuo o un’organizzazione a crescere.

Cliente felice

A differenza di CMM, questo non è un modello che è necessario dimostrare a qualsiasi organizzazione di certificazione. L’unico certificato che si ottiene è dai vostri clienti felici o partner commerciali. Si tratta di un modello di auto riflettere e e aiutare le imprese a crescere. Lo scopo stesso di qualsiasi team IT è quello di creare valore facendo una consegna sostenibile e prevedibile con qualità.

Questo è un modello semplice che da Sviluppatore a CxO può comprendere e relazionarsi.

Prima di discutere sul modello. Dobbiamo capire la necessità di questo modello. Molti anni fa, Melvin Conway nel suo articolo ” Come inventano i comitati?”si avvicinò con tesi che divenne famoso come legge di Conway.

Qualsiasi organizzazione che progetta un sistema (definito in senso lato) produrrà un progetto la cui struttura è una copia della struttura di comunicazione dell’organizzazione.

La legge si basa sul ragionamento che affinché i moduli software funzionino, più persone devono comunicare frequentemente tra loro. Pertanto, la struttura dell’interfaccia software di un sistema rifletterà i confini sociali delle organizzazioni che lo hanno prodotto, attraverso i quali la comunicazione è più difficile.

Diamo un’occhiata a come funziona nello sviluppo del software con uno scenario reale. Radha sta costruendo una schermata di front-end che mostra gli attributi dettagliati di un prodotto. Dire che questo prodotto è un telefono cellulare. Pochi dettagli comuni del prodotto sono colore, prezzo, dimensioni, valutazioni ecc. Un nuovo regolamento è venuto a visualizzare il valore SAR del portatile. Lo schermo che ha progettato funziona con micro service call. Ha parlato con Sunil che lavora nel team di dati. Ha detto che possono inviare dati solo in file flat. C’è una chiara disconnessione tra due moduli. Questo è uno scenario che ogni team IT incontra se non tutte le volte 100% ma la maggior parte delle volte. Questo è solo un problema di progettazione. Il problema è più ampio. Cosa succede se le priorità dell’altra squadra sono molto diverse da ciò che sta facendo la tua squadra? Le vostre esigenze possono essere la priorità più bassa per loro, mentre le parti interessate sono in esecuzione dietro di voi.

Il primo passo per l’implementazione DevOps di successo deve essere aperto con le modifiche all’organizzazione.

Organizzazione cambia

Fammi discutere 5 livelli di maturità:

  1. Iniziale: in questa fase, i team lavorano in silos e c’è solo una collaborazione basata sulla necessità. In un incontro con tutte le squadre insieme, se chiedi chi possiede il “Prodotto” non avrai alcuna mano alzata. Il time to market è in genere più lungo, andando a mesi e talvolta anni. Le priorità sono stabilite a livello di team ma non a livello di prodotto. Ciò porterà ogni squadra ad avere le proprie priorità. Poiché non esiste un processo definito, ogni tentativo è come reinventare la ruota. Ciò porterà a problemi di qualità e scadenze più lunghe. Il team esegue principalmente implementazioni manuali e interventi manuali. Bene.. questo non è un cattivo stato. Questo è come la maggior parte dello sviluppo sarebbe iniziato.

2. Ripetibile: i team lavorano ancora nei silos. C’è un certo livello di automazione all’interno del team. Quando una crisi colpisce, squadra definisce il proprio processo e segue fino alla fine della crisi. Solo una buona notizia è che alcuni di questi possono diventare processi ripetibili quando la crisi colpisce di nuovo.

3. Definito: Questo è un buon punto di partenza per seminare la cultura DevOps con un team centralizzato. Questo team comprende le varie tecnologie che i team di sviluppo stanno utilizzando e gli utensili si basano sulle esigenze attuali. Essendo un team centralizzato, non è facile monitorare ciò che ogni squadra sta facendo e quindi alcune decisioni sono lasciate ai team per sperimentare. Il team centrale in genere è composto da esperti e i team di sviluppo avranno alcune persone con conoscenze e conoscenze di base.

4. Gestito: poiché il team DevOps centrale comprende il panorama degli strumenti dell’organizzazione, vengono testati più ambienti e strumenti. Processi coerenti e ripetibili sono seguiti da più team. La catena di strumenti viene selezionata in base a casi d’uso piuttosto che a scelte personali. Gli strumenti di monitoraggio per tutti i processi vengono introdotti e utilizzati pesantemente dai team per prendere decisioni.

5. Ottimizzare:

Il successo di un buon leader è definito non avendo seguaci ma dalla capacità di creare grandi leader.

La fase finale della maturità DevOps consiste nel far scomparire il team DevOps. Questo potrebbe sembrare contro intuitivo. In questa fase, DevOps fa parte del team di sviluppo del prodotto piuttosto che un’entità separata. Utilizzo dell’infrastruttura come codice, contenitori, orchestrazione ecc. zero touch distribuzione è raggiunto. Ora, se si chiama tutti coloro che sta lavorando su un prodotto e chiedere chi possiede il prodotto, si avrà alcune mani sicure alzando senza alcuna esitazione. I dati degli strumenti di monitoraggio vengono utilizzati per selezionare un nuovo set di strumenti (tra cui infrastruttura, linguaggi di programmazione, tecniche). Le decisioni si basano sui dati piuttosto che sulle preferenze personali. Il team di prodotto è pronto a distribuire il codice in qualsiasi momento e giorno. Amano il “valore aziendale” e lo trattano come un animale domestico. Tutto il resto è trattato come bestiame.

Modello di maturità DevOps.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.