Microsoft AZ-400: Gestión de lanzamientos y estrategias de despliegue — Guía de estudio

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Forma parte de la Microsoft DevOps Engineer Expert AZ-400 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Descripción general

La gestión de versiones en Azure se basa en una entrega repetible y gobernada por políticas que protege la disponibilidad a la vez que acelera la retroalimentación. Dominar las estrategias de implementación, las validaciones controladas, la exposición basada en anillos y los lanzamientos oscuros con marcadores de características (feature flags) permite a los equipos realizar entregas continuas sin sacrificar la seguridad. Azure Pipelines, Azure Deployment Environments, Azure Front Door/Traffic Manager y Azure App Configuration proporcionan una cadena de herramientas cohesiva para la entrega progresiva, la orquestación de múltiples entornos y un control de cambios auditable. Esta sección explica cuándo y cómo usar cada capacidad, cómo interconectarlas y qué prácticas de reversión (rollback) y documentación se esperan en las canalizaciones de nivel de producción.

Estrategias de implementación y entrega progresiva

La implementación azul-verde (rojo/negro) despliega la nueva versión en un entorno paralelo (verde) mientras el actual (azul) atiende el tráfico. En Azure App Service, las ranuras de implementación implementan el patrón azul-verde: se despliega en el entorno de ensayo (staging), se precalienta y luego se realiza un intercambio de ranuras. La reversión es instantánea al volver a intercambiar las ranuras, por lo que el azul-verde es la opción de reversión más rápida. Combine los intercambios de ranuras con la opción «Intercambiar con vista previa» para validar los enlaces y la configuración de la aplicación antes de que se mueva el tráfico.

El despliegue canary se dirige primero a un pequeño segmento de usuarios y luego aumenta progresivamente el tráfico si el estado de salud se mantiene. En Azure, implemente un despliegue canary con:

• Enrutamiento ponderado de Azure Front Door para dividir el tráfico entre los backends antiguos y nuevos en la capa de aplicación con sondeos de estado y WAF.
• Puntos de conexión ponderados de Azure Traffic Manager para despliegues canary globales basados en DNS cuando necesite control a nivel de región.
• Canary en AKS a través de Ingress (p. ej., anotaciones canary de NGINX) o división de tráfico con un service mesh. Las puertas de enlace (gates) deben evaluar los presupuestos de error, los percentiles de latencia y la saturación antes de avanzar.

Las actualizaciones graduales (rolling updates) reemplazan las instancias poco a poco, evitando el costo de una doble flota. En AKS, configure rollingUpdate con maxSurge y maxUnavailable; asegúrese de que las sondas de preparación y de actividad (readiness/liveness probes) y los PDBs protejan la disponibilidad. Para VM Scale Sets, utilice políticas de actualización gradual con sondas de estado de la aplicación. La actualización gradual es económica, pero la recuperación de regresiones sistémicas es más lenta que con el método azul-verde.

Los marcadores de características (feature flags) desacoplan la publicación (release) de la implementación (deploy). El lanzamiento oscuro (dark launching) entrega rutas de código deshabilitadas por defecto, ejercitando la infraestructura sin exponer las características. Use los marcadores para controlar migraciones costosas, revelar progresivamente la interfaz de usuario y desactivar rápidamente un comportamiento problemático. Esto complementa los despliegues canary y por anillos: implementar ampliamente y luego habilitar progresivamente.

La implementación basada en anillos formaliza la exposición progresiva a través de cohortes. Defina anillos como R0 (interno), R1 (clientes canary), R2 (una región) y R3+ (global). Los criterios de avance deben ser objetivos: cumplimiento de los SLO, ausencia de incidentes Sev2+ y KPIs de negocio aceptables. Combine los anillos con el desvío de tráfico (Front Door/Traffic Manager), las comprobaciones de entorno y las puertas de aprobación para detener o revertir tempranamente.

Azure Front Door frente a Traffic Manager para el desvío progresivo de tráfico: Front Door opera en la capa 7 con cambios instantáneos, sondeos de estado, afinidad de sesión, enrutamiento basado en rutas y divisiones ponderadas, lo que es ideal para despliegues canary a nivel de aplicación y pruebas A/B. Traffic Manager opera a nivel de DNS; es mejor para el enrutamiento geográfico, la conmutación por error entre nubes o los despliegues canary a nivel de región, pero tiene consideraciones de TTL de DNS y carece de características de la capa de aplicación.

Entornos, aprobaciones y puertas de enlace

Azure Deployment Environments estandariza el aprovisionamiento de entornos de desarrollo/pruebas con barreras de protección (guardrails). Las definiciones de entorno son plantillas de infraestructura como código (Bicep/ARM/Terraform) que describen pilas repetibles. Las definiciones residen en catálogos (repositorios de Git registrados en el servicio), lo que permite tener planos de entorno versionados y detectables. Los desarrolladores autoaprovisionan instancias de desarrollo/pruebas restringidas por políticas empresariales (cuotas, RBAC, redes), eliminando las configuraciones únicas (snowflakes) y alineando los entornos inferiores con la topología de producción.

Las aprobaciones establecen controles con intervención humana donde sea necesario. En Azure Pipelines:

• Las aprobaciones previas a la implementación bloquean una fase hasta que los aprobadores designados den su consentimiento. Úselas para transiciones de alto riesgo, p. ej., del entorno de ensayo a producción o para la escalada de anillos más allá del canary.
• Las aprobaciones posteriores a la implementación confirman las actividades de validación (aceptación de UAT, pasos de auditoría) antes de que la versión se marque como completada.
• Configure tiempos de espera para las aprobaciones de modo que las solicitudes caduquen automáticamente; las aprobaciones caducadas provocan el fallo de la fase y evitan derivas incontroladas. Exija múltiples aprobadores o secuencie las aprobaciones cuando sea necesaria una separación de funciones. Aplique aprobaciones a los entornos y a las conexiones de servicio a través de «Aprobaciones y comprobaciones» para una gobernanza coherente.

Las puertas de enlace de versión (release gates) exigen evidencia objetiva antes de la promoción. Azure Pipelines admite comprobaciones como:

• Comprobaciones de Azure Monitor que consultan métricas o alertas (p. ej., que no haya alertas Sev2 activas, que la tasa de error esté por debajo del umbral, que la latencia p95 esté por debajo del objetivo). Las puertas de enlace se reevalúan a un intervalo definido hasta que se alcanza el éxito/fallo o el tiempo de espera.
• Comprobaciones de «Invocar API REST» para llamar a servicios de calidad externos, pruebas de carga o puntos de conexión de cumplimiento internos. Analice las respuestas y bloquee si no se cumplen los criterios.
• Comprobaciones de consulta de elementos de trabajo para garantizar que las tareas, los errores o las solicitudes de cambio requeridas estén en los estados correctos antes de la versión (p. ej., que todos los defectos «Must Fix» estén resueltos). Use consultas acotadas al rango de la versión o del commit.

Implemente puertas de enlace en los límites de los anillos y durante el despliegue canary para pasar de decisiones de promoción subjetivas a medibles.

Canalizaciones Multi-Entorno, Variables y Dependencias

Diseñe canalizaciones YAML multi-etapa con dependencias explícitas y alcance por entorno. Use trabajos de despliegue con bloques de estrategia (runOnce, rolling, canary) para modelar el despliegue progresivo e incluya hooks para preDeploy, routeTraffic, postRouteTraffic y on: failure para el rollback automatizado. Las etapas deben declarar dependsOn y conditions para que los entornos posteriores solo se ejecuten después de que los anteriores superen las puertas y aprobaciones.

Gestione la configuración específica del entorno a través de:

• Grupos de variables con alcance por entorno, vinculados a Azure Key Vault para los secretos. Haga referencia a los grupos por etapa y mantenga los valores sensibles fuera del control de código fuente.
• Plantillas YAML y parámetros en tiempo de ejecución para estandarizar los despliegues entre servicios y pasar valores específicos del entorno (cadenas de conexión, valores predeterminados de los feature flags, ponderación de Front Door).
• Tareas de tokenización o transformación para appsettings y manifiestos de Kubernetes, asegurando una configuración como código sin desviaciones.

Para despliegues en múltiples entornos, prefiera artefactos inmutables con promoción (construir una vez, desplegar muchas veces). Vincule los elementos de trabajo a los commits y compilaciones para mantener la trazabilidad a medida que el mismo artefacto fluye de desarrollo a producción, permitiendo notas de la versión y auditorías precisas.

Estrategias de Rollback y Consideraciones de Base de Datos

Planifique los rollbacks antes de lanzar:

• El rollback automático utiliza señales de salud para revertir sin acción humana. En AKS, establezca maxSurge/maxUnavailable de forma conservadora y habilite el rollback automático en despliegues fallidos; use

undefined

o confíe en los hooks de fallo de la estrategia de despliegue para activar un ReplicaSet anterior. En Azure App Service, revertir un intercambio de slot es instantáneo; combínelo con comprobaciones de estado y puertas de despliegue para decidir automáticamente.

• El rollback manual es apropiado cuando la recuperación requiere el juicio del operador (riesgo de datos, fallo parcial). Proporcione tareas de canalización de un solo clic que redirijan las ponderaciones de Front Door/Traffic Manager, deshagan los intercambios de slot o redesplieguen la última compilación buena conocida. Mantenga el artefacto anterior fácilmente disponible y documente el proceso de decisión.
• El rollback de la base de datos exige un cuidado especial. Evite cambios incompatibles con versiones anteriores. Use el patrón expandir-contraer: añada columnas/tablas y popúlelas mientras las lecturas/escrituras siguen siendo compatibles; despliegue código que escriba en ambos esquemas si es necesario; solo más tarde elimine los elementos obsoletos. Para Azure SQL Database, combine:
  • DACPAC o frameworks de migración (EF Core) con scripts idempotentes y versionados y validación pre y post-despliegue.
  • Operaciones en línea (reconstrucciones de índices con opción reanudable, cambio de particiones) para minimizar la contención de bloqueos.
  • Restauración a un punto en el tiempo y georreplicación activa como último recurso, asumiendo el riesgo de pérdida de datos. Desactive funcionalidades mediante flags antes de cualquier degradación del esquema. Controle las promociones basándose en la salud de la base de datos (DTU/CPU, interbloqueos) capturada en Azure Monitor y Query Store.

Feature Flags con Azure App Configuration y Automatización de Notas de la Versión

Azure App Configuration centraliza la gestión de características con SDK para .NET, Java, Node.js y otros. Utilice etiquetas para acotar los marcadores por entorno o anillo y habilite la actualización dinámica para que las aplicaciones recojan los cambios sin necesidad de volver a desplegar.

• Los filtros de segmentación (Targeting filters) permiten una habilitación granular basada en usuario/grupo, notificaciones (claims), dispositivo o atributos personalizados. Defina cohortes (p. ej., inquilinos internos, clientes VIP) para alinearlas con los anillos.
• El despliegue por porcentaje (Percentage rollout) expone gradualmente las características a un subconjunto aleatorio. Comience con un 1–5 %, valide los KPI y luego aumente. Coordine con la ponderación de Front Door para un control por capas a nivel de usuario y de tráfico.
• Los interruptores de emergencia (Kill switches) desactivan una característica al instante cuando ocurren incidentes. Proteja las rutas de alto riesgo (pagos, escrituras de datos) con un interruptor de desactivación global que no requiere despliegues para ejecutarse. Registre todos los cambios de estado de los marcadores para auditoría y correlaciónelos con los incidentes.

Automatice las notas de la versión para proporcionar trazabilidad y comunicación:

• Fuerce la vinculación de elementos de trabajo requiriendo que los mensajes de los commits y los PR hagan referencia a los ID. Azure DevOps asocia automáticamente las compilaciones y versiones con elementos de trabajo y commits.
• Genere registros de cambios (changelogs) en las canalizaciones utilizando la tarea “Generate Release Notes” o llamadas a la API REST para listar los cambios y elementos de trabajo desde el último despliegue exitoso al entorno de destino. Genere un Markdown con secciones para características, correcciones, cambios que rompen la compatibilidad (breaking changes) y migraciones de base de datos.
• Publique las notas en la Wiki del proyecto, empaquételas como un artefacto de compilación y adjúntelas a la versión. Incluya metadatos del despliegue (número de compilación, SHA del commit, entorno, aprobadores, puertas superadas) para el cumplimiento normativo.

Escenario de Problema Práctico

Adobe necesita introducir un nuevo motor de personalización en sus sitios de marketing alojados en Azure sin arriesgar las tasas de conversión durante las campañas de mayor actividad. El equipo debe desplegar con frecuencia, exponer progresivamente la característica, validar los SLO y revertir instantáneamente si los KPI se degradan.

1. Definir entornos con Azure Deployment Environments

• Crear definiciones de entorno (Bicep) para la aplicación, AKS, Azure SQL y Front Door en un catálogo respaldado por Git. Los desarrolladores autoprovisionan entornos de desarrollo/prueba de forma segura, garantizando la paridad con producción y permitiendo pilas de prueba efímeras para experimentos. ADE aplica cuotas y RBAC para controlar el gasto y el acceso.

2. Compilar una vez, desplegar muchas veces con YAML multietapa

• Un único artefacto se promueve a través de las etapas ring-r0, ring-r1, ring-r2 y prod. Las etapas dependen unas de otras y utilizan trabajos de despliegue con estrategias: canary y rolling donde sea apropiado, garantizando binarios consistentes en todos los anillos.

3. Usar azul-verde con slots de App Service para la capa web heredada

• Desplegar en un slot de preproducción (staging), prepararlo y luego intercambiarlo (swap) para los usuarios internos del anillo ring-r0. Si los SLO de Adobe se degradan, un intercambio de slot inverso proporciona la reversión más rápida con un tiempo de inactividad casi nulo.

4. Introducir canary mediante el enrutamiento ponderado de Azure Front Door

• Registrar tanto el backend de personalización heredado como el nuevo. Comenzar con un 1 % del tráfico hacia el nuevo backend en el anillo ring-r1. Las sondas de estado de Front Door y las actualizaciones instantáneas de peso permiten ajustes seguros y rápidos, alineados con los patrones de tráfico.

5. Controlar las promociones con puertas (gates) y comprobaciones objetivas

• Añadir comprobaciones de Azure Monitor para la latencia p95, la tasa de errores y los KPI de conversión obtenidos de Application Insights. Añadir una comprobación de API REST al servicio de experimentación interno de Adobe para confirmar las métricas de seguridad. Configurar una comprobación de consulta de elementos de trabajo para asegurar que los errores “Must Fix” (deben corregirse) se cierren antes de avanzar de anillo. Las puertas se evalúan periódicamente y tienen un tiempo de espera para evitar que los cambios se estanquen.

6. Requerir aprobaciones en transiciones críticas

• Las aprobaciones previas al despliegue para ring-r2 y prod requieren la firma de marketing y SRE, con un tiempo de espera de 4 horas para evitar versiones pendientes. Las aprobaciones posteriores al despliegue confirman que las pruebas de aceptación del usuario (UAT) y la validación de análisis están completas antes de cerrar la versión.

7. Controlar la exposición con feature flags de Azure App Configuration

• Implementar el lanzamiento oscuro (dark launching) para que el nuevo motor esté presente pero deshabilitado inicialmente. Usar filtros de segmentación para habilitarlo para el personal interno (ring-r0) y cohortes de clientes seleccionadas (ring-r1). Aplicar el despliegue por porcentaje para expandir la exposición. Un interruptor de emergencia (kill switch) deshabilita el motor globalmente en segundos sin volver a desplegar si aparecen anomalías.

8. Proteger los datos con migraciones de expansión-contracción

• Desplegar primero los cambios aditivos en SQL, rellenar los datos de forma asíncrona y realizar escritura dual donde sea necesario. Solo después de que se demuestre la estabilidad, se elimina el esquema obsoleto. Las puertas monitorizan las DTU, los interbloqueos (deadlocks) y las consultas de larga duración para evitar una promoción insegura.

9. Automatizar las rutas de reversión (rollback)

• Los enlaces de error (failure hooks) en los trabajos de despliegue activan la reversión: los pesos de Front Door vuelven al 0 % para el nuevo backend; App Service realiza un intercambio de slot inverso; AKS ejecuta

undefined

. La reversión manual con un solo clic sigue disponible para los operadores en escenarios complejos.

10. Automatizar la documentación de la versión

• La canalización genera notas de la versión en Markdown a partir de los elementos de trabajo y commits asociados, destacando las características activadas, los cambios en la base de datos y las puertas superadas. Las notas se publican en la Wiki de Azure DevOps y se adjuntan a la versión, satisfaciendo la auditoría y la visibilidad para los interesados.

Este enfoque utiliza cada herramienta según su punto fuerte: ADE para entornos seguros y reproducibles; estrategias YAML y aprobaciones para un flujo gobernado; Front Door y App Configuration para una entrega progresiva por capas; Azure Monitor y las puertas para un control de calidad objetivo; y reversiones y notas de la versión automatizadas para resiliencia y trazabilidad.

← Contenerización y Kubernetes · Todos los dominios · Seguridad →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Microsoft →