La sección de estrategias de despliegue en el examen AZ-400 pregunta: una vez que el código ha sido construido y probado, ¿cómo se entrega de forma segura a producción? Que el build y los tests pasen no significa que el trabajo haya terminado. Una estrategia de despliegue mal elegida puede exponer a miles de usuarios a errores de forma simultánea, o convertir una simple reversión en un trabajo de varias horas. Esta sección aborda cinco patrones para distribuir el riesgo, los Feature Flags que los controlan a nivel de código, y GitOps que gestiona la infraestructura de forma declarativa.
Como cambiar la temporada en una tienda de ropa — Blue-Green y Recreate
Algunas tiendas retiran toda la colección de invierno antes de poner la de primavera. Otras mantienen dos secciones abiertas al mismo tiempo y redirigen a los clientes a la nueva cuando está lista. El despliegue funciona como el primer caso. Primero apaga la versión antigua y luego levanta la nueva. Es el enfoque más sencillo, pero el servicio queda completamente fuera de línea durante la transición. Puede ser aceptable para herramientas internas con una ventana de mantenimiento, pero no es adecuado para sistemas de producción con usuarios externos.
El despliegue mantiene dos entornos idénticos en funcionamiento al mismo tiempo. Blue aloja la versión actualmente en producción, mientras que Green recibe la nueva versión. Cuando Green está listo, un balanceador de carga o una entrada DNS cambia el tráfico de forma atómica hacia Green. Si algo falla, se vuelve a Blue de inmediato. En Azure App Service, este patrón se implementa con y . Slot Swap completa las solicitudes de calentamiento antes de cambiar el tráfico, eliminando la latencia de arranque en frío en el momento de la transición.
El principal inconveniente es el costo de infraestructura. Mantener dos entornos en paralelo casi duplica los costos. Una solución intermedia práctica consiste en escalar el slot Green solo durante el período de prueba y reducir el slot Blue antiguo inmediatamente después de completar el swap.
Como abrir una llave de agua poco a poco — Canary y Rolling
Abrir una llave de agua de golpe puede generar una presión excesiva. Abrirla poco a poco permite detectar problemas con anticipación y cerrarla de inmediato si es necesario. El despliegue funciona de la misma manera. Envía solo una pequeña fracción del tráfico (por ejemplo, un 5%) a la nueva versión, luego monitorea las tasas de error y los tiempos de respuesta antes de aumentar gradualmente el porcentaje.
En Azure, se puede implementar Canary configurando porcentajes de tráfico en los Deployment Slots de App Service, o ajustando los pesos de Ingress en Azure Kubernetes Service (AKS). La clave está en conectar las alertas de Azure Monitor con condiciones automáticas de avanzar y revertir basadas en las métricas medidas.
El despliegue reemplaza las instancias de una en una, en secuencia. Como la versión antigua y la nueva funcionan de forma simultánea durante un período, la compatibilidad hacia atrás de la API es estrictamente obligatoria. En AKS, los parámetros y controlan el ritmo del despliegue.
| Patrón | Tiempo de inactividad | Costo de infraestructura | Velocidad de reversión | |--------|----------------------|--------------------------|------------------------| | Recreate | Sí | Bajo | Lenta | | Blue-Green | No | Alto | Inmediata | | Canary | No | Medio | Rápida | | Rolling | No | Bajo | Media |
!Comparación de 4 estrategias de despliegue
Como un ensayo clínico de un medicamento nuevo — Feature Flags y Progressive Delivery
Desplegar una nueva función no significa que todos los usuarios deban verla de inmediato. Los ensayos clínicos de medicamentos comienzan con un grupo pequeño de voluntarios y solo avanzan a la siguiente fase cuando los resultados son prometedores. Un controla si una función está activa o inactiva en tiempo de ejecución, aunque el código ya haya sido desplegado. Es la herramienta esencial para separar el despliegue del lanzamiento.
En Azure, se utiliza junto con la biblioteca . Los pares de clave-valor de los feature flags se almacenan en App Configuration, y la aplicación .NET, Java o Python se conecta a App Configuration usando Azure.Identity para leer los flags en tiempo de ejecución. Se pueden configurar condiciones basadas en IDs de usuario específicos, un porcentaje de usuarios, ubicación geográfica o cualquier atributo personalizado. Tanto si se usa GitHub Feature Flags como LaunchDarkly, el concepto subyacente es el mismo.
combina despliegues Canary, Feature Flags y observabilidad en un único enfoque. Se despliega el código con el flag desactivado y luego se abre gradualmente mientras se monitorean las métricas. Una vez completado un experimento, la limpieza del código de condición del flag debe formar parte del pipeline. Los flags que se acumulan con el tiempo añaden complejidad y dificultan el razonamiento sobre el código.
Como escribir una partitura para que la orquesta la siga — GitOps
Cuando un director escribe rápido y fuerte en la partitura, los músicos tocan en consecuencia sin necesidad de que se les indique cada nota individualmente. aplica la misma idea a los clústeres de Kubernetes. Se declara el estado deseado del clúster como archivos YAML en un repositorio de Git, y un agente compara continuamente ese estado declarado con el estado real del clúster y reconcilia cualquier diferencia.
y son las principales herramientas de GitOps. Flux consulta periódicamente el repositorio de Git o escucha eventos de webhook para detectar cambios y aplicarlos al clúster. ArgoCD añade una interfaz de usuario de visualización y políticas de sincronización sobre el mismo modelo. En Azure, se conecta AKS a y se instala la extensión de Flux para gestionar GitOps de forma centralizada en múltiples clústeres.
El valor central de GitOps es la trazabilidad de auditoría. Como cada cambio de infraestructura es un commit de Git, siempre existe un registro claro de quién cambió qué, cuándo y por qué. Las reversiones se manejan con . Un patrón común combina Azure Pipelines para construir y probar el código de la aplicación con GitOps para gestionar el estado del clúster, manteniendo ambas responsabilidades bien separadas.
Mantener el tráfico fluyendo mientras se repavimenta la carretera — Migraciones de bases de datos
No se puede cortar todo el tráfico solo porque la carretera necesita ser repavimentada. Se cierra un carril, el tráfico se desvía por el otro y la obra continúa. Los cambios de esquema de base de datos son la parte más delicada de un despliegue exactamente por esta razón. Las aplicaciones pueden reemplazarse rápidamente, pero un cambio de esquema es difícil de revertir.
El enfoque sigue tres etapas: Expand, Migrate y Contract. Primero se añade la nueva columna (Expand), luego se migran los datos existentes a ella (Migrate) y finalmente se elimina la columna antigua (Contract). Durante la fase Expand, tanto el esquema antiguo como el nuevo se admiten simultáneamente, de modo que en un despliegue Blue-Green la aplicación Green puede usar el nuevo esquema mientras la aplicación Blue continúa usando el antiguo sin fallos.
El principio de migración es: nunca eliminar ni renombrar una columna existente hasta que la versión antigua de la aplicación haya sido completamente retirada. Las eliminaciones o cambios de nombre de columnas pueden romper la versión actualmente en ejecución. En Azure, herramientas como EF Core Migrations, DACPAC/BACPAC y Flyway automatizan esta disciplina. Los scripts de migración deben incluirse en el pipeline como un paso explícito, y cada script debe ser idempotente, lo que significa que ejecutarlo varias veces debe producir exactamente el mismo resultado que ejecutarlo una sola vez.
Resumen para el Examen
"Enviar solo una porción del tráfico a la nueva versión para monitoreo" -- Despliegue Canary "Mantener dos entornos y cambiar el tráfico de forma atómica" -- Blue-Green / Slot Swap "Separar el despliegue del código del lanzamiento de funciones" -- Feature Flag "Almacenar y gestionar Feature Flags en Azure" -- Azure App Configuration + Feature Manager "Repositorio de Git como única fuente de verdad para el estado del clúster" -- GitOps "Agente de GitOps gestionado para AKS en Azure" -- Azure Arc + extensión Flux "Condición obligatoria cuando las versiones antigua y nueva se ejecutan simultáneamente en Rolling" -- Compatibilidad hacia atrás de la API "Añadir columna, migrar datos, eliminar columna antigua para proteger la app en ejecución" -- Expand-Migrate-Contract (Forward-only) "Apagar todas las instancias antes de desplegar la nueva versión, con tiempo de inactividad aceptado" -- Despliegue Recreate "Parámetros de control del ritmo en despliegue Rolling de AKS" -- maxUnavailable / maxSurge
Blue-Green = reversión inmediata, Canary = validación gradual, Feature Flag = separar despliegue de lanzamiento, GitOps = Git como fuente de verdad.