Lo sviluppo del software nel 2020 è un ambiente in rapido cambiamento. Sta diventando sempre più chiaro che se le nostre organizzazioni vogliono sopravvivere a questo periodo di incertezza politica ed economica, devono essere in grado di muoversi con velocità e adattabilità. Ma come si fa a controllare la sicurezza in velocità? Se il vostro obiettivo è quello di passare da un ciclo di consegna del software che è stato costruito con un sacco di guardrail e deploy poco frequenti, ad una metodologia più moderna che supporta la reattività attraverso rilasci frequenti per far fluire il valore ai vostri clienti nel modo più rapido e sicuro possibile, allora chi mettete a capo delle decisioni di change management conta, molto.

Tradizionalmente in molte organizzazioni, queste decisioni sono prese a livello centrale da un change manager che conduce riunioni periodiche di change advisory board (CAB). Il CAB stesso è un insieme di rappresentanti di varie funzioni all’interno e all’esterno dell’IT aziendale, incaricato di rivedere i cambiamenti proposti e di assistere il change manager nella valutazione, prioritizzazione e programmazione del cambiamento. Per progettazione, questo è un gruppo che non è direttamente coinvolto nella progettazione o nell’implementazione del cambiamento proposto, che è il motivo per cui il processo che conducono è conosciuto come una revisione “esterna”.

Ma, chi dovrebbe essere responsabile? Per supportare al meglio sia la velocità e la sicurezza che l’impatto aziendale, volete che i vostri team di sviluppo e i vostri clienti guidino il vostro processo decisionale. Da un punto di vista tecnico, i vostri sviluppatori hanno un’idea migliore di cosa c’è in un rilascio, se esistono interdipendenze e se è stato testato, rispetto a qualsiasi comitato consultivo di cambiamento. Dal punto di vista del business, è ora che ci rendiamo conto che il cliente è l’arbitro finale di ciò che funzionerà o non funzionerà, non qualche manager senior, e certamente non il vostro comitato consultivo dei cambiamenti.

Un Change Advisory Board può essere più lento, ma almeno è più sicuro, giusto?

Il Change Advisory Board (e molto di ciò che troverete in ITIL), potrebbe sembrare un modo ragionevole per ridurre il rischio e aggiungere rigore, specialmente in ambienti complessi e lenti. Se avete solo un’occasione ogni 30 o 90 giorni per cambiare la produzione, tenere le cose fuori dai rilasci con cancelli di qualità e approvazioni di gestione sembra un buon modo per gestire il rischio. Nessuno discuterebbe sul fatto che è un processo più lento (che può aggiungere settimane o mesi al tempo tra uno sviluppatore che scrive codice e il suo rilascio), ma è più sicuro, giusto?

In realtà, no. Non lo è.

Uno studio pluriennale su un’ampia varietà di industrie e ambienti ha scoperto che avere un CAB o un simile processo di “approvazione esterna” ha funzionato peggio che non avere alcun processo di approvazione. Ecco cosa ha detto l’autore principale Dr. Nicole Fosgren sui risultati:

Abbiamo trovato che le approvazioni esterne erano negativamente correlate con il tempo di esecuzione, la frequenza di distribuzione e il tempo di ripristino, e non avevano alcuna correlazione con il tasso di fallimento dei cambiamenti. In breve, l’approvazione da parte di un ente esterno (come un manager o un CAB) semplicemente non funziona per aumentare la stabilità dei sistemi di produzione, misurata dal tempo di ripristino del servizio e dal tasso di fallimento dei cambiamenti. Tuttavia, certamente rallenta le cose. In effetti, è peggio che non avere alcun processo di approvazione dei cambiamenti.

Cosa c’è di meglio di nessuna gestione dei cambiamenti?

La dottoressa Fosgren e il suo team non stanno effettivamente suggerendo di non avere alcun processo di approvazione, ma visto quanto male funzionano i CAB nel mondo reale, dovremmo ripensare a quale tipo di processo vi terrà effettivamente al sicuro.

Ecco un’altra citazione dallo studio Accelerate:

La nostra raccomandazione basata su questi risultati è di usare un processo leggero di approvazione delle modifiche basato sulla revisione tra pari, come la programmazione a coppie o la revisione del codice intrateam, combinato con una pipeline di distribuzione per rilevare e rifiutare le cattive modifiche. Questo processo può essere utilizzato per tutti i tipi di modifiche, comprese le modifiche al codice, all’infrastruttura e al database.

Peer Code Reviews Combined with What Now?

Quando ho letto quella raccomandazione nel marzo del 2018, non ho avuto problemi a visualizzare la prima metà: le peer code review e le demo settimanali del team erano già la norma in BlazeMeter. La seconda metà? Non così tanto! Eravamo una “moderna” app SaaS cloud-native, ma non avevo mai sentito parlare di “una pipeline di distribuzione rilevare e rifiutare le cattive modifiche”.

Per gestire il rischio durante i rilasci allora, usavamo una combinazione di distribuzioni blu/verde e rilasci canarini. La piattaforma si occupava di “spingere” ma non di “rilevare” o “rifiutare” – questo spettava ai nostri migliori e più brillanti SRE, che avrebbero controllato manualmente lo stato di decine di cose prima di raggiungere il 100% degli utenti. Leggere “rilevare e rifiutare i cattivi cambiamenti” portava solo all’immagine di una scatola nera su una lavagna bianca con l’etichetta “qui avviene la magia”. Flashback agli studi cinematografici al college, dove ho imparato cosa significava “deus ex machina”.

Rileva e rifiuta: Examples Are Out There If You Look

In due anni possono cambiare molte cose. Da quando mi sono unito a Split come CD Evangelist, ho visto Lukas Vermeer descrivere come la pipeline di distribuzione di Booking.com può rilevare e annullare un cattivo cambiamento in un solo secondo. Ho ascoltato Sonali Sheel di Walmart Labs spiegare come usano la loro piattaforma Expo per fermare un rollout a metà strada prima che faccia danni alle loro metriche chiave, qualcosa che chiamano Test to Launch.

La Split Feature Delivery Platform è stata creata da persone con visioni simili della moderna gestione del cambiamento basate su esperienze vissute a LinkedIn, Salesforce.com e Yahoo. I fondatori hanno ricevuto consigli da persone che avevano affrontato la complessità, la velocità e la scala di sistemi simili in Amazon e Microsoft.

Quando ho sentito parlare di Split e ho scoperto gli esempi che stavano commercializzando, ho colto la possibilità di unirmi a loro. Costruire una tale piattaforma in-house era qualcosa che solo pochi giganti avevano il tempo e le risorse per affrontare. Se lo stesso tipo di esposizione a grana fine e il rilevamento automatico dell’impatto fossero disponibili come SaaS, allora la consegna del software guidata dall’impatto potrebbe essere sbloccata per ogni team, non solo per le startup unicorno.

E’ incredibile, ma non funzionerà qui

Una cosa divertente è successa più e più volte mentre viaggiavo alle conferenze tecnologiche, facendo discorsi sui primi pionieri che avevano costruito queste piattaforme in casa. Il pubblico rispondeva prima con stupore e poi con rassegnazione. “È molto bello, ma noi non siamo Booking.com, LinkedIn o Facebook. Non possiamo farlo nel nostro ambiente”.

Nei miei sforzi per essere “vendor-neutral” evitando le specifiche dell’implementazione di Split, avevo praticamente ridisegnato quell’immagine sfocata di una scatola nera con la scritta “la magia accade qui”.

E se non fosse così difficile?

Se non avete mai visto una piattaforma che fornisce un controllo a grana fine dell’esposizione e un rigoroso meccanismo automatizzato per rilevare e respingere i cattivi cambiamenti nel vostro ambiente, non potete essere biasimati per pensare che sia fantascienza.

Si è scoperto che ci sono solo quattro problemi principali da risolvere qui:

1. Disaccoppia il deploy dal rilascio, così il codice può essere spinto fino alla produzione ma non può essere eseguito finché non è pronto. Questo facilita la vera integrazione continua, le piccole dimensioni dei lotti, lo sviluppo di funzionalità incrementali e la ramificazione per astrazione, che sono tutti elementi critici per tirare fuori la consegna continua dove il flusso è la norma.
2. Esporre selettivamente il nuovo codice, iniziando con un piccolo pubblico interno e lavorando verso l’esterno. Questo facilita i test in produzione, il dogfooding, i programmi di accesso anticipato e il raggruppamento delle modifiche per i clienti contrari al cambiamento.
3. Ingerire i dati sul comportamento del sistema e degli utenti e allinearli con i dati di esposizione che indicano chi è dentro e fuori da ogni coorte di utenti. L’obiettivo è quello di rendere il processo di attribuzione (allineare “Chi ha avuto cosa?”, con “Poi è successo questo”) automatico e continuo.
4. Confrontare i modelli di metriche tra quelli inclusi ed esclusi da ogni coorte per identificare (e opzionalmente avvisare) le differenze significative. Potreste aver visto questo modello prima nel contesto del “test A/B” che tipicamente traccia l’impatto dei cambiamenti su una metrica di conversione, ma qui stiamo parlando di tracciare ampiamente l’impatto di tutto il lavoro di ingegneria e di avere un controllo sempre vigile per gli impatti su tutte le metriche valutate dall’organizzazione, che l’impatto su quelle metriche sia previsto o meno.

Progressive Delivery: Una base facilmente stabilita

Distaccare la distribuzione dal rilascio e esporre selettivamente il nuovo codice stanno diventando noti come consegna progressiva, un termine coniato dall’analista di RedMonk James Governor. Diversi venditori commerciali di feature flag forniscono queste capacità fuori dalla scatola e il consenso sta emergendo che le feature flag si sono aggiunte alla lista degli strumenti per sviluppatori che hanno più senso comprare che costruire e mantenere in casa.

Le feature flag sono una base essenziale per ottenere il flusso, ma da sole non accelerano il rilevamento dell’impatto. La maggior parte delle implementazioni delle feature flag rendono più facile il flusso, ma non fanno nulla per indicare se tutto va bene o se si stanno raggiungendo risultati significativi.

Head’s Up: Data Scientists Don’t Scale

Indagare il comportamento del sistema e dell’utente e allinearlo automaticamente con le coorti esposte è raro tra tutti i sistemi in-house tranne i più sofisticati. La maggior parte dei team che tentano questa pratica stanno facendo un sacco di lavoro manuale e ad-hoc di data science. Poiché sono limitati dalle risorse umane piuttosto che dalla capacità di calcolo, sono costretti a scegliere quando e dove prestare attenzione.

Il carico cognitivo non è amico quando si punta al flusso, quindi il design di Split non richiede nemmeno ai team di scegliere quali eventi associare a ogni rollout di feature flag; tutti gli eventi ingeriti, una volta legati alle metriche organizzative, sono continuamente attribuiti alle coorti on e off di ogni rollout, senza alcun intervento. Split facilita anche il lavoro di identificazione e ingestione di dati di eventi attraverso integrazioni con Segment, Sentry, mParticle e Google Analytics.

Semper Fi per le pipeline di Continuous Delivery

Confrontare i modelli di metriche tra quelli inclusi e non inclusi in ogni coorte in modo rigoroso per determinare automaticamente le differenze significative è ancora più raro in natura dell’attribuzione. Questo è esattamente il problema che i moduli Monitor e Experimentation di Split risolvono. Monitor si concentra sull’identificazione e l’avviso degli impatti sulle metriche mentre un rollout è in corso (noto anche come “limitare il raggio di esplosione degli incidenti”), mentre la sperimentazione, come il test A/B, cerca di fornire una fonte continua di dati imparziali, non vincolati dalla disponibilità di un analista, per indicare se ogni caratteristica ha raggiunto un impatto desiderato o meno.

Meglio insieme: Peer Review, Progressive Delivery e Automated Sense-Making

Perché ci sforziamo per il flusso? Non si tratta di output. Si tratta di risultati. Ci sforziamo per il flusso in modo da poter iterare il ciclo di feedback di idea -> implementazione -> osservazione con meno attrito in meno tempo. Che lo chiamiate “sviluppo guidato dall’impatto” o “sviluppo guidato dal cliente”, questo approccio per muoversi più velocemente con una maggiore (e più veloce) consapevolezza dei risultati va ben oltre la “pipeline di implementazione per rilevare e rifiutare i cattivi cambiamenti” che il team DORA ci ha raccomandato di combinare con le pratiche di peer review. Sì, possiamo rilevare e rifiutare automaticamente le cattive modifiche, ma, cosa più importante, possiamo costruire un processo ripetibile per triangolare verso risultati di business significativi.

Impara di più su come raggiungere la gestione del cambiamento e il flusso, insieme, in Continuous Delivery

• Guarda un video di quattro minuti sulla definizione di Continuous Delivery per vedere perché le piccole dimensioni dei lotti sono fondamentali per raggiungere un flusso coerente.
• Prendi spunto da diversi team che spediscono in produzione quotidianamente nell’e-book di O’Reilly, Continuous Delivery in the Wild
• Guarda un video approfondito con Craig Sebenik (LinkedIn, Crunchbase, Matterport) sui benefici del passaggio allo sviluppo basato su trunk.

Cercando altri grandi contenuti sul raggiungimento di risultati significativi con feature delivery su scala? Segnalibri il blog di Split, ci controlli su YouTube, o ci segua su Twitter @splitsoftware.