Flag e tipi

Un flag è una decisione con un nome che la tua app chiede a FortressFlag di prendere: questo dispositivo deve vedere il nuovo checkout? Quale testo va sul pulsante di acquisto? Quanti tentativi prima di arrenderci? Questa pagina ti dà il vocabolario su cui si costruisce il resto della documentazione.

I flag vivono in un progetto e hanno un valore per ambiente

Ogni flag appartiene a un progetto ed è identificato dalla sua chiave — un nome breve in minuscolo come new-checkout. La chiave è ciò che il tuo codice chiede, ed è immutabile dopo la creazione: le tue app già distribuite hanno la chiave scolpita nel codice, quindi rinominarla le romperebbe. Puoi cambiare il nome visualizzato di un flag quando vuoi; la chiave è per sempre.

Un flag non ha un solo valore — ha un valore per ambiente. new-checkout può essere attivo in dev, in fase di rollout in staging e disattivo in production, tutto insieme. Attivi e indirizzi ogni ambiente in modo indipendente.

I tre tipi

Ogni flag ha un tipo, scelto alla creazione e immutabile in seguito:

Tipo	Valori	Ideale per
Boolean	`true` / `false`	Kill switch, feature gate, rollout
String	Varianti di testo con un nome	Esperimenti sui testi, selezione di algoritmi, temi
Number	Varianti numeriche con un nome	Limiti, timeout, soglie

Il tipo è immutabile per lo stesso motivo della chiave: il tuo codice legge il flag attraverso una chiamata tipizzata (isEnabled, stringValue, numberValue), e un flag che cambiasse tipo sotto un’app già distribuita smetterebbe di avere senso per lei.

Varianti

I flag stringa e numerici servono varianti — valori con un nome, come control → "buy-now" e treatment → "start-free". I nomi sono per te e per la tua dashboard; i dispositivi dei tuoi utenti ricevono sempre e solo il valore. I nomi delle varianti non lasciano mai il piano di gestione.

I valori predefiniti, e il predefinito dietro il predefinito

Due cose diverse si chiamano «valore predefinito», e vale la pena tenerle distinte:

Il predefinito del flag è ciò che un ambiente serve quando nessuna regola di targeting corrisponde. Per un flag booleano è il suo stato on/off; per un flag multivariato è la variante che scegli come predefinita.
Il predefinito del tuo codice è il valore che passi nel punto di chiamata — isEnabled("new-checkout", default: false). È il fondo della catena di fallback: è ciò che la tua app usa quando non ha mai raggiunto FortressFlag, o quando il flag non esiste (o non ha un valore da servire) in quell’ambiente.

Un flag multivariato appena creato, senza una variante predefinita scelta, non serve nulla — risponde il predefinito del tuo codice finché non decidi. È voluto: un flag che non hai finito di configurare deve comportarsi come un flag che non c’è.

Il ciclo di vita: archiviare, ripristinare, eliminare definitivamente

Eliminare un flag è reversibile — fino a un certo punto. Archiviarlo lo rimuove dalle tue app: su ogni dispositivo online il flag smette di risolversi entro circa un minuto, e subentrano i valori predefiniti del tuo codice. Un flag archiviato può essere ripristinato intatto entro la finestra di conservazione, oppure eliminato definitivamente dopo di essa. L’elenco degli archiviati vive dentro ogni progetto, accanto ai flag che contiene.

Se un flag resta intoccato per 90 giorni, la dashboard lo contrassegna come obsoleto — un invito ad archiviarlo, mai un’archiviazione automatica. I flag che hai dimenticato sono complessità che il tuo codice sta ancora pagando.

Prossimi passi

Targeting — regole, segmenti e rollout percentuali
Ambienti e progetti — dove vivono i flag
Come i flag raggiungono la tua app — cosa riceve davvero un dispositivo