Spegni la funzione senza ripubblicare

Cos'è e perché conta

Un feature flag, in italiano un interruttore, è un sì o no che l'app legge mentre gira. Se è acceso, l'utente vede la funzione nuova. Se è spento, vede quella di prima. Il codice di tutte e due le strade è già dentro l'app: l'interruttore sceglie solo quale usare.

Il problema che risolve è semplice. Pubblichi una funzione, qualcosa si rompe, e per toglierla devi fare un'altra modifica, un altro deploy, magari aspettare la revisione dello store. Con l'interruttore cambi un valore e la funzione sparisce. Poi la sistemi con calma.

Per chi costruisce con Claude Code conta ancora di più: pubblichi spesso, e non sempre hai letto ogni riga. Poter spegnere quello che hai appena pubblicato, senza toccare il codice, ti toglie tanta ansia il giorno del rilascio.

1. Dove li tengo

Io uso una tabella «flags» nel database che l'app usa già: una riga per interruttore, con nome, acceso sì o no, percentuale e lista di utenti. L'app la legge all'avvio e ogni tanto mentre è aperta. Cambio un valore e la funzione si accende o si spegne senza una nuova versione. Chi ha l'app già aperta riceve il cambio alla lettura successiva dei flag.

L'unica condizione vera è questa: il valore deve stare in un posto che puoi cambiare senza un deploy. Le strade principali sono tre.

• Una tabella nel database. È quello che faccio io: niente di nuovo da imparare, e la cambi anche da una pagina tua.
• Un servizio dedicato ai feature flag o alla configurazione remota. Ti dà un pannello già pronto, percentuali e statistiche. Per iniziare la tabella basta.
• Una variabile d'ambiente. Va bene sul server, ma su molti hosting cambiarla richiede un nuovo deploy o un riavvio: controlla come la applica il tuo hosting. In un'app mobile di solito resta fissata nella build.

Per prima cosa chiedo a Claude Code la tabella e un solo punto del codice da cui passano tutte le domande sugli interruttori, invece di venti controlli sparsi. Con Claude Code tutto quello che segue si mette in pochi minuti.

Crea una tabella flags con nome, acceso sì o no, percentuale e lista di utenti, e una sola funzione che l'app usa per sapere se un interruttore è acceso per l'utente attuale.

2. La funzione nasce spenta

Ogni funzione nuova entra nel codice già dietro il suo interruttore, spento.

Metti la funzione X dietro un interruttore chiamato nuova-x, spento di default, letto dalla tabella flags.

Poi pubblico così. Per gli utenti non cambia niente: il codice nuovo c'è, ma non parte. È la prima delle tre regole: nessun valore nel database può far comparire una funzione che non è nell'app installata.

Sulle app per iPhone questo è la seconda regola, e Apple la scrive chiara: le funzioni nuove vanno descritte nelle note per la revisione e devono essere accessibili a chi revisiona, e quelle nascoste sono vietate. Se pubblichi una funzione spenta, scrivilo nelle note e spiega come vederla.

3. Accendere a scaglioni

Non accendo mai per tutti in un colpo. Prima per me, poi per una decina di utenti, poi per tutti.

Fai in modo che nuova-x si possa accendere per una lista di utenti e per una percentuale, sempre la stessa per lo stesso utente.

La parte «sempre la stessa per lo stesso utente» conta. Se l'app tira a sorte ogni volta che si apre, la stessa persona vede la funzione oggi e non domani. Di solito si calcola un numero fisso partendo dall'id dell'utente: se il numero cade sotto la percentuale, la funzione è accesa. Così, quando alzi la percentuale, chi l'aveva già continua ad averla.

Tra uno scaglione e l'altro guardo gli errori e i messaggi degli utenti. Se è tutto tranquillo, salgo.

4. Se la lettura fallisce, resta tutto spento

L'interruttore è già un kill switch: se la funzione dà problemi, la spengo e torna la versione vecchia. Ma c'è un caso a cui nessuno pensa: e se l'app non riesce a leggere i flag? Database lento, niente rete, tabella rinominata per sbaglio.

Se la lettura dei flag fallisce, considera tutti gli interruttori spenti e mostra la versione vecchia.

Così, se la lettura fallisce, l'app mostra da sola la versione che funzionava già. Accendere tutto quando non sa è il modo più veloce per mostrare a tutti una funzione a metà.

Poi c'è il ritardo: chi ha l'app aperta vede la funzione finché non rilegge i flag, e anche i servizi dedicati di solito tengono i valori in memoria. Quanto devo aspettare, lo chiedo.

Dimmi dopo quanto tempo, nel caso peggiore, un utente con l'app già aperta vede un interruttore che ho appena spento, e dove si decide questo tempo.

5. La tabella la cambio solo io, e dal telefono

Per non dover aprire il database dal computer, uso una pagina admin dal telefono. Ma prima della pagina viene la protezione: nascondere un pulsante non basta. Chi può modificare la tabella lo deve decidere il server, altrimenti qualcuno più furbo accende e spegne le tue funzioni senza passare dalla pagina. Per questo il prompt fa le due cose in quest'ordine.

Proteggi la tabella flags sul server: la può leggere l'app, ma la può modificare solo il mio account. Poi crea una pagina admin, solo per me, con un interruttore per ogni riga.

6. La pulizia

Un interruttore acceso per tutti da settimane, e che va bene, non serve più. Lasciato lì è codice vecchio che nessuno prova, e una riga che prima o poi qualcuno spegne per sbaglio. In più, con la regola del punto 4, se la lettura fallisce l'app torna alla versione vecchia anche per una funzione che usano tutti.

Elenca gli interruttori accesi per tutti da più di un mese e toglili dal codice, lasciando la funzione accesa.

Prima di pubblicare, controllo che la funzione resti accesa e tolgo la riga anche dalla tabella.

Le tre regole

• L'interruttore accende solo codice che è già nella versione pubblicata: la funzione va pubblicata spenta, prima.
• Spegnere codice già pubblicato non richiede revisione; ma gli store non ammettono funzioni nascoste da accendere dopo senza revisione. I flag servono per spegnere e per accendere a scaglioni, non per far passare di nascosto funzioni nuove.
• Niente di segreto nei flag: li legge l'app, quindi chi vuole li vede.

Anche il nome conta: «sconto-segreto-partner» racconta già troppo. Chiavi e password restano sul server.

Gli errori più comuni

• Accendere il flag prima di aver pubblicato la funzione: non succede niente, perché il codice non c'è. Prima pubblica spento, poi accendi.
• Considerare acceso un flag che non si riesce a leggere: se la lettura fallisce, il valore giusto è spento.
• Tirare a sorte a ogni apertura: la percentuale deve dare sempre lo stesso risultato per lo stesso utente.
• Proteggere solo la pagina admin: anche la tabella deve accettare modifiche solo dal tuo account.
• Non togliere mai gli interruttori vecchi: quelli accesi per tutti da più di un mese vanno tolti dal codice.

Checklist

• Tabella flags creata, una sola funzione per leggerla
• La funzione nuova è pubblicata spenta
• Percentuale stabile per lo stesso utente
• Se la lettura fallisce, tutto spento
• So dopo quanto si spegne per chi ha l'app aperta
• Solo il mio account può cambiare i flag
• Ogni tanto tolgo i flag accesi da più di un mese

Domande frequenti