Introducción
Desplegar rápido no es el problema. El problema es desplegar rápido y enterarte tarde de que rompiste algo.
Las feature flags prometen justo lo contrario: separar despliegue de publicación y controlar quién ve qué. Pero si se usan sin disciplina, se convierten en una capa de complejidad difícil de desmontar.
En este artículo te explico qué son, por qué importan y cómo aplicarlas con un enfoque que no genere deuda técnica.
Qué es una feature flag
Una feature flag es un mecanismo para activar o desactivar comportamiento en producción sin tener que volver a desplegar código. Suele ser una condición controlada por configuración.
Dicho de otro modo, es un interruptor. Puedes mostrar una funcionalidad a un grupo pequeño, apagarla si hay problemas o probar variantes sin forzar un release completo.
No se trata de «poner ifs por todas partes», sino de gestionar el ciclo de vida de cada flag: creación, rollout, medición y retirada.
Por qué es relevante
Es relevante porque reduce riesgo. Puedes hacer despliegues pequeños, medir y corregir antes de impactar a todos los usuarios.
Además, bien usadas aceleran aprendizaje: validas hipótesis de producto, controlas incidencias con un kill switch y evitas que cada release sea un salto de fe.
Desarrollo principal
Empieza con una estrategia: cada flag necesita objetivo, responsable y fecha de retirada. Sin esas tres cosas, se acumulan y el código se vuelve ilegible.
Define tipos de uso. En la práctica, no es lo mismo una flag temporal de release que una de emergencia o una de experimentación. Cada una pide controles distintos.
Diseña el rollout por fases: primero interno, luego grupos acotados y finalmente general. Lo interesante aquí es medir en cada fase antes de avanzar.
Acompaña el rollout con observabilidad: errores, rendimiento, conversiones y tickets de soporte. Si no miras métricas, el rollout es una apuesta.
Cuando la funcionalidad esté estable, elimina la flag y simplifica. No se trata de mantener la opción «por si acaso», sino de evitar ramas muertas que nadie testea.
Y cuida seguridad: las flags no deberían convertirse en una forma de saltarse autorizaciones. Separar «feature rollout» de «control de acceso» evita sorpresas.
Desglose práctico
Caso típico: activar una mejora de checkout solo para un 5% de tráfico. Si sube el error rate o baja la conversión, puedes pausar sin un rollback agresivo.
Otro caso: un kill switch para integrar un tercero. Si la API del proveedor se degrada, apagas la integración y vuelves a un modo degradado.
En entornos B2B, las flags por cliente (tenant) ayudan a hacer pilotos sin clonar versiones. Dicho de otro modo, pruebas en producción sin convertirlo en un laboratorio descontrolado.
Y para equipos de ingeniería, una buena práctica es tener un inventario de flags activas, con su dueño y su fecha objetivo de retirada. Eso evita deuda silenciosa.
Limitaciones o consideraciones
Las flags añaden complejidad. Duplican rutas de código y, si no se testean, aparecen bugs que solo afectan a un segmento.
También pueden impactar rendimiento si se evalúan de forma masiva o si dependen de llamadas externas. En la práctica, conviene diseñarlas para fallar de forma segura.
Por último, si la organización no tiene disciplina de retirada, el sistema se degrada. No se trata de implementar la herramienta, sino de sostener el hábito.
Conclusión con visión de futuro
Las feature flags son una palanca potente para entregar con control. Usadas con criterio, te dan velocidad sin sacrificar estabilidad.
A futuro veremos más integración con observabilidad y políticas de despliegue. Pero el fundamento seguirá siendo el mismo: estrategia clara, medición y retirada.