Las claves verificadas
- Un feature flag separa el despliegue del momento en que una función se activa para los usuarios. Ver evidencia
- Las reglas de una bandera pueden dirigir una función a una audiencia o variante específica. Ver evidencia
- Una estrategia gradual necesita un valor por defecto y un plan para apagar la ruta nueva si aparece un problema. Ver evidencia
- Los flujos de integración continua pueden separar la entrega del código y las condiciones que habilitan un paso. Ver evidencia
Qué es un feature flag
Un feature flag es una decisión configurable que indica si una parte de la aplicación queda activa para una ejecución concreta. El código contiene la ruta nueva y la evaluación de la bandera elige si se muestra; así el despliegue de archivos deja de ser el mismo momento que la activación para todas las personas.
También puede servirte: Qué es una variable de entorno y cómo usarla
La bandera puede devolver un valor booleano simple o una variante. En una versión gradual, el sistema evalúa atributos del contexto, como un entorno, un equipo o una región, y aplica una regla que se puede cambiar sin reconstruir toda la aplicación. La configuración debe tener un responsable y una fecha de revisión.
Cómo se usa durante un despliegue
Un flujo habitual despliega primero el código con la función desactivada, verifica que la aplicación arranque y luego enciende la bandera para un grupo pequeño. Si los registros muestran un problema, apagar la bandera devuelve el tráfico a la ruta anterior mientras el equipo prepara una corrección.
La evaluación debe ocurrir en un punto claro y seguro. Si el servicio que entrega la configuración no responde, definí un valor predeterminado que preserve el comportamiento conocido y registrá el fallo sin imprimir datos sensibles. La ruta nueva también necesita pruebas aunque empiece apagada.
Qué tipos de reglas convienen
Una bandera de lanzamiento sirve para ocultar una función hasta que esté lista. Una bandera de experimento compara variantes con un criterio definido, mientras que una de operación permite reducir una carga costosa o desactivar una integración. No todas deben vivir el mismo tiempo: las de lanzamiento suelen retirarse cuando la función se estabiliza.
Las reglas deben ser deterministas para un mismo usuario o cuenta; de lo contrario, una persona podría saltar entre variantes en cada petición. Documentá la prioridad entre reglas, la audiencia alcanzada y el valor por defecto. Esa información permite revisar el cambio cuando otra persona toma el mantenimiento.
Cómo retirar una bandera sin dejar deuda
Cuando una función queda estable, eliminá la condición y la configuración asociada en una misma tarea de mantenimiento. Buscá referencias en el código, pruebas, documentación y panel de reglas; una bandera olvidada puede conservar dos rutas que nadie vuelve a ejercitar.
Antes de borrar el último control, confirmá qué variante debe quedar como comportamiento permanente y revisá los permisos del sistema de configuración. Un inventario con dueño, fecha de creación y fecha esperada de retiro ayuda a que una bandera temporal no se convierta en una dependencia invisible.
Qué aporta VisteEsto: Nuestro trabajo en esta nota
VisteEsto ordena el uso de feature flags en tres decisiones: separar despliegue y activación, definir reglas deterministas y retirar la deuda cuando la función se estabiliza.
Fuentes, actualizaciones y metodología 3 fuentes
Fuentes consultadas
- Fuente primariaMartin Fowler: Feature Toggles
- Fuente primariaLaunchDarkly Docs: Feature flags
- Fuente primariaGitHub Actions: Workflow syntax
Historial de actualización
- Publicación inicial basada en la guía de Martin Fowler, la documentación de LaunchDarkly y la sintaxis de workflows de GitHub Actions.
Cómo elaboramos esta nota
Definimos la consulta principal “qué es un feature flag y cómo funciona”, contrastamos los datos con 3 fuentes —3 primarias— y revisamos contexto, imágenes y posibles vacíos antes de publicar. Conocé nuestra política editorial y de verificación.
