Bandiera dell'ingegneria

Un flag di funzionalità, detto anche feature toggle, è una condizione nel codice dell'applicazione che determina in fase di esecuzione se una particolare funzionalità è attiva per un dato utente o richiesta. Invece di avere una funzionalità presente o assente a seconda della versione del codice distribuita, essa è presente nel codice ma può essere attivata o disattivata tramite configurazione. Questo disaccoppia la distribuzione dal rilascio: il codice può essere distribuito in produzione in modo continuativo, mentre le funzionalità in esso contenute rimangono invisibili finché qualcuno non decide di renderle visibili.

Per la sperimentazione, i flag di funzionalità sono il meccanismo alla base dei test lato server. Assegnare un utente a una variante di flag è funzionalmente equivalente ad assegnarlo a un gruppo di sperimentazione e, poiché la decisione viene presa nell'applicazione anziché nel browser, la variante può influenzare qualsiasi elemento controllato dall'applicazione: logica di prezzo, ranking di ricerca, algoritmi di raccomandazione, attivazione di email, regole di pagamento e comportamento del backend, aspetti che nessuno strumento di test lato client può raggiungere. Inoltre, elimina lo sfarfallio visivo prodotto dalla manipolazione lato client ed è invisibile ai blocchi pubblicitari e alle impostazioni del browser che bloccano gli script.

I flag svolgono diverse funzioni distinte che meritano di essere analizzate separatamente, data la loro diversa durata. I flag di rilascio nascondono il lavoro non ancora completato e vengono rimossi una volta che la funzionalità è stata lanciata definitivamente. I flag di sperimentazione controllano l'assegnazione delle varianti e vengono rimossi al termine del test. I flag operativi, a volte chiamati "kill switch", consentono di disabilitare istantaneamente una funzionalità se causa problemi in produzione e possono rimanere attivi a tempo indeterminato. I flag di autorizzazione limitano l'accesso alle funzionalità in base al livello di cliente o al contratto e sono di fatto permanenti. Trattare tutti e quattro come se fossero la stessa cosa è il motivo per cui le organizzazioni si ritrovano con centinaia di condizioni obsolete che nessuno osa rimuovere.

Questo accumulo rappresenta il rischio principale. Ogni flag è un ramo e il numero di possibili percorsi del codice cresce in modo moltiplicativo con l'accumularsi dei flag. Testare ogni combinazione diventa impossibile, interazioni inattese tra i flag causano difetti difficili da riprodurre e il codice diventa progressivamente più difficile da comprendere. I team disciplinati considerano la rimozione dei flag come parte integrante della definizione di "fatto", mantengono un inventario con un responsabile e una data di scadenza per ogni flag ed effettuano periodicamente verifiche per individuare i flag che mantengono un valore fisso da mesi.

Le feature flag consentono inoltre strategie di rilascio che riducono il rischio indipendentemente dalla sperimentazione. Il rollout progressivo espone una funzionalità all'uno percento del traffico, poi al cinque percento, poi al venti percento, monitorando i tassi di errore e le metriche aziendali a ogni passaggio. Il deployment ad anello espone prima gli utenti interni, poi un gruppo di beta tester e infine tutti. Le release canary eseguono una nuova versione insieme alla precedente e confrontano le metriche operative prima di procedere. Tutte queste sono varianti della stessa funzionalità: la possibilità di modificare chi vede cosa senza implementare codice.

Le flag forniscono anche il meccanismo per un'implementazione controllata a livello regionale e di segmento, aspetto fondamentale per le organizzazioni che operano in diversi mercati. Una modifica può essere inizialmente introdotta in un singolo paese, monitorata per individuare eventuali problematiche specifiche del mercato relative a lingua, metodi di pagamento, visualizzazione delle imposte o requisiti normativi, e quindi estesa una volta dimostrata la sua efficacia. Questo approccio è considerevolmente più sicuro di un rilascio globale e fornisce prove concrete del trasferimento di un miglioramento tra i diversi mercati, un aspetto che spesso viene dato per scontato e raramente verificato. La questione degli strumenti deriva dalla scalabilità: i team di piccole dimensioni possono gestire le flag con file di configurazione e una semplice interfaccia amministrativa, mentre le organizzazioni che gestiscono molte flag contemporaneamente su più servizi necessitano generalmente di una piattaforma di gestione dedicata che fornisca regole di targeting, registri di controllo e una valutazione coerente tra backend e frontend, poiché una valutazione incoerente tra i diversi livelli fa sì che gli utenti visualizzino solo una parte della funzionalità.

L'introduzione dei flag è spesso un prerequisito prima che possa esistere una seria pratica di sperimentazione, in particolare per le funzionalità che risiedono nel livello applicativo piuttosto che nel livello di presentazione. sviluppo del prodotto lavoro, l'infrastruttura flag viene normalmente costruita insieme alla pipeline di consegna, in modo che la sperimentazione, il rollout progressivo e il rollback di emergenza utilizzino tutti lo stesso meccanismo. Una volta che esiste, un Servizio CRO Il programma non si limita più a ciò che può essere modificato nel browser, il che in genere apre la strada alle idee di test di maggior valore presenti nel backlog: quelle che riguardano i prezzi, la logica di personalizzazione e i meccanismi del flusso di acquisto stesso.