Feature flags, canary releases y el arte de no romper producción (demasiado)

Publicado el 22 de junio de 2026  •  13 minutos  • 2576 palabras

En tu equipo seguramente hay alguna versión de “no desplegamos en viernes” o “nadie toca pagos en fin de mes”.

No salen en la guía interna, pero se respetan como si estuvieran talladas en piedra. No nacen de la teoría: nacen de noches largas, rollbacks heroicos y esa sensación de “nunca más” compartida en silencio por todo el equipo.

El problema es que el negocio no entiende de traumas. Quiere cambios, muchos y a menudo.

Tú quieres seguir teniendo trabajo (y vida), así que te toca cuadrar el círculo: mover producción todos los días sin convertir cada despliegue en un deporte de riesgo.

Y ahí entran dos de las mejores invenciones de los últimos años: las feature flags y los canary releases .

Separar “subir código” de “encenderlo”: la pequeña revolución de las feature flags

Antes, el flujo era sencillo y crudo: una nueva versión del código, un despliegue, y todo el mundo cruzando los dedos a la vez.

El día que alguien decidió separar cuándo subes el código de cuándo lo activas, cambió medio juego. Esa decisión tiene nombre: feature flag .

Una feature flag es un interruptor que vive en tu aplicación y decide si cierta funcionalidad se comporta de la forma vieja o de la forma nueva.

Lo importante no es solo el if, es lo que implica: puedes desplegar código apagado, probarlo internamente, encenderlo para un 1% de usuarios, para una región concreta, para empleados, para una prueba cerrada… sin volver a desplegar .

Los vendedores de plataformas de flags (que algo ganarán con que la adoptes) lo describen casi como un superpoder: despliegues continuos sin miedo, kill switch instantáneo si algo va mal, posibilidad de hacer A/B testing y experiments sin líos de ramas.

Y tienen razón… hasta cierto punto. Porque, como todo poder útil, las flags vienen con una gran responsabilidad, con riesgo incorporado .

En los artículos recientes de LaunchDarkly , Unleash , Flagsmith o PostHog hay páginas enteras dedicadas a los errores habituales que convierten un sistema de flags en un infierno.

El primero es casi poético, por lo patético, y por saltarse a la torera el “principio de responsabilidad única”: intentar que cada flag haga dos o tres cosas a la vez.

“Esta flag activa la nueva pantalla Y además el nuevo cálculo de precio Y de paso el experimento de checkout”. Si, al describir una flag, necesitas la palabra “y” estás sembrando el caos futuro.

Otro clásico es mezclar la lógica de negocio con la lógica de flags hasta que todo es un puré: condiciones anidadas, comprobaciones repetidas en cinco sitios, reglas de negocio escondidas en if (flagActive) repartidos por media base de código.

PostHog lo narra con pelos y señales: flags mal colocadas han causado interrupciones serias, montañas de deuda técnica y, en un caso famoso, casi arruinan una empresa porque nadie entendía ya en qué combinaciones de flags el sistema era estable.

Y las guías de buenas prácticas modernas insisten en cosas que suenan (y son) aburridas y que, precisamente por eso, funcionan: cada flag debería tener una única responsabilidad clara, vivir lo más en el borde posible (en el punto de entrada a un flujo, no en 20 sitios más abajo), y venir con un plan de retirada.

Unleash y otros lo llaman sin rodeos: las flags son deuda técnica con fecha de caducidad; si no las limpias cuando han cumplido su función, acabarán mordiéndote de vuelta.

La jugada, cuando se hace bien, es elegante: colocas la flag en la frontera (“uso el código de checkout viejo o el nuevo”), despliegas, pruebas, haces canary con un subconjunto de usuarios, recoges métricas… y cuando estás seguro, borras el flag y el camino viejo.

Lo que era una operación de corazón abierto se convierte en quitar un parche de código muerto.

Canary releases: mandar primero a los valientes

Si las feature flags deciden qué camino se ejecuta, los canary releases deciden a quién le enseñas cada versión.

La idea viene de esas historias de minas donde enviaban a un canario antes que a los mineros: si algo iba mal, lo descubrías con un impacto pequeño (tamaño canario). No es muy amable con el pájaro, pero en la práctica funciona estupendamente.

En un canary, en lugar de servir la versión nueva a todo el mundo de golpe, la sirves a una fracción pequeña del tráfico (un 1%, un 5%, a veces incluso a un puñado de usuarios internos) y observas.

Mirar no es solo “lanza y reza”: es integrar el canary con métricas y logs, hasta el punto de que muchas herramientas automatizan la decisión. Si los errores se disparan o la latencia se dispara por encima de un umbral, el sistema corta el experimento y vuelve a la versión anterior .

Son dos filosofías distintas para el mismo problema. Blue/green apuesta por la limpieza: tienes dos entornos completos (blue, el viejo; green, el nuevo) entre los que conmutas de forma instantánea, con rollback igual de rápido. El precio es que exige duplicar infraestructura y que, cuando cambias, cambias para todos a la vez.

El canary apuesta por lo contrario: reutiliza la misma infraestructura y juega con porcentajes: más lento, más granular, con capacidad de recoger datos reales sin arriesgar todo el parque de usuarios (comparativa canary vs. blue/green en Stack Overflow ).

Algunos proveedores lo han formalizado tanto que ya te dan hasta recetas de “canary por etapas”: primero 1%, luego 10%, luego 25%… con condiciones de ascenso automáticas basadas en tasa de errores y rendimiento. Lo que antes era un “vamos a ver qué pasa” se convierte en un experimento con criterios de salida, como los que ofrece Flagger .

Y aquí es donde las feature flags y los canaries se dan la mano de forma interesante: canary decide qué versión de la app ve un porcentaje de tu tráfico; el flag decide qué funcionalidad dentro de esa versión ve qué tipo de usuario. Un artículo de Unleash lo resume así: las flags llevan el canary del nivel de infraestructura al nivel de aplicación, permitiéndote hacer despliegues graduales finos por segmento, región o incluso usuario individual.

Cómo reducir riesgo sin matar la velocidad (y sin crear un infierno de flags)

El planteamiento es tentador: despliegues seguros, menos incidentes, poder experimentar sin miedo. Pero quienes mejor conocen estas herramientas —los que las venden y las operan día a día— llevan tiempo avisando de lo mismo: mal usadas, las flags y los canaries pueden hacer más daño que bien, como deja claro ConfigCat .

Y Flagsmith, ConfigCat, DevCycle y compañía coinciden en las mismas pesadillas. Las flags que nunca se borran convierten cada flujo en un árbol de Pascua de condiciones imposibles de testear.

Las que se usan para controlar reglas de negocio críticas o permisos, sin suficiente control ni auditoría, abren la puerta a incidentes de seguridad . Y las combinaciones explosivas que nadie ha probado juntas hacen que el número de posibles estados se dispare hasta que ya nadie sabe qué combinación es “la correcta”.

Lo más irónico es que casi sin excepción empezó con buena intención: “pongamos un par de flags para estar seguros”. Dos años después, el primer trabajo de cualquier desarrollador nuevo es descifrar qué conjunto de flags hace que el sistema se comporte “como se supone que debería”.

Las mejores prácticas modernas hablan mucho de gestión del ciclo de vida del flag: documentar para qué existe, quién la controla, cuándo debería desaparecer. También insisten en tener visibilidad sobre qué flags están activas en qué entornos, y en prohibir el reuso de flags antiguas para propósitos nuevos “porque ya estaban ahí”, según DevCycle .

Con los canary pasa algo similar: diseñar bien qué métricas vas a mirar antes de lanzar el canary marca la diferencia entre “hemos mitigado riesgo” y “hemos creado trabajo extra”. Si solo miras errores técnicos pero no estás atento, por ejemplo, a un desplome en cierta métrica de negocio (conversiones, abandono de carrito, etc.), puedes declarar victoria mientras los usuarios están huyendo discretamente.

La idea clave es que flags y canaries no sustituyen el criterio, lo amplifican.

Si el criterio es “esto lo saco como sea”, tendrás flags usadas como pegamento rápido y canaries que se usan una vez y nunca más. Si el objetivo es “quiero poder probar y revertir sin trauma”, se convierten en parte del lenguaje del equipo: “lo sacamos detrás de flag, empezamos con un canary al 5%, medimos y ya decide el dato”.

Ejemplos de uso bien planteado (y de los otros)

Hay casos públicos que son casi un manual. Empresas que hacen rollouts masivos de UI (modo oscuro, rediseños de flujos) suelen usar flags para desplegar el código completo días o semanas antes, activarlo primero para empleados, luego para una porción de usuarios beta, y, solo cuando han visto que no se hunde nada importante, para todo el mundo.

Si algo sale mal, el kill switch es inmediato: el flag se apaga, la UI vieja vuelve como si nada, y el equipo gana tiempo para arreglar el fallo sin carreras.

Hay historias más sonadas, como la que PostHog menciona de una empresa que casi se fue a pique por una combinación de flags mal gestionada: flags anidadas, lógica de negocio mezclada, nuevos cambios soportándose en flags que nadie recordaba, hasta que un despliegue aparentemente inocente desencadenó un comportamiento que nadie había previsto.

De ahí su cruzada personal contra los “flags multipropósito” y las bases de código donde los if (flag) actúan como goto con disfraz.

En el terreno de los canaries, muchos equipos cuentan cómo pasaron de “siempre da miedo desplegar” a “desplegamos varias veces al día” simplemente introduciendo un pequeño porcentaje inicial de tráfico y dando a SRE/producto 30 minutos para mirar los paneles antes de subir al 100%.

Algunas plataformas, como Flagger , incluso integran reglas automáticas: si la latencia o la tasa de errores superan cierto umbral, el canary se congela o se revierte sin que nadie tenga que estar pegado a la pantalla.

También hay usos dudosos: canaries que en la práctica siempre empiezan al 50%, se “monitorizan” mirando a ver si alguien grita, y se promueven por pura inercia; flags usadas como solución permanente para problemas de diseño (“si falla, que el usuario vuelva al flujo viejo”) hasta que nadie se atreve a tocar nada porque el mapa de caminos posibles es un infierno.

La diferencia entre un ejemplo que quieres copiar y uno que quieres evitar suele estar en dos palabras: intención y limpieza.

Si la intención es reducir riesgo y aprender, y luego limpias lo que ya no necesitas, las flags y los canaries se convierten en aliados.

Si la intención es ir más rápido a costa de dejar trampas detrás, terminarán explotando el viernes a las 18:00.

El arte (y la ética) de no romper producción “demasiado”

Nadie puede prometerte que nunca romperás producción. Ni las flags, ni los canaries, ni los blue/green, ni las modas técnicas del momento.

Lo que sí está en tu mano es mover el problema de “romper producción” desde “catástrofe global inevitable” a “incidente localizado, reversible y, con suerte, casi invisible para el usuario”.

Las feature flags te permiten encender y apagar comportamientos como quien sube y baja interruptores: si algo sale raro, puedes matar solo esa parte sin tirar un rollback entero.

Los canary releases te dejan probar en vivo con un pedacito de tu tráfico antes de comprometerte con el resto.

Juntos, bien usados, son una forma de humildad técnica: asumir que no lo vas a acertar todo a la primera y diseñar tu sistema como si eso fuera cierto.

Las mejores guías modernas sobre despliegue seguro no hablan tanto de heroísmo como de oficio: diseñar flags sencillas con vida limitada, canaries con métricas claras, pipelines que no dejen pasar cosas obvias, y equipos que entienden que la velocidad no es incompatible con la prudencia, como recogen las mejores guías de CI/CD .

En ese mundo, “no romper producción (demasiado)” deja de ser un chiste negro que cuentas en la cafetería y pasa a ser un objetivo razonable: sí, alguna vez fallará algo, pero fallará con control, con consciencia y, sobre todo, con un plan para apagar el flag, bajar el canary y volver al estado conocido sin que nadie tenga que sacrificar su fin de semana.

Y si, a pesar de todo, alguna vez la lías parda… siempre podrás consolarte pensando que al menos ya no lo haces con un git push origin main directo a todos los usuarios del planeta.

Eso también es progreso.

Glosario rápido

El vocabulario del despliegue seguro. Aquí, rápido.

• Feature flag: interruptor en el código que activa o desactiva una funcionalidad sin necesidad de desplegar. Permite separar el momento en que subes el código del momento en que lo enciendes.
• Canary release: estrategia de despliegue que expone la nueva versión a un porcentaje pequeño del tráfico antes de generalizarla. El nombre viene de los canarios que se usaban en las minas para detectar peligro antes que las personas.
• Blue/green deployment: técnica que mantiene dos entornos idénticos (uno activo, uno en espera) para poder cambiar entre versiones de forma instantánea y con rollback igual de rápido.
• Rollback: acción de revertir un despliegue a la versión anterior cuando algo sale mal. El equivalente técnico de deshacer.
• Kill switch: mecanismo para desactivar una funcionalidad de forma inmediata sin necesidad de desplegar código nuevo. Una feature flag bien colocada actúa de kill switch.
• A/B testing: experimento que muestra dos variantes a grupos distintos de usuarios para comparar resultados y decidir cuál funciona mejor.
• Deuda técnica: coste acumulado de decisiones rápidas tomadas sin pensar en el mantenimiento futuro. Las flags que nunca se limpian son deuda técnica con intereses.
• Pipeline de CI/CD: cadena automatizada de compilación, pruebas y despliegue que se ejecuta con cada cambio de código. Un buen pipeline detiene lo obvio antes de que llegue a producción.

Fuentes y referencias

Porque no todo el mundo tiene fe ciega en los if (flag) ajenos. Aquí van los interruptores que activaron estas ideas.

• LaunchDarkly - ¿Qué son las feature flags? - LaunchDarkly. Introducción oficial al concepto de feature flags.
• Unleash - Qué es un canary deployment - Unleash. Explicación detallada de canary releases.
• Feature flags: el secreto del canary testing seguro - FasterCapital. Relación entre flags y canary testing.
• Flagsmith - Trampas de las feature flags - Flagsmith. Errores habituales al usar feature flags.
• LaunchDarkly - Errores con feature flags - LaunchDarkly. Los mistakes más comunes en sistemas de flags.
• PostHog - Errores con feature flags - PostHog. Casos reales de flags mal gestionadas, incluyendo uno casi catastrófico.
• Unleash - Buenas prácticas con feature flags a escala - Unleash. Guía de ciclo de vida, responsabilidades y limpieza de flags.
• Octopus Deploy - Buenas prácticas con feature flags - Octopus Deploy. Seguridad, control y auditoría de flags.
• Unleash - Blue/green vs canary release - Unleash. Comparativa detallada entre ambas estrategias.
• Stack Overflow - Canary vs. blue/green - Stack Overflow. Discusión técnica con pros y contras de cada enfoque.
• Flagger - Deployment strategies - Flagger. Documentación sobre canary automatizado con métricas y criterios de promoción.
• ConfigCat - Riesgos de las feature flags - ConfigCat. Análisis de los peligros del abuso de flags.
• DevCycle - Lo que hay que hacer y lo que no con feature flags - DevCycle. Ciclo de vida de las flags: documentar, controlar y retirar.
• CI/CD best practices: branching, approvals y rollouts - Skywork AI. Guía de buenas prácticas de pipelines para despliegue seguro.