Su AZ-400 i feature flag non sono un argomento di sintassi. La domanda tipica è: dato un requisito di rilascio — esporre a un sottoinsieme, poter rientrare in secondi, misurare l’impatto su una metrica di business — quale meccanismo scelgo e quale prezzo pago in complessità e manutenzione. Microsoft definisce il feature management come la pratica che disaccoppia il rilascio di una feature dal deployment del codice, amministrandone il ciclo di vita in modo dinamico. Diamo per acquisiti i meccanismi base e concentriamoci sulle decisioni di design e sui trade-off.

Deployment ed esposizione sono due decisioni distinte

Con un flag il binario in produzione contiene già il codice della feature, dormiente. Microsoft documenta la separazione su cinque scenari: dark deployment (spedisci codice incompleto in main senza esporlo, eliminando i branch a lunga vita), test in production su utenti interni o beta tester, flighting incrementale, instant kill switch senza redeploy e selective activation per segmento.

La conseguenza architetturale è che il rischio si sposta: la pipeline non è più l’unica frontiera, e la configurazione runtime diventa superficie di produzione. Le linee guida App Configuration sono esplicite: applica le safe deployment practices, evita modifiche di configurazione fatte a mano dal portale direttamente sulla produzione, e usa gli snapshot — immutabili — per la configurazione di base, con rollback all’ultima versione buona nota. Il pattern raccomandato è ibrido: snapshot per la baseline, dynamic configuration per override d’emergenza e feature flag.

Sul lato branching, i flag rendono praticabile il trunk-based development che Microsoft usa internamente: si lavora in main, si merge presto, la feature resta nascosta. Attenzione a una trappola documentata: se la feature introduce dipendenze — per esempio espone un endpoint REST — quelle esistono anche a flag spento e portano lavoro di sicurezza e manutenzione. Il flag nasconde l’esperienza utente, non la superficie d’attacco.

Filtri: dove collocare la regola di esposizione

Un flag basico è booleano. Un conditional feature flag delega la decisione a uno o più feature filter. La libreria Microsoft.FeatureManagement porta filtri built-in che non richiedono codice: il time window filter, che accende la feature in una finestra temporale (con supporto alla ricorrenza), il percentage filter, che la abilita su una quota della base utenti, e il targeting filter con la sua variante contestuale, per il rollout progressivo su utenti e gruppi nominali. Quando nessuno di questi esprime la regola che ti serve scrivi un custom filter: codice tuo, invocato a ogni valutazione. La scelta di design è dove far vivere la regola — nella configurazione, dove la cambi senza redeploy, o nel custom filter, dove hai potenza espressiva ma torni a dipendere dal ciclo di rilascio.

Quando componi più filtri entra in gioco requirement_type. Il default è Any: basta che un filtro sia vero. Con All devono esserlo tutti. È la leva per requisiti tipo “rollout percentuale, ma solo nella finestra di manutenzione”.

Il targeting filter modella un’audience come combinazione di utenti nominali, gruppi e una default percentage sul resto della base, con liste di inclusione ed esclusione. Due punti che l’esame ama: l’esclusione vince sempre sull’inclusione, e gli “utenti” non devono essere account umani — possono essere macchine, dispositivi o qualunque entità identificabile univocamente, mentre i gruppi li definisce l’applicazione (gruppi Microsoft Entra ID, aree geografiche, stadi di rollout per le macchine). È così che si implementano i ring di esposizione: prima team e utenti interni via include users, poi gruppi di early adopter, infine si apre la default percentage.

Un vincolo di privacy da tenere in progettazione: nomi di utenti e gruppi nelle impostazioni di targeting possono costituire informazione identificativa dell’utente finale. Se la configurazione viene servita ad applicazioni client, la raccomandazione è uno store separato e dedicato, con soli valori non sensibili e filtri stretti su prefissi, label o tag.

Varianti, telemetria e progressive exposure

Il variant feature flag supera il booleano: definisce più varianti, ciascuna con nome e un valore di configurazione opzionale (da primitiva JSON a oggetto complesso). Le regole di allocation decidono chi riceve cosa, valutate in ordine preciso: prima user, poi group, infine percentile. Chi resta fuori prende default_when_enabled. Portare enabled a false è il kill switch: tutti finiscono su default_when_disabled, ignorando percentili e override — la risposta corretta quando il requisito dice “fermare l’esperimento senza redeploy”.

Il parametro seed è il dettaglio che distingue chi ha capito il modello. Il percentile di un utente è calcolato a partire dal seed; feature diverse che condividono lo stesso seed assegnano lo stesso utente alla stessa fascia. In assenza di seed esplicito ne viene derivato uno dal nome della feature. Design: seed distinti quando vuoi esperimenti indipendenti, seed condiviso quando vuoi coorti coerenti tra più flag.

L’A/B testing nasce dall’unione di varianti e telemetria. Abilitata la telemetria sul flag e connesso lo store ad Application Insights, l’applicazione emette eventi FeatureEvaluation con dimensioni tra cui TargetingId, Variant e il riferimento al flag. Nel portale puoi raggruppare per variante e per assignment reason — tra i valori documentati Percentile, Group, User, DefaultWhenEnabled e DefaultWhenDisabled. Qui c’è una distinzione che vale punti: verificare che il rollout funzioni significa controllare assignment reason e distribuzione; verificare che la variante funzioni significa correlare in KQL gli eventi FeatureEvaluation con gli eventi di business su TargetingId. Due domande diverse, due strumenti diversi.

Ultimo trade-off, spesso ignorato: la maturità delle capability non è uniforme fra i linguaggi. Targeting, time window e varianti sono ampiamente disponibili sulle librerie di feature management supportate, ma telemetria e integrazione Application Insights non lo sono ovunque allo stesso livello. In uno scenario poliglotta, verifica la matrice di supporto prima di promettere un esperimento end-to-end.

Governance: il flag è debito tecnico dal giorno uno

Ogni flag raddoppia i percorsi di codice da testare. La guida Microsoft è netta: la maggior parte dei flag va ritirata una volta completato il rollout, eliminando tutti i riferimenti in codice e configurazione, e conviene istituire una review periodica dei flag, per esempio a inizio sprint. Per i pochi flag che sopravvivono — tipicamente switch infrastrutturali tenuti come rete di sicurezza dopo una migrazione — vale l’avvertenza esplicita: quel ramo può essere riattivato, quindi va testato e manutenuto finché esiste.

Le leve efficaci sono organizzative prima che tecniche: un owner esplicito per ogni flag, una definizione centralizzata per servizio (un elenco che cresce visibilmente crea l’incentivo naturale a cancellare), naming a prefisso gerarchico. Sul versante ambienti, App Configuration offre key prefix e label: le label sovrappongono valori per ambiente caricando prima il set senza label e poi quello specifico, con l’ultimo che vince. Se il requisito è isolamento forte, la risposta è uno store separato, non una label.

Infine, i flag rientrano nella configuration as code: puoi sincronizzare i file verso lo store con GitHub Actions o con il task di import di Azure Pipelines, ottenendo tracciabilità e approvazione. Il trade-off è che se ogni modifica passa da una pull request perdi l’immediatezza del kill switch. Per il refresh a runtime la scelta è fra monitorare tutte le chiavi selezionate o una sentinel key aggiornata solo a modifiche completate: la sentinel garantisce coerenza quando cambi più valori insieme e riduce le richieste allo store.

Come cade all’esame

  • “Il codice della feature deve essere in produzione ma invisibile, senza mantenere un branch parallelo” → dark deployment con feature flag e trunk-based development; non un long-lived feature branch né un deploy condizionale in pipeline.
  • “Serve disabilitare istantaneamente una feature difettosa senza rebuild” → kill switch sul flag, con default_when_disabled se il flag è a varianti; non un rollback della release.
  • “Attivare la feature solo in una finestra e solo per una quota di utenti” → due filtri combinati con requirement_type impostato su All; il default Any risponderebbe alla domanda sbagliata.
  • “Rollout progressivo per anelli: prima il team, poi i clienti che aderiscono, poi tutti” → targeting filter con include users e gruppi, aumentando la default percentage; le esclusioni prevalgono sulle inclusioni.
  • “Confrontare due esperienze e capire quale converte meglio” → variant feature flag con allocation a percentile, telemetria abilitata e correlazione in Application Insights fra FeatureEvaluation e l’evento di business tramite TargetingId.
  • “Lo stesso utente deve ricadere nella stessa fascia su più feature correlate” → seed condiviso nell’allocation; senza seed esplicito il calcolo deriva dal nome della feature e le coorti divergono.
  • “Ridurre il rischio delle modifiche di configurazione in produzione” → snapshot immutabili con rollback alla last-known-good e configuration as code via pipeline.
  • “Il numero di flag attivi rende il codice ingestibile” → processo di ritiro con review ricorrente e owner per flag; non un flag di secondo livello per governare i primi.