Targeting

Por defecto, un entorno sirve a cada dispositivo el valor por defecto del flag. El targeting es cómo sirves otra cosa a algunos dispositivos: probadores beta, una versión concreta de la app, el 10% de todo el mundo. Esta página explica la maquinaria; la guía de rollouts te acompaña al usarla.

Etiquetas: lo que ven las reglas

Las reglas comprueban etiquetas — pequeños hechos clave/valor sobre el dispositivo que pregunta. Los SDK envían automáticamente unas cuantas etiquetas integradas (appVersion, appBuild, osVersion, platform, sdkVersion), y tu app puede añadir las suyas, como cohort: "beta".

Dos cosas sobre las etiquetas que conviene saber pronto:

• Las etiquetas se evalúan y se olvidan. FortressFlag las usa para responder a la única petición en la que llegaron, y después las descarta — nunca se almacenan y nunca se registran. No existe un historial de etiquetas en ningún sitio, por diseño.
• Las etiquetas son afirmaciones de tu app. Una etiqueta puede llevar cualquier cosa que tu código ponga en ella — así que no pongas secretos ni datos personales de tus usuarios en los valores de las etiquetas. Limítalas a cohortes, versiones y configuración.

Reglas: una lista ordenada, gana la primera coincidencia

Cada flag + entorno tiene una lista ordenada de reglas. Una regla es un grupo de condiciones unidas con AND — cohort es beta AND appVersion ≥ 2.0 — más el valor que sirve cuando coincide.

La evaluación es sencilla y vale la pena interiorizarla:

1. Las reglas se comprueban de arriba abajo.
2. La primera regla cuyas condiciones se cumplen todas decide el valor. Nada por debajo se consulta — el orden es significado, y puedes reordenar las reglas en el panel.
3. Una condición sobre una etiqueta que el dispositivo no envió no se cumple. Sin etiqueta, sin coincidencia — la regla se salta, nunca es un error.
4. Si ninguna regla coincide, se sirve el valor por defecto del flag.

Una regla sin condiciones siempre coincide — es la forma de «todos los demás» que pones al final de una lista.

Comparaciones de versiones

Las condiciones pueden comparar versiones: appVersion ≥ 2.0. Las versiones se separan por puntos y se comparan numéricamente, de izquierda a derecha, y los componentes que faltan se leen como cero — así que 2.0 es igual a 2.0.0, y 2.10 es más reciente que 2.9. Una versión de dispositivo que no se pueda interpretar como números separados por puntos (digamos, 2.0-beta) simplemente hace que la condición no se cumpla. Los sufijos de prelanzamiento no se admiten — compara versiones simples separadas por puntos.

Segmentos: un trozo de regla al que pones nombre y reutilizas

Un segmento es una lista AND de condiciones con nombre — beta-testers, internal-devices — que defines una vez para toda tu organización y referencias desde reglas de distintos flags y entornos. Edita el segmento, y cada regla que lo usa le sigue.

Ese alcance es exactamente la razón por la que editar un segmento requiere permiso de nivel producción: un segmento referenciado por una regla de producción cambia producción cuando cambia, sea quien sea quien lo guarde.

Rollouts porcentuales

Cualquier regla puede llevar un porcentaje de rollout: en lugar de coincidir con cada dispositivo que pasa sus condiciones, coincide solo con el primer N% de ellos. Así es como funciona «el 10% de los probadores beta» — primero las condiciones, después la puerta del porcentaje.

Tres propiedades hacen que se pueda confiar en los rollouts:

• Fijos. Que un dispositivo esté dentro del porcentaje se calcula a partir de la identidad del dispositivo y la clave del flag — el mismo dispositivo recibe la misma respuesta en cada petición. Nadie parpadea entrando y saliendo de un rollout, y subir del 10% al 20% mantiene dentro al 10% original.
• Por flag. El cálculo mezcla la clave del flag, así que un rollout del 10% en un flag y un rollout del 10% en otro alcanzan décimas distintas de tu flota. No hay un 10% de dispositivos permanentemente desafortunado que reciba todos los experimentos a la vez.
• No se almacena nada. La pertenencia a una cohorte es pura aritmética, recalculada en cada petición — FortressFlag no guarda ningún registro de qué dispositivos están en qué rollout. No hay nada que filtrar ni nada que limpiar.

Límites

Lo bastante generosos como para que normalmente no los alcances, fijos para que las cargas útiles sigan acotadas: hasta 20 reglas por flag y entorno, 5 condiciones por regla (una referencia a un segmento cuenta como una y puede contener hasta 10 propias), claves de etiqueta de hasta 64 caracteres, valores de condición de hasta 256.

¿Por dónde seguir?

• Configura un rollout porcentual — la tarea, paso a paso
• Entornos y proyectos — el targeting es por entorno
• Cómo llegan los flags a tu app — por qué los dispositivos nunca ven tus reglas