Flags y tipos
Un flag es una decisión con nombre que tu app le pide a FortressFlag que tome: ¿debería este dispositivo ver el nuevo checkout? ¿Qué texto va en el botón de compra? ¿Cuántos reintentos antes de rendirnos? Esta página te da el vocabulario sobre el que se construye el resto de la documentación.
Los flags viven en un proyecto y tienen un valor por entorno
Sección titulada «Los flags viven en un proyecto y tienen un valor por entorno»Cada flag pertenece a un proyecto y se identifica por su clave — un nombre corto en
minúsculas como new-checkout. La clave es lo que pide tu código, y es inmutable después
de crearla: tus apps publicadas llevan la clave incrustada en su código, así que
renombrarla las rompería. Puedes cambiar el nombre visible de un flag cuando quieras; la
clave es para siempre.
Un flag no tiene un valor — tiene un valor por entorno. new-checkout puede estar
activado en dev, en rollout en staging y desactivado en production, todo a la vez.
Cambias y haces targeting de cada entorno de forma independiente.
Los tres tipos
Sección titulada «Los tres tipos»Cada flag tiene un tipo, elegido al crearlo e inmutable después:
| Tipo | Valores | Ideal para |
|---|---|---|
| Boolean | true / false |
Interruptores de emergencia, puertas de funcionalidades, rollouts |
| String | Variantes de texto con nombre | Experimentos de textos, selección de algoritmos, temas |
| Number | Variantes numéricas con nombre | Límites, tiempos de espera, umbrales |
El tipo es inmutable por la misma razón que la clave: tu código lee el flag a través de una
llamada tipada (isEnabled, stringValue, numberValue), y un flag que cambiara de tipo
bajo una app ya publicada dejaría de tener sentido para ella.
Variantes
Sección titulada «Variantes»Los flags de cadena y numéricos sirven variantes — valores con nombre como control →
"buy-now" y treatment → "start-free". Los nombres son para ti y para tu panel; los
dispositivos de tus usuarios solo reciben el valor. Los nombres de las variantes nunca
salen del plano de gestión.
Valores por defecto, y el valor por defecto detrás del valor por defecto
Sección titulada «Valores por defecto, y el valor por defecto detrás del valor por defecto»Dos cosas distintas se llaman «valor por defecto», y conviene tenerlas separadas:
- El valor por defecto del flag es lo que sirve un entorno cuando ninguna regla de targeting coincide. Para un flag booleano es su estado activado/desactivado; para un flag multivariante es la variante que eliges como predeterminada.
- El valor por defecto de tu código es el valor que pasas en el punto de llamada —
isEnabled("new-checkout", default: false). Es el fondo de la cadena de respaldo: lo que usa tu app cuando nunca ha llegado a FortressFlag, o cuando el flag no existe (o no tiene ningún valor que servir) en ese entorno.
Un flag multivariante recién creado sin variante predeterminada elegida no sirve nada — el valor por defecto de tu código responde hasta que lo decidas. Es deliberado: un flag que no has terminado de configurar debe comportarse como un flag que no existe.
El ciclo de vida: archivar, restaurar, purgar
Sección titulada «El ciclo de vida: archivar, restaurar, purgar»Eliminar un flag es reversible — hasta cierto punto. Archivarlo lo quita de tus apps: en cada dispositivo conectado el flag deja de resolverse en aproximadamente un minuto, y los valores por defecto de tu código toman el relevo. Un flag archivado puede restaurarse intacto dentro del periodo de retención, o purgarse de forma permanente después. La lista de archivados vive dentro de cada proyecto, junto a los flags que contiene.
Si un flag lleva 90 días sin tocarse, el panel lo marca como obsoleto — un empujón para archivarlo, nunca un archivado automático. Los flags que has olvidado son complejidad que tu código sigue pagando.
¿Por dónde seguir?
Sección titulada «¿Por dónde seguir?»- Targeting — reglas, segmentos y rollouts porcentuales
- Entornos y proyectos — dónde viven los flags
- Cómo llegan los flags a tu app — qué recibe realmente un dispositivo