Come Microsoft offre software con DevOps

Microsoft ha decenni di esperienza nella fornitura di servizi altamente scalabili agli ambienti di produzione. Man mano che servizi Microsoft e gli ambienti sono stati ampliati, anche le procedure di distribuzione si sono sviluppate nel corso del tempo. Molti clienti Microsoft hanno adottato e traggono vantaggio da queste procedure di recapito efficienti. I principi e i processi DevOps di base seguenti possono essere applicati a qualsiasi attività di distribuzione software moderna.

Per implementare i processi di distribuzione devOps, Microsoft ha adottato le iniziative seguenti:

• Concentrarsi sulla mentalità organizzativa e sulla cadenza sul recapito.
• Formare team autonomi, responsabili che possiedono, testano e offrono funzionalità.
• Passare a destra per testare e monitorare i sistemi nell'ambiente di produzione.

Concentrarsi sulla consegna

La spedizione più veloce è un vantaggio ovvio che le organizzazioni e i team possono facilmente misurare e apprezzare. La frequenza tipica di DevOps prevede brevi cicli sprint con distribuzioni regolari nell'ambiente di produzione.

Temendo una mancanza di stabilità del prodotto con brevi sprint, alcuni team avevano compensato con periodi di stabilizzazione alla fine dei loro cicli sprint. I tecnici volevano spedire il maggior numero possibile di funzionalità durante lo sprint, in modo da sostenere un debito di prova che dovevano pagare durante la stabilizzazione. I team che hanno gestito il debito durante lo sprint hanno quindi dovuto supportare i team che hanno costruito il debito. I costi aggiuntivi sono stati eseguiti tramite le pipeline di recapito e nell'ambiente di produzione.

La rimozione del periodo di stabilizzazione ha migliorato rapidamente il modo in cui i team hanno gestito il debito. Invece di spingere il lavoro di manutenzione chiave al periodo di stabilizzazione, i team che hanno costruito il debito hanno dovuto spendere il prossimo sprint recuperando fino ai loro obiettivi di debito. Team ha imparato rapidamente a gestire il debito di test durante gli sprint. Le funzionalità offrono quando sono comprovate e vale la pena il costo della distribuzione.

Automatizzare completamente le pipeline

La maggior parte dei team di miglioramento può ottenere immediatamente è automatizzare completamente le pipeline dal repository di codice all'ambiente di produzione. L'automazione include pipeline di versione con integrazione continua (CI), test automatizzati e recapito continuo (CD).

Teams potrebbe evitare la distribuzione perché è difficile, ma meno frequentemente distribuiscono, più difficile è. Più tempo tra le distribuzioni, più problemi si accumulano. Se il codice non è aggiornato, si verifica un debito di distribuzione.

È più facile lavorare in blocchi più piccoli distribuendo di frequente. Questa idea potrebbe sembrare ovvia nel senno, ma al momento può sembrare controintuitiva. Le distribuzioni frequenti motivano anche i team a classificare in ordine di priorità la creazione di pipeline e strumenti di distribuzione più efficienti e affidabili.

Usare gli strumenti interni

Microsoft usa il sistema di gestione delle versioni che compila e lo invia ai clienti. Un singolo investimento migliora sia la produttività del team che i prodotti Microsoft. L'uso di un sistema secondario avrebbe disattivato lo sviluppo e la velocità di distribuzione.

Autonomia e responsabilità del team

Nessun indicatore di avanzamento chiave specifico (KPI) misura la produttività o le prestazioni del team o se una funzionalità è in pista. I team devono essere in grado di gestire i propri piani e backlog, trovando un modo per allinearsi agli obiettivi dell'organizzazione.

È importante comunicare direttamente con i team per tenere traccia dello stato di avanzamento. Gli strumenti devono facilitare la comunicazione, ma la conversazione è il modo più trasparente per comunicare.

Assegnare priorità alle funzionalità

Un obiettivo importante è concentrarsi sulla distribuzione delle funzionalità. Le pianificazioni possono valutare quanto team e singoli utenti possono ragionevolmente completare in un determinato periodo di tempo, ma alcune funzionalità verranno fornite in precedenza e alcune verranno fornite in un secondo momento. Teams può classificare in ordine di priorità il lavoro in modo che le funzionalità più importanti lo rendano di produzione.

Usare microservizi

I microservizi offrono diversi vantaggi tecnici che migliorano e semplificano il recapito. I microservizi forniscono anche limiti naturali per la proprietà del team. Quando un team ha autonomia rispetto agli investimenti in un microservizio, può definire le priorità su come implementare le funzionalità e gestire il debito. Teams può concentrarsi sui piani per fattori come il controllo delle versioni, indipendentemente dai servizi complessivi che dipendono dal microservizio.

Lavorare in main

Ingegneri usati per lavorare in rami separati. Il debito di merge in ogni ramo è cresciuto fino a quando il tecnico ha cercato di integrare il ramo nel ramo principale. Più team e tecnici c'erano, più grande è stata l'integrazione.

Per consentire l'integrazione in modo più rapido, più continuo e in blocchi più piccoli, i tecnici lavorano ora nel ramo principale. Uno dei motivi principali per il passaggio a Git è rappresentato dalle offerte Git lightweight branching. Il vantaggio dell'ingegneria interna è stato eliminare la gerarchia profonda dei rami e i relativi sprechi. Tutto il tempo impiegato per l'integrazione viene ora versato nel recapito.

Usare i flag di funzionalità

Alcune funzionalità non vengono completate completamente per una distribuzione sprint, ma possono comunque trarre vantaggio dai test nell'ambiente di produzione. Teams può unire e distribuire questo codice con flag di funzionalità per attivare la funzionalità per utenti specifici, ad esempio il team di sviluppo o un piccolo segmento di early adopter. I flag di funzionalità controllano l'esposizione senza rischiare problemi con la base utente complessiva e possono aiutare i team a determinare se e come completare la funzionalità.

Test in produzione

Il passaggio da destra al test nell'ambiente di produzione consente di garantire che i test di pre-produzione siano validi e che gli ambienti di produzione in continua evoluzione siano pronti per gestire le distribuzioni.

Instrumentare test e metriche

Indipendentemente dalla posizione in cui viene distribuita un'app, è importante instrumentare tutto. La strumentazione non solo consente di identificare e risolvere i problemi, ma può fornire ricerche preziose sull'utilizzo e su cosa aggiungere successivamente.

Testare i modelli di resilienza

Un rischio per le distribuzioni complesse è costituito da errori a catena, in cui un errore di un componente causa un errore dei componenti dipendenti e così via fino a quando l'intero sistema non si interrompe. È importante comprendere dove si trovano singoli punti di errore (SPOFs) e come vengono mitigati e testare i processi di mitigazione, in particolare nell'ambiente di produzione.

Scegliere le metriche corrette

La progettazione delle metriche può essere difficile. Un errore comune consiste nell'includere troppe metriche, per evitare di mancare nulla. Ciò può tuttavia comportare l'esclusione o la mancata attendibilità del valore delle metriche che non soddisfano esigenze specifiche. Al contrario, i team Microsoft impiegano tempo per determinare i dati necessari per misurare il successo. Teams potrebbe aggiungere o modificare le metriche, ma comprendere lo scopo fin dall'inizio facilita tale processo.

Oltre alla base di una metrica, i team considerano ciò che hanno bisogno della metrica da misurare. Ad esempio, la velocità o l'accelerazione dei guadagni utente potrebbero essere una metrica più utile rispetto al numero totale di utenti. Le metriche variano da progetto a progetto, ma le più utili sono quelle con il potenziale per prendere decisioni aziendali.

Usare le metriche per guidare il lavoro

Microsoft include metriche con revisioni ai livelli di leadership più elevati. Ogni sei settimane, le organizzazioni presentano come funzionano su integrità, business, scenari e dati di telemetria dei clienti. Le organizzazioni illustrano le metriche con i dirigenti e con i team.

Teams in tutta l'organizzazione esamina le metriche utente coinvolte per determinare il significato delle funzionalità. I team non si limitano a distribuire le funzionalità, ma cercano di verificare se e come le persone le usano. I team usano queste metriche per regolare i backlog e determinare se le funzionalità necessitano di più lavoro per soddisfare gli obiettivi.

Linee guida per il recapito

• Non è mai una linea retta per arrivare da A a B, né è B la fine.
• Ci saranno sempre rimonti e errori.
• Visualizzare i setback come opportunità di apprendimento per modificare le tattiche per completare una determinata parte del processo.
• Nel corso del tempo, ogni team evolve le proprie procedure DevOps basandosi sull'esperienza e adattandosi alle esigenze mutevoli.
• La chiave è concentrarsi sulla distribuzione del valore, sia agli utenti finali che al processo di recapito stesso.