Los feature flags separan el momento de subir código a producción del momento en que esa función se enciende para los usuarios. Un equipo de desarrollo despliega el cambio sin que nadie lo vea, lo activa solo para una parte del tráfico y lo apaga al instante si algo falla, sin tocar el servidor ni esperar un nuevo despliegue. Para quien dirige marketing o tecnología en una empresa con web propia, desde un ecommerce de moda hasta una consultora industrial, esto cambia la pregunta de si atreverse a lanzar por la de a qué porcentaje abrirlo hoy.
Un feature flag es un interruptor en el código que decide, en tiempo real y sin nuevo despliegue, si una función está visible para un usuario, para un porcentaje del tráfico o para nadie. Permite lanzar código ya probado y encenderlo poco a poco, revirtiendo al instante si algo falla.
Feature flags: el interruptor que separa código y lanzamiento
Subir código a producción y lanzar una función para los usuarios solían ser el mismo instante. Con un feature flag dejan de serlo: el código vive ya en el servidor, apagado, y una condición en tiempo de ejecución decide quién lo ve. Martin Fowler, uno de los referentes en arquitectura de software, documentó esta separación como feature toggle hace más de una década, y desde entonces es práctica estándar en equipos que despliegan varias veces por semana.
La ventaja no es solo técnica. Para una tienda online que vende en campaña de rebajas o para una consultora que factura por proyecto, cada lanzamiento sin esta separación es una apuesta: si algo rompe el checkout o el formulario de contacto, la única salida es un despliegue de emergencia, con el tiempo que eso cuesta. Con el flag apagado, el fallo desaparece con un clic.
Despliegue progresivo, del 5% al 100% de usuarios
Un despliegue canario no abre la función a todo el tráfico de golpe: la rutea primero a una porción pequeña, normalmente entre el 5% y el 10%, mientras el resto sigue en la versión estable. Si las métricas aguantan, el porcentaje sube por tramos hasta llegar al 100%; si no, se retrocede antes de que lo note el resto de usuarios.
Las métricas que vigila un despliegue canario
El equipo técnico no mira solo si la página carga: compara la tasa de error, el tiempo de respuesta y las conversiones del grupo con el flag activado frente al grupo de control, en la misma franja horaria. Antes de subir el porcentaje conviene que esos cambios ya hayan pasado por pruebas automatizadas, como las que corre Playwright en cada despliegue. Una tienda online puede ver que el nuevo checkout carga bien pero el formulario de pago falla en Safari; una plataforma B2B puede detectar que el buscador nuevo tarda el doble en una categoría concreta de producto. Ese diagnóstico, con solo el 5% o el 10% del tráfico afectado, es la diferencia entre perder unas decenas de leads y perder el día entero de conversión. La condición para pasar al siguiente tramo no la decide una sensación: se fija de antemano, con un umbral numérico, antes de que el despliegue empiece.
Kill switch, el feature flag que frena un fallo
Revertir un despliegue tradicional implica volver a desplegar la versión anterior: minutos de proceso, a veces con caída de servicio. Revertir un feature flag es cambiar un valor en un panel: el siguiente usuario que entra ya ve la versión estable, sin reinicio y sin que el equipo de guardia tenga que tocar el servidor.
El hash estable que decide quién ve la función
Para que un mismo usuario no vea la función encendida en una visita y apagada en la siguiente, el sistema no elige al azar en cada petición: calcula un hash estable a partir de su identificador, de sesión, de cuenta o de cookie, y lo compara contra el porcentaje activo del flag. Quien cae dentro del tramo ve la nueva versión en todas sus visitas mientras dure la prueba; quien queda fuera, no la ve hasta que el flag suba de tramo. Es el mismo mecanismo que sostiene un test A/B bien hecho, y por eso los equipos de producto y marketing acaban usando la misma infraestructura para las dos cosas.
Los informes State of DevOps de DORA, el grupo de investigación de Google Cloud, sitúan la tasa de cambios fallidos de los equipos con mejor desempeño por debajo del 15%, frente al 46-60% de los equipos con peor desempeño; separar el despliegue del lanzamiento, que es exactamente lo que hace un flag, es una de las prácticas que distingue a un grupo del otro.
¿Te ayudamos con esto?
Cuéntanos tu caso
Si esto te afecta, escríbenos en dos líneas y te respondemos por email con una valoración concreta.
Tipos de banderas según el problema que resuelven
No todas las banderas duran lo mismo ni resuelven lo mismo. Fowler distingue cuatro categorías según cuánto tiempo viven en el código y quién las controla:
- De lanzamiento: ocultan una función a medio terminar mientras el equipo la integra poco a poco; se retiran en días o semanas, en cuanto el lanzamiento se completa.
- De experimento: reparten el tráfico entre dos versiones para medir cuál convierte más; viven mientras dure la prueba estadística.
- Operativas, o kill switches: apagan una integración o un módulo pesado bajo carga alta; permanecen en el código de forma indefinida, como un fusible.
- De permiso: activan una función solo para un plan de pago o un cliente concreto; viven tanto como viva ese plan.
Confundir una bandera de lanzamiento con una operativa es el error más común: la primera se olvida en el código semanas después de cumplir su función, y ese olvido es exactamente lo que trata el siguiente apartado.
Gestión de flags en WordPress y a medida
Un proyecto a medida en Laravel o en un backend propio suele montar su propio sistema de flags, o apoyarse en un servicio como Azure App Configuration, que separa la bandera del código y permite cambiarla sin tocar el repositorio. En un desarrollo de software a medida esa separación suele decidirse desde el primer sprint, no se añade después.
En WordPress el patrón es más artesanal: un plugin propio, una opción en el panel de administración o, en los casos más simples, una constante en el archivo de configuración que se cambia por SSH, algo que conviene dejar documentado como parte del mantenimiento de WordPress habitual. Sirve igual para un catálogo industrial que necesita probar una ficha de producto nueva en el 10% de las visitas antes de tocar las dos mil fichas restantes.
La deuda técnica que deja un flag olvidado
Cada bandera que queda activa al 100% y nunca se borra del código es una rama que ya no decide nada pero que el siguiente desarrollador tiene que leer, entender y descartar para asegurarse de que no afecta a nada más. Con diez o veinte flags acumulados en un par de años, cualquier cambio exige comprobar combinaciones que nadie necesita ya. La práctica que evita esto es simple y casi nunca se aplica sola: poner fecha de caducidad a cada flag de lanzamiento desde el día en que se crea, y revisar esa lista en cada auditoría técnica en lugar de dejarla para cuando ya molesta.
Proyectos pequeños donde un flag no compensa
No toda web necesita un sistema de flags. Una landing de una sola página, un sitio de cinco secciones que apenas cambia o un comercio de barrio con un catálogo de veinte productos ganan poco montando infraestructura para algo que pueden probar con un despliegue en horario de poco tráfico y revisando a mano. La complejidad de gestionar flags, documentarlos, fijarles caducidad, revisarlos, solo se paga cuando hay cambios frecuentes y una base de usuarios lo bastante grande para que un fallo pase inadvertido en el 5% antes de llegar al 100%.
Donde sí compensa casi siempre es en proyectos con tráfico constante y equipo técnico propio: el distrito 22@ de Barcelona concentra buena parte de las scale-ups y empresas de producto digital de la ciudad, y es ahí donde un despliegue mal medido cuesta más caro, no por el tamaño de la empresa sino por el volumen de usuarios que lo notan a la vez.
Preguntas frecuentes sobre feature flags
¿En qué se diferencia un feature flag de un test A/B?
El flag es el mecanismo; el test A/B es un uso concreto de ese mecanismo. Un feature flag puede activar una función para el 100% sin medir nada, mientras que un test A/B siempre reparte tráfico entre dos versiones y compara resultados antes de decidir cuál se queda.
¿Hace falta pagar una herramienta para usar feature flags?
No para empezar. Una tabla en la base de datos con el nombre del flag y el porcentaje activo, consultada en cada petición, resuelve los primeros casos. Un servicio de pago aporta auditoría, caducidad automática y paneles sin tocar código, y se justifica cuando hay varios equipos tocando flags a la vez.
¿Cuánto se tarda en montar un primer sistema de banderas?
Una versión mínima, una tabla, una consulta y una condición en el código, se monta en menos de un día de desarrollo. Lo que lleva más tiempo es decidir qué métricas definen que un despliegue va bien, y esa conversación conviene tenerla antes del primer lanzamiento, no durante.
