Stima della fase di implementazione di un feature flag
Come valutare l’implementazione di un feature flag: percentuali graduali, kill switch, metriche di controllo e la pulizia che nessuno programma mai. Un flag è un piccolo prodotto, non una semplice distribuzione.
La storia si limita a lanciare il segnale, tralasciando poi le operazioni di pulizia, le metriche e il dispositivo di spegnimento di emergenza.
Un feature flag non è un meccanismo di distribuzione; è un piccolo prodotto. Richiede un’impostazione predefinita, un percorso di override, una traccia di audit, un kill-switch e un piano di rimozione. La maggior parte di questi elementi non è presente nel ticket originale, che solitamente recita: «inseritelo in un flag». Quel ticket rappresenta il punto di controllo, non la funzionalità.
Il preventivo deve tenere conto delle fasi di implementazione (1% → 10% → 50% → 100%), dei parametri che determinano se aumentare o ridurre la copertura in ciascuna fase e del ticket di pulizia che rimuove il flag una volta che la funzionalità è diventata permanente. I team che non pianificano tale operazione di pulizia finiscono per rilasciare, nel giro di un anno, un codice pieno di flag obsoleti — il che costituisce di per sé un debito operativo.
Ciò che viene detto nella stanza
Backend: “Incorporare la chiamata in un flag — poche righe.”
SRE: “Quale parametro ci indica che l’implementazione sta procedendo male?”
PM: «Per quali coorti verrà attivato per prime il flag?»
Titolo: “Chi rimuove la bandiera una volta raggiunto il 100%, e quando?”
Backend: “Esiste un kill switch indipendente dal flag?”
Domande che vale la pena porsi prima di votare
- Modalità di implementazione: rampa lineare, basata su coorti o passaggio netto?
- Valore predefinito nel caso in cui il servizio “flag” sia inattivo — comportamento precedente o nuovo?
- Indicatori che determinano il superamento di ciascuna fase: cosa si intende per “andare bene”?
- Il percorso del kill-switch è indipendente dal sistema dei flag?
- Biglietto di rimozione: da creare subito o “lo faremo più tardi”?
- Registro di controllo: chi ha modificato l’indicatore, quando e perché?
La soluzione è la stessa applicabile alla maggior parte delle storie relative al rollout: split suddividere l’implementazione, il rollout graduale e la pulizia in storie separate, e creare il ticket di rimozione prima di dimenticarsi della sua esistenza.
Un flag è un prodotto di piccole dimensioni. Si valuti la fase di avvio, i parametri di gating e la fase di pulizia — non solo la fase di chiusura.
Si veda Stima dell’implementazione graduale di un limite di velocità per lo stesso modello in cui l’implementazione graduale assorbe il carico di lavoro, nonché gli altri esempi di stime già realizzati. Avviare una sessione gratuita di Planning Poker una volta definite le fasi.