Manual de combate para introducir cambios sin romperlo todo

Publicado el 19 de mayo de 2026  •  12 minutos  • 2489 palabras

No toques nada en viernes.

En muchas empresas esa frase no está escrita en ningún sitio, pero aparece sola en la cabeza de cualquiera que haya vivido un despliegue salir mal.

Y alrededor de ese miedo se han ido construyendo capas, entornos, reuniones, aprobaciones… todo para evitar salir en la portada de “Producción caído otra vez” el lunes a las 9:01.

El problema es que el negocio no entiende de supersticiones. Quiere cambios. Quiere nuevas funcionalidades, nuevos flujos, nuevas integraciones, correcciones, mejoras de rendimiento. Quiere que la aplicación se mueva.

Y tú estás en medio, intentando hacer malabares: cambiar cosas sin romperlo todo.

Este artículo pretende ser ese manual que faltaba para no romperlo todo.

No es teoría abstracta, sino un recorrido por herramientas y patrones que existen precisamente para que puedas tocar producción sin necesidad de incienso y sacrificios a tu entidad divina favorita: feature flags, canary releases , blue/green, strangler pattern , refactors seguros y esos circuitos de aprobación en CI/CD que, bien usados, salvan carreras.

De “big bang” a “vamos por partes, por favor”

Hubo una época, no muy lejana, en la que la estrategia de cambio por defecto era el big bang: reescribir el sistema o la pieza entera, hacer un gran corte en una fecha concreta y cruzar los dedos.

El patrón era siempre el mismo: meses de trabajo en paralelo, ambiente de guerra en la semana del despliegue, freeze total, y un “día D” que, si salía mal, dejaba a medio mundo corriendo como un pollo sin cabeza para intentar hacer un rollback de emergencia.

Martin Fowler lo resumió con mucha calma: un “reescribe todo desde cero” tiene una probabilidad peligrosamente alta de fracasar. Su alternativa fue el famoso Strangler Fig Pattern .

La metáfora es bonita y cruel a la vez: igual que la higuera estranguladora crece alrededor de un árbol hasta reemplazarlo, la idea es ir construyendo el sistema nuevo alrededor del viejo, pieza a pieza, redirigiendo poco a poco el tráfico hasta que lo antiguo puede “morir” en paz.

Hoy, hay guías modernas de modernización que te cuentan este mismo principio aplicado al código: crear una capa de enrutado o fachada, colgar ahí el comportamiento nuevo, redirigir solo una parte del tráfico, observar, ajustar… y repetir.

Nada de todo-o-nada: micro-cortes, caminos alternativos, capacidad de dar marcha atrás sin incendiarlo todo.

Ese es el espíritu de este manual: cambios pequeños, reversibles y observables, en vez de heroísmos puntuales.

Feature flags: el interruptor de la vergüenza (y del control)

Los feature flags han cambiado la forma de desplegar más que casi cualquier otra herramienta.

Antes, “sacar una feature” era sinónimo de desplegar código nuevo. Ahora, en muchos equipos, el código se despliega antes de estar activo, y se enciende o apaga con una bandera.

La gracia de un flag es que separa dos momentos: el de lanzar código a producción y el de exponer comportamiento a usuarios. Puedes tener la nueva lógica desplegada, probada con tráfico interno, quizás activada solo para un porcentaje minúsculo de usuarios… sin necesidad de sacar una versión nueva cada vez que ajustas algo.

Los buenos artículos sobre flags insisten en que la clave no es solo usarlos, sino usarlos en el sitio correcto.

Un ejemplo clásico: cuando estás reemplazando un componente grande, en lugar de llenar el interior de if (flag) y ramificar toda la implementación, pones el flag justo en la entrada y decides ahí si llamas al código nuevo o al viejo. Eso hace que, cuando termines la migración, puedas borrar el flag y todo el código antiguo de un plumazo, en vez de vivir con condicionales zombie durante años.

El reverso tenebroso (de la fuerza) es fácil de imaginar: si no gestionas bien la vida y muerte de los flags, tu base de código se convierte en una excavación arqueológica. Los feature flags mal cuidados pueden hacer el mantenimiento más duro, no más fácil. Pero usados con disciplina (banderas con fecha de caducidad, limpieza regular, nombres claros) son uno de los mejores seguros de vida para introducir cambios sin quemarte.

Canary y blue/green: probar con gente real… pero pocas

Si los feature flags controlan qué se ejecuta, los despliegues canary y blue/green controlan dónde y para quién. Son primos cercanos, con personalidades diferentes, pero con una idea en común: nunca más eso de “o el 100% de los usuarios o ninguno”.

Un canary release es la aplicación literal de la expresión “mandemos primero al canario a la mina”. Despliegas la nueva versión en una fracción pequeña de instancias o tráfico (un 1%, un 5%) y miras qué pasa: errores, latencias, métricas de negocio. Si todo va bien, amplías; si va mal, vuelves atrás sin haber roto el mundo.

Herramientas como Flagger o Argo Rollouts automatizan este baile: despliegan, redirigen un poquito de tráfico, monitorizan métricas (tasa de error, tiempo de respuesta, etc.), pausan o revierten si los números se tuercen, y solo promueven la versión nueva si ha sobrevivido a ese pequeño infierno controlado. Es como tener un robot paranoico mirando el dashboard por ti.

El enfoque blue/green es otra variante: tienes dos entornos idénticos, uno sirve tráfico (blue), otro está en la sombra (green). Despliegas la nueva versión en green, haces tus pruebas ahí, y cuando te convence, cambias el puntero (DNS, load balancer) para que todo el mundo vaya a green. Si algo se rompe, vuelves a blue, que sigue intacto.

Ambas estrategias comparten una idea que FinOps y SRE repiten mucho: el riesgo se baja reduciendo el radio de explosión.

No es lo mismo descubrir un bug en un canary al 5% que descubrirlo cuando toda tu base de usuarios ya está gritando en internet.

Strangler pattern y refactors seguros: matar al legacy sin hacer un remake cutre

En relatos de migración sin sobresaltos, un patrón aparece una y otra vez: el de la higuera estranguladora. AWS , Azure , blogs de arquitectura… todos tienen ya su versión del Strangler Fig Pattern, y es que la alternativa de “reescribir y rezar” ha salido mal demasiadas veces .

El enfoque es deliberadamente aburrido: pones una capa de routing delante del sistema legacy (un API gateway, un reverse proxy, una pieza de código), y ahí decides qué rutas siguen yendo al código viejo y cuáles empiezan a ir al nuevo.

Refactorizas o reimplementas un trocito: el módulo de pedidos, el de facturación, la generación de informes. Lo cuelgas del nuevo sistema, rediriges solo esas peticiones, comparas resultados con shadow traffic, mides… y solo cuando estás seguro, dejas de llamar al viejo.

En la práctica: cada paso es pequeño, reversible y local. Si algo falla, reenvías las peticiones al monolito antiguo y vuelves a pensar. No hay un “día del juicio final”, hay una secuencia de pequeños juicios parciales. Y si un día decides parar la modernización porque el negocio ha cambiado prioridades, puedes hacerlo sin quedarte a medias con un engendro inusable.

El mismo principio vale para refactors internos sin cambiar de arquitectura. La gente que habla de zero-downtime refactoring suele recomendar patrones parecidos: introducir primero nuevos modelos de datos en paralelo, escribir dos caminos de lectura/escritura temporalmente, usar dual writes para validar el comportamiento y, solo cuando los números encajan, apagar el camino viejo.

Es más trabajo que “cambiar un par de cosas y esperar”, pero también mucho menos emocionante en producción.

Aburrido y predecible: exactamente lo que buscas.

CI/CD con cerebro: gates, approvals y evitar el “ship crap”

Todos queremos desplegar rápido. Nadie quiere desplegar basura.

Entre esos dos polos vive la tensión permanente de los circuitos de aprobación en CI/CD : si son demasiado laxos, la gente habla de “ship crap”; si son demasiado rígidos, el sistema se llena de colas de PRs y el equipo pierde el apetito por cambiar nada.

Las guías modernas de CI/CD piden distinguir entre dos capas: las puertas automáticas y las aprobaciones humanas.

Las puertas automáticas son todo lo que una máquina puede verificar sin opinar: tests, linters, análisis estático, escáneres de seguridad, checks de política como código (que no haya secretos en el repo, que los recursos de infra cumplan ciertas reglas, etc.).

Si alguno de esos checks falla, el cambio ni siquiera debería entrar en discusión: no se despliega, punto. Es el “no pasas” objetivo, sin debates. Es lo que artículos sobre mejores prácticas de pipelines llaman gates siempre activos: nadie tiene que acordarse, el sistema simplemente no avanza si no se cumple la higiene mínima.

Sobre esa base, sí tiene sentido añadir aprobaciones humanas donde aportan algo: diseño de la solución, impacto en negocio, revisión de cambios críticos. Ahí entran los responsables de módulo , las revisiones de alguien senior en módulos delicados, o una aprobación manual antes de desplegar a producción en entornos regulados.

Lo importante es que estas aprobaciones no se conviertan en una cadena infinita de firmas. Escalar, limitar quién tiene que decir que sí, automatizar notificaciones y tener vías de excepción para hotfixes es clave para que el proceso no mate la velocidad.

Bien planteados, estos circuitos no son burocracia: son una forma de asegurarte de que lo que se rompe en producción nunca es lo que una máquina ya podía haber detectado antes.

Shadow IT, experimentos y cómo no reventar lo viejo al probar lo nuevo

Por último, está el territorio gris de lo que a veces llamamos shadow IT: cosas nuevas que entran por la puerta de atrás.

Ese script que alguien monta en su cuenta personal de cloud “solo para probar”, esa herramienta SaaS a la que se le empiezan a subir datos porque resuelve un problema puntual, ese microservicio paralelo que un equipo lanza para esquivar cuellos de botella del sistema oficial.

Una parte de la innovación nace justo ahí, en esas pequeñas pruebas.

La pesadilla empieza cuando esos experimentos se cruzan sin control con el sistema existente: dobles fuentes de verdad, integraciones frágiles, flujos que nadie sabe ya si pasan por la vía oficial o por el atajo que alguien montó un viernes .

Patrones como el estrangulador, los canaries y las feature flags ofrecen un camino menos suicida: puedes montar cosas nuevas en paralelo, usando shadow traffic para compararlas con el comportamiento existente, sin cortar directamente el cable del sistema original. Puedes dirigir solo un subconjunto de usuarios (equipos internos, probadores beta, clientes muy pacientes) a la ruta nueva, mientras el resto sigue usando lo conocido.

La diferencia entre shadow IT peligroso y experimentación sana suele estar en tres cosas: visibilidad, reversibilidad y límites claros. Si todo el mundo sabe que cierto flujo es experimental, si hay un interruptor para volver al camino viejo, y si se ha pensado un mínimo en cómo convive con el resto del sistema, estás innovando con red de seguridad.

Si, en cambio, un día descubres que tu facturación depende de una lambda escrita por alguien que ya no está, en una cuenta de AWS sin tags ni monitorización, entonces no estabas haciendo cambios sin romperlo todo: estabas jugando a la ruleta rusa con un cluster.

En el fondo, este manual no va de patrones aislados, sino de una mentalidad: los cambios no son eventos, son una corriente continua, y la única forma de sobrevivir sin vivir en modo “no deploy on Fridays” es diseñar con esa corriente en mente.

Feature flags para decidir qué se enciende, canaries y blue/green para decidir a quién se lo enseñas, strangler pattern para migrar sin incidentes , refactors con red, y pipelines que paren lo que no está listo sin necesidad de héroes improvisados.

Con eso, introducir cambios sin romperlo todo deja de ser cuestión de suerte y se parece más a lo que debería haber sido siempre: un oficio.

Menos épico, menos batallitas que contar… y, curiosamente, mucho más compatible con dormir bien.

Glosario rápido

El vocabulario de estos patrones se presta a confusión. Aquí, ordenado.

• Feature flag: mecanismo que permite activar o desactivar funcionalidad en producción sin necesidad de desplegar código nuevo. Separa el momento de lanzar código del momento de exponerlo a usuarios.
• Canary release: estrategia de despliegue que dirige solo una fracción del tráfico real (1%, 5%…) a la nueva versión antes de promocionarla al 100%. Si algo falla, el impacto es mínimo.
• Blue/green deployment: técnica que mantiene dos entornos idénticos (blue activo, green en preparación). El cambio de versión es un simple cambio de puntero; si algo va mal, se vuelve al entorno anterior sin tocar nada.
• Strangler Fig Pattern: patrón de modernización que consiste en construir el sistema nuevo alrededor del viejo, redirigiendo tráfico pieza a pieza hasta que el sistema original puede retirarse. Nombre tomado de la higuera estranguladora, que crece alrededor de un árbol hasta reemplazarlo.
• Shadow traffic: técnica que duplica peticiones reales hacia el sistema nuevo sin afectar a los usuarios, para comparar el comportamiento del código nuevo con el existente antes de activarlo oficialmente.
• Blast radius: término de SRE que describe el alcance máximo de un fallo: cuántos usuarios, servicios o datos se ven afectados si algo sale mal. Reducir el blast radius es el objetivo de canaries y despliegues graduales.
• Zero-downtime refactoring: conjunto de técnicas para refactorizar sistemas sin interrumpir el servicio, usando escrituras duales, migraciones paralelas y apagado progresivo del camino antiguo en lugar de cortes bruscos.

Fuentes y referencias

Todo lo que está aquí ya lo han aprendido otros a costa de sangre, sudor y errores en producción. Aprovéchalo antes de que te toque a ti.

• Strangler Fig Pattern en la práctica - GoCodeo. Cómo aplicar el patrón para refactorizar de forma segura y gradual.
• Deployment Strategies con Flagger - Flagger Docs. Canary, blue/green y A/B testing automatizados con Kubernetes.
• CI/CD Best Practices: Branching, Approvals, Rollouts - Skywork AI. Guía sobre puertas de calidad, aprobaciones y estrategias de despliegue en pipelines modernos.
• Strangler Fig Pattern - Microsoft Azure Architecture Center. Descripción oficial del patrón con diagramas y casos de uso.
• StranglerFigApplication - Martin Fowler. El artículo original donde Fowler acuña el patrón y explica la metáfora de la higuera estranguladora.
• Strangler Pattern - MaibornWolff. Perspectiva de consultoría sobre cuándo y cómo aplicar el patrón.
• Strangler Fig en AWS - AWS Prescriptive Guidance. Guía de AWS para descomponer monolitos usando el patrón.
• Strangler Pattern for Safe Microservices Transition - CircleCI Blog. Implementación del patrón en transiciones a microservicios.
• Why Your Feature Flags Are Making Code Maintenance Harder - Algocademy. Los riesgos de los feature flags mal gestionados y cómo evitarlos.
• Migrating from Microservices to Monolith with Strangler Fig - SoftwareSeni. El patrón aplicado en dirección inversa: de microservicios a monolito.
• Zero-Downtime Refactoring - In-Com. Técnicas para refactorizar sistemas sin interrupción de servicio.
• Refactoring Legacy Code with the Strangler Fig (Reddit) - r/programming. Discusión comunitaria con experiencias reales aplicando el patrón.
• CI/CD Pipeline Best Practices - Group107. Prácticas recomendadas para pipelines robustos con gates y aprobaciones.
• CI/CD con Jenkins y DevOps - LinkedIn/Krishnamoorthi. Code owners y aprobaciones en pipelines de CI/CD.
• Strangler Architecture Pattern for Modernization - vFunction. El patrón como estrategia central de modernización de aplicaciones legacy.