Feature flag: suelta sin contener la respiración
· 4 min read · Filippo Spinella · DevOps, OpenFeature, CI/CD, Software Architecture
La implementación es cuando el código llega a producción. La liberación es cuando alguien realmente puede usarlo. Confundirlos es una de las formas más rápidas de hacer que cada despliegue sea un momento un poco tenso.
Los feature flag sirven para poner espacio entre estos dos momentos. Puede implementarlo hoy, iniciarlo mañana para el equipo interno, luego para un cliente piloto y luego para el 10% de los usuarios. Si algo sale mal, apaga la bandera. No necesariamente es necesario revertir toda la versión.
La bandera no es sólo un si
Técnicamente suele ser un if. Culturalmente es mucho más.
if (await flags.isEnabled('checkout.v2.enabled', context)) { return newCheckout(input); } return oldCheckout(input);
Ese pequeño if puede representar un despliegue gradual, un experimento, una migración, un permiso empresarial o un kill switch operativo. El problema es que si no se gestiona bien también puede convertirse en deuda técnica que se queda en el código durante dos años.
¿Dónde entra OpenFeature?
OpenFeature es una especificación abierta para evaluar feature flag con un API común. La idea es simple: el código de su aplicación no debe depender directamente del proveedor o del sistema interno que utiliza para las banderas.
La aplicación pregunta:
const enabled = await client.getBooleanValue('checkout.v2.enabled', false, { targetingKey: user.id, plan: user.plan, country: user.country, });
El proveedor decide de dónde provienen las reglas: SaaS, archivo, servicio interno, flagd, configuración de GitOps. Si un día cambia el backend de marcado de funciones, no es necesario reescribir la aplicación en todas partes.
Esta separación parece un detalle arquitectónico, pero se siente a medida que crece el proyecto.
El contexto es la mitad de la batalla
Una bandera de encendido o apagado para todos es útil, pero limitada. La entrega progresiva vive en contexto:
- usuario interno o externo;
- plan gratuito o empresarial;
- aldea;
- organización;
- versión de la aplicación;
- porcentaje estable de tráfico.
La clave importante es targetingKey: debe ser estable. Si cambia con cada solicitud, un usuario puede terminar una vez en la variante A y otra en la variante B. Para un experimento es terrible, para una compra puede ser desastroso.
Un lanzamiento sensato
Un flujo que me gusta es este:
- desplegar con la bandera apagada;
- encendido para desarrolladores y control de calidad;
- encendido para un cliente o inquilino piloto;
- 5% de implementación;
- lanzamiento al 25%;
- 100% de implementación;
- eliminación del código y la bandera antiguos.
El punto que a menudo se olvida es el último. Una bandera temporal debe tener una fecha de muerte. Si permanece para siempre, cada refactor futuro tendrá que preguntarse: "¿pero esta rama sigue siendo útil?".
Kill switch: prepáralos primero
El kill switch es la bandera que te salva cuando una dependencia externa comienza a molestarte, un trabajo consume demasiados recursos o una nueva lógica produce errores extraños.
Un buen kill switch debe ser:
- fácil de encontrar;
- documentado en el runbook;
- probado ocasionalmente;
- observable cuando se activa;
- independiente, en la medida de lo posible, de la pieza que podría romperse.
Lo peor es descubrir durante el accidente que la bandera existe, pero nadie sabe si todavía funciona.
Observabilidad o entrega no progresiva
Activar una función al 10% sin mirar las métricas es solo optimismo con múltiples pasos.
Cada implementación debe responder preguntas simples:
- ¿Han aumentado los errores?
- ¿Ha cambiado la latencia?
- ¿Los usuarios completan el flujo?
- ¿Hay más tickets o reintentos?
- ¿Una variante afecta sólo a un segmento?
OpenFeature admite ganchos alrededor de la evaluación de banderas. Son útiles para registrar errores, agregar métricas o vincular la calificación a un trace.
Denominación y propiedad
Los nombres importan. new_ui no dice nada. checkout.v2.enabled dice mucho más.
Para cada bandera marcaría al menos:
- nombre;
- descripción;
- dueño;
- valor predeterminado seguro;
- razón por la que existe;
- fecha o condición de expulsión.
Una bandera sin dueño es casi siempre una bandera que nadie borrará.
Dónde evaluarlos
¿Frontend, backend o borde? Depende.
Si la bandera es para diseño, copia o incorporación, la interfaz está bien. Si se trata de permisos, facturación, límites o datos confidenciales, debe estar en el backend. Si se trata de experimentos de enrutamiento o de mucho tráfico, la ventaja puede tener sentido.
La regla simple: el frontend puede mejorar la experiencia, pero no debería ser la única barrera de seguridad.
Conclusión
Los feature flag bien hechos cambian la relación con la producción. No eliminan el riesgo, pero lo hacen más pequeño y manejable. Puedes soltar en rodajas, observar, detenerte, retroceder, aprender.
OpenFeature agrega una base limpia: un API común, proveedores intercambiables y una forma más ordenada de hacer crecer el sistema. Pero la disciplina sigue siendo tuya: valores predeterminados seguros, nombres claros, métricas, propietarios y limpieza.
La mejor bandera es la que te ayuda a soltar con calma y luego desaparece cuando ya no es necesaria.