Feature flags y progressive delivery: desplegar sin miedo

El despliegue de software tiene un problema fundamental: cuanto más grande es el cambio, más riesgo conlleva. Y cuanto más miedo tiene el equipo al riesgo, menos frecuentemente despliega. Y cuanto menos frecuentemente despliega, más grandes son los cambios cuando llegan. Es un ciclo que se retroalimenta y termina con equipos que despliegan una vez al mes con miedo, en lugar de diez veces al día con confianza.

Los feature flags rompen este ciclo. Permiten separar el despliegue del código de la activación de funcionalidades. Puedes desplegar código a producción sin que los usuarios lo vean, activarlo gradualmente para un porcentaje de usuarios, y revertirlo instantáneamente si algo falla. Sin rollbacks, sin hotfixes de emergencia, sin noches en vela.

Este artículo explica cómo funcionan los feature flags, cómo implementar progressive delivery de forma práctica y qué errores evitar para que no se conviertan en una fuente nueva de complejidad.

Qué son los feature flags (y qué no son)

La definición simple

Un feature flag es una condición en tu código que determina si una funcionalidad está activa o no. En su forma más básica es un condicional:

if (featureEnabled("new-checkout")) {
  showNewCheckout();
} else {
  showOldCheckout();
}

La diferencia con un condicional normal es que el valor de ese flag se controla externamente: desde un panel de administración, un servicio de configuración o una herramienta de feature management. No necesitas desplegar código nuevo para activar o desactivar una funcionalidad.

Qué no son los feature flags

No son un sustituto del testing. Los feature flags te permiten controlar el riesgo del despliegue, no la calidad del código. Si despliegas código con bugs detrás de un flag, el bug sigue ahí. Solo es invisible hasta que activas el flag.

No son configuración permanente. Un feature flag tiene un ciclo de vida. Nace cuando desarrollas una funcionalidad, vive mientras la lanzas gradualmente y debe morir cuando la funcionalidad está completamente desplegada. Los flags que nunca se eliminan se convierten en deuda técnica.

No son permisos de usuario. Aunque puedes usar flags para controlar quién ve qué, los feature flags no sustituyen un sistema de permisos robusto. Son mecanismos temporales de control de despliegue, no de autorización.

Los cuatro tipos de feature flags

No todos los flags son iguales. Entender las diferencias te ayuda a gestionarlos correctamente.

1. Release flags (flags de lanzamiento)

Propósito: separar el despliegue del código de la activación de la funcionalidad.

Ciclo de vida: días a semanas. Deben eliminarse cuando la funcionalidad está completamente activa.

Ejemplo: has desarrollado un nuevo flujo de onboarding. Lo despliegas a producción detrás de un flag. Lo activas primero para el 5% de nuevos usuarios. Si las métricas son buenas, lo subes al 25%, luego al 50%, luego al 100%. Cuando está al 100%, eliminas el flag y el código antiguo.

2. Experiment flags (flags de experimentación)

Propósito: A/B testing y experimentación controlada.

Ciclo de vida: semanas a meses. Deben eliminarse cuando el experimento concluye.

Ejemplo: quieres probar si un botón rojo convierte mejor que uno azul. Creas un flag que asigna aleatoriamente a los usuarios al grupo A (rojo) o grupo B (azul). Después de recoger datos suficientes, analizas los resultados y eliminas el flag.

3. Ops flags (flags operacionales)

Propósito: controlar el comportamiento del sistema en producción sin desplegar código.

Ciclo de vida: variable. Algunos son permanentes.

Ejemplo: un flag que desactiva la integración con un servicio externo cuando ese servicio tiene problemas. En lugar de que tu aplicación falle, degradas la funcionalidad de forma controlada. Otro ejemplo: un flag que limita el número de peticiones a una API costosa cuando el tráfico es anormalmente alto.

4. Permission flags (flags de permisos)

Propósito: dar acceso a funcionalidades específicas a segmentos de usuarios.

Ciclo de vida: largo, a veces permanente.

Ejemplo: funcionalidades premium disponibles solo para usuarios de pago, o acceso anticipado a features para beta testers.

Progressive delivery: el framework completo

Los feature flags son una herramienta. Progressive delivery es la estrategia que les da sentido. Progressive delivery consiste en desplegar funcionalidades de forma gradual, medida y reversible.

Los cinco niveles de progressive delivery

Nivel 1: dark launches (lanzamientos oscuros)

Despliegas el código a producción pero ningún usuario lo ve. El código existe, se ejecuta en el backend, pero la interfaz no cambia. Esto te permite validar que el nuevo código funciona correctamente en producción sin impacto en los usuarios.

Nivel 2: canary releases (lanzamientos canario)

Activas la funcionalidad para un porcentaje muy pequeño de usuarios (1-5%). Monitorizas métricas clave: tasa de error, latencia, conversión. Si todo está bien, avanzas al siguiente nivel. Si algo falla, reviertes instantáneamente.

Nivel 3: staged rollout (despliegue por fases)

Aumentas gradualmente el porcentaje: 10%, 25%, 50%, 75%, 100%. En cada fase monitorizas y decides si avanzar, pausar o revertir.

Nivel 4: ring-based deployment

En lugar de porcentajes aleatorios, despliegas por “anillos” de usuarios: primero el equipo interno, luego beta testers, luego early adopters, luego todos los usuarios. Cada anillo valida la funcionalidad antes de avanzar al siguiente.

Nivel 5: feature experimentation

El nivel más sofisticado. Cada despliegue es un experimento con hipótesis, métricas de éxito y análisis estadístico. No solo despliegas funcionalidades; mides su impacto con rigor científico.

Métricas de guardia (guardrail metrics)

Las guardrail metrics son métricas que monitorizas durante un despliegue progresivo para detectar problemas antes de que afecten a muchos usuarios.

Métricas técnicas:

• Tasa de errores (5xx, excepciones no capturadas)
• Latencia p50, p95 y p99
• Uso de CPU y memoria
• Tasa de timeouts en servicios dependientes

Métricas de negocio:

• Tasa de conversión
• Revenue por usuario
• Tasa de retención a corto plazo
• NPS o CSAT

Métricas de experiencia de usuario:

• Core Web Vitals (LCP, FID, CLS)
• Tasa de completación de flujos críticos
• Tasa de abandono en pasos clave

La regla es simple: si cualquier guardrail metric se degrada significativamente durante el rollout, pausas o reviertes. No esperas a que un cliente se queje. No esperas a que el equipo de soporte reporte problemas. Las métricas te dicen antes que nadie.

Implementación práctica

Opción 1: flags simples con configuración

Para equipos pequeños que despliegan una o dos funcionalidades al mes, los feature flags simples basados en variables de entorno o ficheros de configuración pueden ser suficientes.

Ventajas: sin dependencias externas, sin coste, control total.

Limitaciones: no puedes segmentar por usuario, no tienes panel de gestión, los cambios requieren redespliegue.

Cuándo usarla: MVP con menos de 10.000 usuarios y un equipo de menos de 5 desarrolladores.

Opción 2: herramientas open source

Para equipos que necesitan segmentación por usuario, porcentajes de rollout y un panel de gestión sin pagar licencias.

Herramientas principales:

• Unleash: open source maduro, auto-hospedado, con SDKs para los lenguajes principales
• Flagsmith: open source con opción cloud, API-first, buen panel de gestión
• GrowthBook: open source especializado en experimentación y A/B testing

Ventajas: control total de los datos, sin costes de licencia, personalizable.

Limitaciones: requiere infraestructura propia, mantenimiento del equipo.

Opción 3: plataformas comerciales

Para equipos que necesitan funcionalidades avanzadas sin gestionar infraestructura.

Herramientas principales:

• LaunchDarkly: líder del mercado, integración profunda con herramientas de desarrollo
• Split.io: enfocado en experimentación y métricas de impacto
• Statsig: combina feature flags con análisis estadístico automatizado

Ventajas: funcionalidades avanzadas, escalabilidad garantizada, soporte.

Limitaciones: coste mensual significativo (desde 500 a varios miles de euros al mes), dependencia del proveedor.

Buenas prácticas de implementación

Nombrado consistente. Usa una convención clara para nombrar flags: [equipo]-[funcionalidad]-[tipo]. Ejemplo: checkout-new-payment-flow-release. Esto facilita la búsqueda y el mantenimiento.

Propietario de cada flag. Cada flag debe tener un propietario responsable de su ciclo de vida. Cuando el propietario cambia de equipo o deja la empresa, el flag queda huérfano y se convierte en deuda técnica.

Fecha de expiración. Cada flag (excepto los operacionales permanentes) debe tener una fecha de expiración prevista. Si pasa esa fecha y el flag sigue activo, es una señal de que algo fallo en el proceso.

Valores por defecto seguros. Si el sistema de feature flags falla (y fallará), el valor por defecto del flag debe ser el comportamiento seguro. Normalmente, el valor por defecto es “desactivado” para flags de release y “control” para flags de experimentación.

Errores comunes y cómo evitarlos

Error 1: flags que nunca se eliminan

Es el error más común y el más costoso a largo plazo. Cada flag que permanece en el código después de cumplir su propósito añade complejidad. Dos flags crean 4 estados posibles. Diez flags crean 1.024 estados posibles. Ningún equipo puede testear 1.024 combinaciones.

Solución: establece una política de limpieza. Cada flag de release debe eliminarse dentro de las dos semanas siguientes a alcanzar el 100% de rollout. Añade alertas automáticas cuando un flag supera su fecha de expiración.

Error 2: flags demasiado granulares

Poner un flag en cada línea de código no es progressive delivery. Es caos. Los flags deben encapsular funcionalidades completas o cambios coherentes, no fragmentos de código.

Solución: un flag por funcionalidad visible para el usuario, no un flag por componente técnico.

Error 3: no monitorizar durante el rollout

Desplegar al 5% y pasar directamente al 100% sin mirar métricas anula el propósito del progressive delivery. Si no monitorizas, estás haciendo un despliegue normal con pasos extra.

Solución: define guardrail metrics antes del rollout. Automatiza alertas. No avances al siguiente porcentaje hasta que las métricas confirmen que todo está bien.

Error 4: testing insuficiente de combinaciones de flags

Si tienes 5 flags activos simultáneamente, necesitas considerar las interacciones entre ellos. El flag A puede funcionar perfectamente solo. El flag B también. Pero activar A y B juntos puede producir un comportamiento inesperado.

Solución: minimiza el número de flags activos simultáneamente. Cuando necesites varios flags activos, testea las combinaciones más probables.

Error 5: usar flags como excusa para no hacer testing

“No necesitamos testear a fondo porque tenemos flags y podemos revertir.” Esta mentalidad convierte la producción en un entorno de testing. Los flags reducen el riesgo del despliegue, no el riesgo de bugs.

Solución: mantén tus estándares de testing. Los flags son una red de seguridad, no un sustituto de la calidad.

Feature flags y equipos de producto

Cómo los flags cambian la relación entre producto y desarrollo

Sin feature flags, el equipo de producto pregunta “cuándo estará listo?” y el equipo de desarrollo responde con una fecha que depende de múltiples variables incontrolables. Con feature flags, la conversación cambia:

Sin flags: “La funcionalidad estará lista el 15 de marzo. Ese día la lanzamos a todos los usuarios.”

Con flags: “El código estará desplegado esta semana. Cuándo y para quién lo activamos es una decisión de producto que podemos tomar de forma independiente.”

Esta separación es transformadora. El equipo de desarrollo puede desplegar con su cadencia natural sin esperar a que producto “apruebe” el lanzamiento. El equipo de producto puede controlar la activación según la estrategia de negocio sin depender de un despliegue técnico.

Casos de uso para product managers

Lanzamiento coordinado con marketing. El código está desplegado y listo. Marketing prepara la campaña. Cuando todo está alineado, el product manager activa el flag. Sin coordinación con el equipo de desarrollo el día del lanzamiento.

Beta cerrada con usuarios seleccionados. Activas la funcionalidad solo para un segmento de usuarios: los más comprometidos, los que más necesitan la funcionalidad o los que han expresado interés. Recoges feedback antes del lanzamiento general.

Kill switch para emergencias. Si una funcionalidad genera problemas inesperados (soporte desbordado, quejas de usuarios, impacto en el rendimiento), el product manager puede desactivarla inmediatamente sin necesitar al equipo de desarrollo.

Implementar progressive delivery paso a paso

Paso 1: elige la herramienta adecuada

Para la mayoría de equipos que empiezan, una herramienta open source como Unleash o Flagsmith es suficiente. Si tu equipo tiene menos de 5 desarrolladores y despliega menos de 5 funcionalidades al mes, incluso las variables de entorno pueden servir temporalmente.

Paso 2: empieza con un flag de release simple

No intentes implementar progressive delivery completo desde el primer día. Empieza con un caso simple: la próxima funcionalidad que vayas a lanzar, ponla detrás de un flag. Despliega el código. Activa el flag para el equipo interno. Luego para un 10% de usuarios. Luego para el 100%.

Paso 3: define tus guardrail metrics

Antes del primer rollout real, define qué métricas monitorizarás y qué umbrales indican un problema. Configura alertas automáticas para esos umbrales.

Paso 4: establece el proceso de rollout

Documenta los pasos del rollout: quién decide avanzar, qué métricas se revisan, cuánto tiempo se espera en cada porcentaje, quién puede revertir y bajo qué condiciones.

Paso 5: implementa la limpieza de flags

Desde el primer flag, establece el proceso de eliminación. Quién elimina el flag? Cuándo? Cómo se rastrea que se ha eliminado correctamente?

Paso 6: escala gradualmente

Una vez que el proceso funciona para flags de release, expande a experimentación. Luego a flags operacionales. Cada tipo introduce complejidad adicional que debes gestionar conscientemente.

Métricas de éxito de tu sistema de progressive delivery

Cómo sabes si el progressive delivery está funcionando? Estas métricas te lo dicen:

Frecuencia de despliegue. Cuántas veces despliegas a producción por semana? Los equipos con progressive delivery maduro despliegan diariamente o varias veces al día.

Lead time for changes. Cuánto tiempo pasa desde que un desarrollador hace commit hasta que el cambio está en producción? Con progressive delivery debe reducirse significativamente.

Change failure rate. Qué porcentaje de despliegues causa problemas en producción? Con progressive delivery y guardrail metrics, este porcentaje debería bajar.

Time to recovery. Si un despliegue causa problemas, cuánto tardas en revertirlo? Con feature flags, la reversión debería ser instantánea (segundos, no minutos u horas).

Número de flags activos. Cuántos flags están activos en un momento dado? Si el número crece sin control, tienes un problema de gestión. Para la mayoría de equipos, 10-20 flags activos es un rango saludable.

Conclusión

Los feature flags y el progressive delivery no son tecnologías sofisticadas reservadas para empresas grandes. Son prácticas que cualquier equipo puede adoptar de forma gradual, empezando con un simple flag de release y evolucionando hacia un sistema completo de despliegue progresivo.

La clave está en empezar simple, mantener disciplina en la limpieza de flags y monitorizar durante cada rollout. La mayoría de los equipos que fracasan con feature flags no fracasan por la tecnología. Fracasan porque acumulan flags sin eliminarlos, no monitorizan durante el rollout o usan los flags como excusa para no testear.

Empieza con un flag. Un rollout gradual. Unas métricas básicas. Y construye desde ahí. El objetivo no es tener el sistema de progressive delivery más sofisticado. Es desplegar con confianza y revertir con rapidez.

Necesitas ayuda para implementar progressive delivery en tu equipo?

En NERVICO ayudamos a equipos de producto a diseñar e implementar estrategias de despliegue progresivo adaptadas a su contexto. Desde la elección de herramientas hasta la definición de procesos, podemos ayudarte a desplegar con más frecuencia y menos riesgo.

Solicitar auditoría gratuita