Stima della fase di implementazione di un feature flag

La storia mette in campo la bandiera e trascura la 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 sovrascrittura, una traccia di controllo, 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 distribuire, 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à attivata per prima l’opzione?»

Titolo: “Chi rimuove la bandiera una volta raggiunto il 100%, e quando?”

Backend: “Esiste un kill switch indipendente dal flag?”

Domande da porsi prima di votare

• Modalità di implementazione: rampa lineare, basata su coorti o passaggio booleano?
• Valore predefinito nel caso in cui il servizio “flag” risulti 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 di flag?
• Biglietto di rimozione: da creare in anticipo 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: 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 prega di valutare la fase di avvio, i parametri di gating e la fase di pulizia, non solo la fase di chiusura.

Si veda la sezione dedicata alla stima dell’implementazione con limitazione della frequenza per lo stesso modello “rollout-eats-the-work”, nonché gli altri esempi di stima già elaborati. Si apra una sessione gratuita di planning poker una volta definite le fasi.