Flag di funzionalità: tipologie, ciclo di vita e governance per i team

Flag di funzionalità: tipologie, ciclo di vita e governance per i team

I flag di funzionalità consentono di distribuire il codice in produzione senza renderlo visibile, attivarlo per pochi utenti e disattivarlo in pochi secondi se qualcosa si rompe, il tutto senza ridistribuire. Adottarli è la parte più semplice. Gestirli bene, con tipologie chiare, responsabili, date di scadenza e l'abitudine di eliminare ciò che non serve più, è ciò che distingue una rete di sicurezza da una seconda codebase non documentata.

Questo articolo considera i flag di funzionalità come una disciplina. Non è un confronto tra strategie di deployment. Per una panoramica più ampia delle release, consulta la nostra guida alla gestione delle release. Qui ci concentriamo su ciò che devi decidere prima di distribuire il primo flag e su ciò che devi imporre dopo il centesimo.

Punti chiave

• Un flag di funzionalità separa il deployment (il codice raggiunge la produzione) dalla release (gli utenti possono vederlo). Questa separazione rappresenta l'intero valore.
• Non tutti i flag sono uguali. I flag di release, sperimentazione, operativi e di autorizzazione hanno durate e responsabili diversi e devono essere gestiti in modo differente.
• Ogni flag deve avere un responsabile, uno scopo e un piano di rimozione già dal giorno della sua creazione. I flag obsoleti diventano debito tecnico e, nel peggiore dei casi, possono causare un'interruzione del servizio.
• Tratta le modifiche ai flag in produzione come modifiche al codice: controllo degli accessi, revisione, log di audit e monitoraggio.
• Il servizio di gestione dei flag è a sua volta una dipendenza. Progetta il sistema pensando al giorno in cui non sarà disponibile.

Indice

• Cosa fanno i flag di funzionalità e cosa non fanno
• Quattro tipologie di toggle di funzionalità, quattro durate
• Il ciclo di vita di un flag, dalla creazione all'eliminazione
• Governance: chi può modificare cosa in produzione
• Strategie di rollout e rollout percentuale
• Dove si verificano i problemi con i flag di funzionalità
• Scegliere gli strumenti per la gestione dei flag di funzionalità
• Come aiutiamo con i programmi di gestione dei flag di funzionalità
• I flag di funzionalità sono una disciplina, non un interruttore
• Domande frequenti
• Fonti

Cosa fanno i flag di funzionalità e cosa non fanno

Un flag di funzionalità, chiamato anche toggle di funzionalità, è una logica condizionale valutata a runtime che decide se un blocco di codice deve essere eseguito per un determinato utente. Il suo stato può essere modificato tramite una configurazione esterna, senza modificare e ridistribuire l'applicazione.

Questo consente una separazione netta. Il deployment inserisce il codice in produzione. La release rende la funzionalità disponibile agli utenti. Con i flag, i team possono inserire il codice in produzione limitandone la disponibilità, quindi attivarlo per utenti selezionati senza riavviare il sistema né effettuare un nuovo deployment. I team usano questa separazione per lo sviluppo trunk-based, i rollout graduali, gli esperimenti, l'accesso premium e il controllo operativo.

Lo sviluppo trunk-based merita una frase. Poiché il lavoro non ancora completato può essere integrato dietro un flag disattivato, i branch rimangono brevi e diminuiscono i problemi di integrazione. Il prezzo da pagare è che ora il branch principale contiene percorsi di codice non attivi e qualcuno deve tenerne conto.

Cosa non sono i flag: configurazione. La configurazione statica dell'applicazione è generalmente longeva e viene caricata all'avvio, mentre i flag sono dinamici, di breve durata e vengono aggiornati a runtime. Confondere le due cose è il modo in cui una stringa di connessione al database finisce in una dashboard dei toggle che trenta persone possono modificare.

Come viene valutato effettivamente un flag? Un SDK nella tua applicazione recupera le regole, le valuta rispetto all’utente e al contesto e applica il risultato. Un esempio documentato: un SDK server memorizza nella cache la configurazione e verifica la disponibilità di aggiornamenti ogni 60 secondi, con valutazioni generalmente inferiori al millisecondo. Il recupero e la risoluzione sono passaggi distinti e gli SDK possono recuperare i dati all’avvio, in background o durante una sessione. Questo dettaglio è importante più avanti, quando parleremo delle modalità di errore.

Quattro tipi di feature toggle, quattro durate

La maggior parte dei problemi con i flag nasce quando un team tratta ogni toggle allo stesso modo. La tassonomia dei toggle ampiamente citata di Martin Fowler li distingue in base alla loro durata e al loro grado di dinamismo. Nella pratica, riteniamo utili quattro categorie operative:

Flag di rilascio

Sono i cavalli da lavoro. Esistono per consentire l’integrazione del codice incompleto e fare in modo che un lancio possa essere una decisione aziendale anziché un evento di deploy. Dovrebbero essere i flag con la durata più breve. Se un flag di rilascio è più vecchio della funzionalità stessa, qualcosa è andato storto.

Kill switch

Un kill switch è un controllo istantaneo on/off per tutti gli utenti, che consente di disabilitare in pochi secondi una funzionalità o una dipendenza che si comporta in modo anomalo, senza un nuovo deploy. Le linee guida DevOps di Microsoft osservano che un flag di spegnimento rapido può ripristinare un comportamento affidabile e controllare sia le modifiche architetturali o infrastrutturali sia le funzionalità dell’interfaccia utente.

I kill switch sono la legittima eccezione alla regola della breve durata. Fowler li descrive come toggle operativi di lunga durata che consentono agli operatori di degradare gradualmente le funzionalità non essenziali in condizioni di carico insolitamente elevato. Il suo punto sulla velocità è quello da ricordare: se per disattivare qualcosa è necessaria una nuova release, il toggle ha fallito il suo unico compito. Inserisci un kill switch attorno a ogni chiamata costosa a servizi di terze parti, a ogni nuova pipeline di dati e a ogni funzionalità che gestisce pagamenti o e-mail, quindi esercitati a utilizzarli.

Flag per esperimenti e autorizzazioni

Le flag per gli esperimenti restano attive esattamente per la durata del test. Stabilite la metrica e la data di fine prima di attivare la flag. Le flag per le autorizzazioni sono, in realtà, diritti di accesso del prodotto travestiti da flag. Se l’accesso dipende dal piano di un cliente, modellatelo come un diritto di accesso con test propri, non come un interruttore che qualcuno potrebbe eliminare durante la pulizia.

Il ciclo di vita di una flag, dalla creazione all’eliminazione

La documentazione di Atlassian descrive un tipico ciclo di vita composto da creazione, configurazione del targeting, valutazione a runtime e pulizia. La maggior parte dei team gestisce bene le prime tre fasi e salta la quarta. Un ciclo di vita praticabile prevede sei fasi:

1. Proposta. Registrate il nome, il tipo, il responsabile, lo scopo e la data prevista per la rimozione della flag. I nomi devono essere univoci e abbastanza descrittivi da permettere a una nuova persona del team di capire cosa fa la flag.
2. Sviluppo. Mantenete la valutazione della flag separata dalla logica di business, in modo che la decisione risieda in un unico livello sottile anziché essere distribuita tra le funzioni. Definite un valore predefinito sicuro per i casi in cui il servizio delle flag non possa rispondere.
3. Test. Eseguite entrambi i percorsi del codice. Una flag con un solo ramo testato è un bug in attesa del momento giusto per manifestarsi.
4. Rilascio graduale. Procedete secondo il modello di rilascio graduale scelto, monitorando i tassi di errore, la latenza e le metriche di business.
5. Stabilizzazione. Quando la funzionalità è al 100% e non presenta problemi, la flag ha svolto il suo compito.
6. Rimozione. Eliminate la flag, il percorso di codice non selezionato e i relativi test. Verificate quindi che nel codice non vi siano riferimenti alla flag.

Sono le fasi cinque e sei a richiedere disciplina. Le ricerche suggeriscono che il problema è reale e non solo teorico. Uno studio empirico del 2021 su 12 progetti open source Python e un sondaggio condotto su 61 professionisti hanno rilevato che il 75% dei componenti di tipo toggle è stato rimosso entro 49 settimane, il che significa anche che una quota significativa non è stata rimossa e che alcune flag di lunga durata non erano mai state concepite per restare attive. Sono queste flag superstiti ad aggiungere silenziosamente dei rischi.

Prevenire il debito delle flag

Il debito delle flag è l’accumulo di interruttori che non servono più a uno scopo, ma continuano a influenzare il comportamento del codice. Il modello di qualità arc42 annovera il debito dei toggle, gli stati di test obsoleti e le collisioni tra toggle interagenti tra le modalità di malfunzionamento dell’approccio. Alcune abitudini aiutano a tenerlo sotto controllo:

• Date di scadenza nel registro delle flag. Avvisate il responsabile quando una flag le supera e nuovamente quando è scaduta da troppo tempo.
• Un ticket di pulizia creato insieme alla flag. Non in un secondo momento. Quando il ticket del rilascio graduale viene chiuso, il ticket per la rimozione è già in attesa.
• Un limite al numero di flag di rilascio attive per team. Un numero visibile a tutti crea una sana pressione.
• Una revisione periodica del codice. Harness raccomanda avvisi per le flag obsolete e il controllo del codice alla ricerca delle flag ancora presenti, operazioni che un controllo CI può automatizzare.

Se il vostro team gestisce già un arretrato di codice morto, si applica lo stesso approccio di prioritizzazione. La nostra guida alla gestione del debito tecnico spiega come valutare e organizzare in sequenza questo lavoro.

Governance: chi può modificare cosa in produzione

Una modifica a una flag in produzione è una modifica alla produzione. Harness consiglia trattare la configurazione dei feature flag come codice di produzione, con controlli di revisione comparabili, una degradazione controllata tramite valori memorizzati nella cache o predefiniti e la compatibilità con le versioni precedenti. In pratica, per un responsabile tecnico, questo si traduce in:

• Accesso basato sui ruoli. Non tutti coloro che possono leggere i flag dovrebbero poterli attivare in produzione. LaunchDarkly indica controlli granulari degli accessi basati sui ruoli e registri di audit come funzionalità di sicurezza per modifiche controllate in produzione.
• Approvazioni per i flag ad alto rischio. Pagamenti, autenticazione ed eliminazione dei dati meritano un secondo paio d’occhi prima che un flag venga modificato.
• Registri di audit. Dovreste poter rispondere a chi ha modificato cosa e quando, senza dover chiedere in chat.
• Disciplina degli ambienti. La divergenza tra le configurazioni di staging e produzione è una modalità di errore documentata; confrontatele quindi secondo una pianificazione prestabilita, invece di limitarvi a sperare.
• Nomenclatura e responsabilità chiare. Un flag senza responsabile è un incidente futuro senza nessuno da chiamare.

La sicurezza fa parte della governance

I flag possono indebolire la sicurezza se non si presta attenzione. La guida ai test di OWASP avverte che stati incoerenti dei flag possono indebolire l’autenticazione, l’autorizzazione, il rilevamento delle frodi e la limitazione della frequenza tra i servizi, soprattutto durante un rilascio parziale, un rollback o un guasto del servizio dei flag. Avverte inoltre che i flag visibili al client non costituiscono confini di sicurezza. Applicate l’autorizzazione sul server, valutate i flag sensibili lato server e non fate mai affidamento su un pulsante nascosto come controllo. Se la vostra applicazione gestisce dati soggetti a normative, coinvolgete il responsabile della sicurezza prima che il primo flag interessi un percorso di accesso.

Strategie di rollout e rollout in percentuale

I flag rendono possibili diversi modelli di rollout e quello giusto dipende dalla vostra base utenti. La documentazione di LaunchDarkly descrive rilasci ad anelli, rilasci in percentuale, canary release, rilasci mirati, rilasci basati sui diritti di utilizzo e dark launch. In parole semplici:

• Rilascio ad anelli: prima il personale interno, poi un gruppo beta e infine tutti. È indicato quando disponete di un pubblico beta naturale.
• Rollout in percentuale: esporre l’1%, poi il 5%, poi il 25% e così via. È più adatto quando la base utenti presenta poca variabilità o non avete un programma beta.
• Canary: un gruppo piccolo e rappresentativo per testare l’accettazione e la capacità.
• Rilascio mirato: account o gruppi specifici, utile quando i clienti dipendono gli uni dagli altri.
• Dark launch: il codice viene distribuito e utilizzato, ma non rilasciato pubblicamente.

Il modello di rollout di Azure aggiunge dimensioni utili: targeting per utente, gruppo o attributi personalizzati come area geografica, tipo di dispositivo o livello di abbonamento, oltre all’attivazione pianificata. AWS esprime bene il concetto: limitare il raggio d’impatto mentre si eseguono test in condizioni reali è preferibile all’esposizione simultanea di tutti gli utenti.

Due regole rendono affidabile il rollout in percentuale. Primo, mantenete coerente l’assegnazione, in modo che un utente che oggi vede il nuovo checkout non veda quello precedente domani. Secondo, stabilite in anticipo cosa monitorerete e quale risultato farà scattare il kill switch. Un rollout senza una condizione di arresto è solo un lancio lento.

GitHub descrive l’attivazione delle modifiche rischiose per tutti o per una percentuale di utenti dopo la distribuzione e poi la loro disattivazione in pochi secondi senza eseguire il rollback. Funziona solo se è possibile vedere rapidamente l’effetto, motivo per cui flag e monitoraggio procedono di pari passo. Il nostro approfondimento su osservabilità delle applicazioni spiega cosa monitorare.

Quando i feature flag non funzionano

Gli svantaggi sono specifici e vale la pena conoscerli prima di prendere un impegno.

Codice obsoleto e riutilizzo non sicuro. Il resoconto di InfoQ sull’incidente di Knight Capital del 2012 descrive il riutilizzo di un flag obsoleto mentre il codice inutilizzato era ancora presente. Il risultato è stato circa 460 milioni di dollari di perdite in circa 30 minuti. Due lezioni: eliminare il codice inutilizzato e non riutilizzare mai il nome di un vecchio flag per un comportamento nuovo.

Complessità combinatoria. Ogni flag raddoppia teoricamente il numero di percorsi del codice. Non sarà possibile testarli tutti, quindi è bene mantenere al minimo i flag che interagiscono tra loro e documentarne le dipendenze. GitHub elenca inoltre rischi specifici, come query al database più lente, casi limite logici imprevisti e valori del database non validi.

Il servizio dei flag come singolo punto di guasto. Il rapporto sull’incidente pubblicato da PostHog registra che il 78% delle richieste di valutazione dei feature flag nella sua regione statunitense è fallito per 1 ora e 48 minuti, con l’amplificazione dei tentativi e controlli di integrità insufficienti che ne hanno prolungato la durata. Un’analisi post-incidente successiva tratta di quattro incidenti nell’arco di 10 giorni che hanno interessato sia l’applicazione principale sia la valutazione dei flag. La lezione per i propri sistemi è questa: le cache locali e i valori predefiniti di fallback mantengono in funzione le applicazioni quando il sistema dei flag non è disponibile, come osserva la guida alle best practice. Verificare cosa fa l’applicazione quando la valutazione dei flag va in timeout. Non scoprirlo in produzione.

Valutazione incoerente. Lo stesso flag può essere risolto in modo diverso all’interno di una singola richiesta se viene letto due volte. Valutarlo una sola volta all’inizio della richiesta e passare il risultato alle fasi successive.

Scegliere gli strumenti per la gestione dei feature flag

Creare un sistema di flag di base è un progetto da fine settimana. Gestirlo in sicurezza per anni è tutt’altra cosa, quindi è importante decidere con piena consapevolezza. Quando si valutano piattaforme o una soluzione sviluppata internamente, l’elenco delle funzionalità pubblicato da LaunchDarkly è una checklist utile: copertura degli SDK, flag booleani e multivariati, targeting e segmentazione, rilasci progressivi, controllo per ambiente, prerequisiti, aggiornamenti in tempo reale, kill switch, RBAC, approvazioni, registri di audit e integrazioni.

Oltre a questo elenco, è utile porsi le seguenti domande:

1. Cosa succede quando il servizio non è disponibile? Cercare il supporto della cache locale e un comportamento di fallback documentato. Ad esempio, la pagina dei prezzi di un fornitore descrive SDK che scaricano e memorizzano nella cache la configurazione, valutandola a partire da tale cache.
2. Con quale rapidità si propagano le modifiche? Secondi o minuti? L’intervallo di polling è compatibile con le aspettative relative ai kill switch?
3. È possibile gestire i flag come codice? Interfaccia utente, CLI, API e flussi di lavoro Git diventano importanti quando si hanno più di qualche decina di flag.
4. Lo strumento aiuta a fare pulizia? La reportistica sui flag obsoleti vale più di un’ulteriore opzione di targeting.
5. Dove vengono trasferiti i dati degli utenti? La valutazione dei flag lato server mantiene i dati personali fuori dai sistemi di terze parti.

Per i piccoli team che gestiscono pochi flag di rilascio, un approccio interno semplice, con una nomenclatura rigorosa e date di scadenza, può essere sufficiente. Con la crescita dei team, dei servizi e dei requisiti di conformità, le piattaforme gestite giustificano il loro costo. La scelta giusta dipende dalla vostra architettura ed è una questione da definire prima di arrivare a duecento flag.

Come vi aiutiamo a gestire i programmi di feature flag

Presso Ridiculous Engineering, ingegneri senior collaborano con il vostro team sulle decisioni relative ai feature flag: quali tipi di flag vi servono, come integrare la valutazione nella vostra architettura, quale governance si adatta al vostro profilo di rischio e come incorporare la pulizia nella pipeline di delivery. Se state modernizzando un sistema legacy o costruendo qualcosa di nuovo, i nostri servizi di consulenza e delivery software e gli incarichi di sviluppo software personalizzato vengono definiti in base alla vostra situazione, con prezzi su richiesta. Potete anche consultare i nostri articoli DevOps per approfondire pratiche correlate.

I feature flag sono una disciplina, non un interruttore

I feature flag vi offrono qualcosa di raro: la possibilità di rilasciare continuamente e fare comunque marcia indietro in pochi secondi. Mantengono questa promessa solo quando ogni flag ha un tipo, un responsabile, un test per entrambi i percorsi, una traccia di audit e una data di fine. Trattate il sistema dei flag come un'infrastruttura di produzione, mantenete gli kill switch per i momenti che contano e rimuovete tutto il resto secondo programma.

Iniziate in piccolo. Scegliete una funzionalità imminente, assegnate un responsabile, create prima il ticket di rimozione e gestitela attraverso l'intero ciclo di vita. Ciò che il vostro team imparerà da quel singolo flag plasmerà ogni politica successiva.

Domande frequenti

Qual è la differenza tra feature flag e feature toggle?

Nessuna differenza significativa. I termini sono usati indistintamente e il noto articolo di Martin Fowler li utilizza entrambi. Alcuni team riservano il termine toggle ai semplici interruttori on/off e flag a quelli con regole di targeting, ma si tratta di una convenzione interna, non di uno standard.

I feature flag sono la stessa cosa della configurazione?

No. La configurazione è generalmente di lunga durata e viene caricata all'avvio, mentre i flag sono dinamici, di breve durata e vengono modificati durante l'esecuzione. Tenerli separati evita che impostazioni sensibili finiscano in uno strumento progettato per modifiche frequenti e a basso attrito.

Quali sono gli svantaggi dei feature flag?

I principali sono i flag obsoleti che diventano debito tecnico, percorsi di codice aggiuntivi che moltiplicano l'impegno necessario per i test e la dipendenza dal servizio dei flag. La sicurezza è un'ulteriore preoccupazione se i flag proteggono i controlli di accesso. Responsabili, date di scadenza, valori predefiniti sicuri e valutazione lato server affrontano la maggior parte di questi problemi.

Quando dovrebbe un kill switch rimanere permanentemente attivo?

Mantenetelo quando protegge da un rischio operativo ricorrente, ad esempio una dipendenza di terze parti inaffidabile o una funzionalità pesante sotto carico di picco. Documentatelo, verificate periodicamente che funzioni e assegnategli un responsabile come a qualsiasi altro controllo di lunga durata.

Fonti

• Feature flag - .NET | Microsoft Learn
• Concetti fondamentali dei feature flag | Atlassian
• Cosa sono i feature flag? | Documentazione di Confidence
• Feature Toggle (noti anche come Feature Flag) | Martin Fowler
• Comprendere la gestione delle funzionalità con Azure App Configuration | Microsoft Learn
• Sperimentazione progressiva con i feature flag | Microsoft Learn
• 11 best practice per creare e scalare i sistemi di feature flag | Unleash
• Sulla rimozione dei Feature Toggle (2021)
• Feature Toggle | Modello di qualità arc42
• Best practice per la gestione dei flag | Harness
• Best practice per una gestione efficace dei feature flag | Harness
• Elusione della sicurezza dei feature flag | OWASP Web Security Testing Guide
• Strategie di deployment e rilascio | LaunchDarkly
• Come funzionano i feature flag | LaunchDarkly
• Implementare tecniche di rilascio incrementale delle funzionalità | AWS Well-Architected
• Come rilasciamo il codice più velocemente e in modo più sicuro con i feature flag | GitHub
• Quando i Feature Flag vanno male | InfoQ
• Interruzione del servizio dei feature flag | PostHog
• Interruzioni ricorrenti causate dai feature flag | PostHog
• Prezzi | ConfigCat

Consigliato

• Gestione dei rilasci: come i team di ingegneria distribuiscono le modifiche in sicurezza
• Ottimizza le tue pratiche DevOps con approfondimenti e strumenti di esperti