Guía - AZ-400 Microsoft Azure DevOps Engineer Expert

Asegurar la calidad del código (compilación, prueba, cobertura) antes de fusionar una solicitud de extracción.

En la rama objetivo, configure una política de validación de compilación que active un pipeline al crear una PR. El pipeline debe publicar los resultados de cobertura de código. Establezca una política de rama para la cobertura mínima.

Por qué: Esto asegura la calidad antes de la fusión. Un disparador CI estándar se ejecuta después de la fusión. Las puertas de lanzamiento son para despliegues, no para PRs.

Seleccionar una estrategia de branching de Git que minimice los conflictos de fusión y soporte el despliegue rápido y continuo a producción.

Implementar desarrollo basado en tronco con ramas de características de corta duración que se fusionan a `main` frecuentemente (diariamente o más).

Por qué: Evita que las ramas diverjan significativamente, reduciendo los conflictos de fusión y asegurando que la rama `main` esté siempre cerca de un estado liberable.

Proteger una rama crítica (p. ej., `main`) aplicando revisiones de código, compilaciones exitosas y vinculación de elementos de trabajo antes de las fusiones.

Configure Políticas de Rama en la rama `main` en Azure Repos. Habilite políticas para un número mínimo de revisores, validación de compilación y vinculación de elementos de trabajo.

Por qué: Las políticas de rama proporcionan una aplicación del lado del servidor que no puede ser eludida por los desarrolladores, asegurando una calidad consistente y el cumplimiento del proceso.

Seleccionar una estrategia de branching de Git para un equipo con lanzamientos programados, desarrollo de características en paralelo y la necesidad de ramas de hotfix dedicadas.

Implementar el modelo de branching GitFlow, que utiliza las ramas `main`, `develop`, `feature/*`, `release/*` y `hotfix/*`.

Por qué: GitFlow proporciona un marco robusto para gestionar ciclos de lanzamiento complejos, aislando el nuevo desarrollo de la estabilización del lanzamiento y las correcciones de emergencia.

Un secreto fue accidentalmente commiteado y subido. Debe ser completamente eliminado de todo el historial de Git.

Primero, rote el secreto expuesto. Luego, use una herramienta como `git-filter-repo` o BFG Repo-Cleaner para reescribir el historial, eliminando el archivo. Force-push los cambios y notifique a todos los desarrolladores que vuelvan a clonar.

Por qué: Un simple `git rm` o revertir no elimina el secreto del historial. La reescritura del historial es necesaria para una purga permanente.

Modelar un flujo de trabajo complejo con etapas paralelas y dependencias entre etapas.

Utilice pipelines YAML multietapa. Use la palabra clave `dependsOn` para las dependencias de etapa y configure trabajos paralelos dentro de las etapas.

Por qué: YAML proporciona el enfoque más flexible y basado en código para la orquestación compleja, superior a los pipelines clásicos o la encadenación de pipelines separados.

Implementar un despliegue sin tiempo de inactividad, de bajo riesgo para una aplicación web con capacidad de reversión instantánea.

Utilice slots de despliegue de Azure App Service. Despliegue en un slot de staging (verde), valide, luego realice un intercambio de slot con producción (azul).

Por qué: Un intercambio de slot es una operación atómica, casi instantánea que redirige el tráfico. La reversión es tan simple como volver a intercambiar.

Referencia

Minimizar la duplicación de pipelines para numerosos microservicios que comparten pasos comunes de construcción/despliegue pero requieren personalizaciones específicas.

Cree plantillas YAML en un repositorio central. En cada pipeline específico del servicio, use la palabra clave `extends` y pase parámetros para la personalización.

Por qué: `extends` promueve los principios DRY y aplica estándares mientras permite flexibilidad a través de parámetros. Más potente que los grupos de tareas para estructuras completas de pipelines.

Restringir una etapa del pipeline (p. ej., despliegue de producción) para que se ejecute solo en fusiones a una rama específica (p. ej., main).

Use una `condition` en la etapa o el trabajo. P. ej., `condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))`.

Por qué: Las compilaciones de validación de PR utilizan una referencia de rama fuente diferente (p. ej., `refs/pull/...`), por lo que esta condición previene correctamente el despliegue durante el ciclo de vida de la PR.

Desplegar aplicaciones desde Azure DevOps a servidores locales detrás de un firewall corporativo.

Instale agentes autohospedados en los servidores locales. Regístrelos en un grupo de agentes en Azure DevOps.

Por qué: Los agentes autohospedados inician comunicación saliente con Azure DevOps, por lo que no se necesitan reglas de firewall de entrada. Pueden acceder a recursos de red locales para el despliegue.

Requerir aprobación de varias personas para los despliegues de producción y restringirlos a ventanas de mantenimiento específicas.

Defina un entorno de Azure DevOps para producción. Configure aprobaciones con los aprobadores requeridos. Agregue una verificación de "Horario Comercial" como una puerta para hacer cumplir la ventana de tiempo.

Por qué: Los entornos centralizan los controles de despliegue. Las aprobaciones y las puertas proporcionan una aplicación de políticas robusta y automatizada antes de que se ejecute una etapa.

Controlar la exposición de características a los usuarios sin volver a desplegar la aplicación, con actualizaciones casi en tiempo real.

Utilice Azure App Configuration para la gestión de características. Instrumente la aplicación para leer flags y habilite sus capacidades de actualización dinámica.

Por qué: Desacopla los lanzamientos de características de los despliegues. App Configuration proporciona una interfaz de usuario centralizada y SDKs para actualizaciones dinámicas, evitando reinicios de aplicaciones.

Administrar el estado del clúster de Kubernetes de forma declarativa, donde Git es la única fuente de verdad y los cambios se aplican automáticamente.

Despliegue un agente GitOps como Flux o ArgoCD en el clúster AKS. Configure el agente para monitorear un repositorio Git que contenga manifiestos de Kubernetes y sincronice automáticamente el estado del clúster.

Por qué: Este modelo basado en extracción permite la conciliación continua y la detección de desviaciones, que es fundamental para GitOps. Es más robusto que los pipelines `kubectl` basados en envío.

Administrar el estado de Terraform para la colaboración en equipo, garantizando la seguridad y previniendo modificaciones concurrentes.

Configure el backend de Terraform para usar una cuenta de almacenamiento de Azure. Esto proporciona almacenamiento de estado remoto, con el bloqueo de estado gestionado a través de arrendamiento de Azure Blob.

Por qué: Evita la corrupción del archivo de estado por operaciones `apply` simultáneas y mantiene los datos de estado sensibles fuera del control de código fuente.

Referencia

En un monorepo, activar el pipeline CI de una aplicación solo cuando se modifican archivos en su directorio específico (o un directorio compartido).

En el YAML del pipeline, use el filtro `trigger.paths.include` para especificar los directorios relevantes, p. ej., `include: ['/apps/frontend/**', '/apps/shared/**']`.

Por qué: Esto evita compilaciones innecesarias para cambios de código no relacionados, ahorrando tiempo de CI y recursos computacionales.

Optimizar una etapa de prueba con pruebas rápidas (unitarias) y lentas (de integración) para una retroalimentación más rápida.

Ejecute pruebas unitarias y pruebas de integración en trabajos paralelos dentro de la misma etapa.

Por qué: La ejecución paralela proporciona resultados de pruebas unitarias mucho más rápido mientras las pruebas más lentas se ejecutan concurrentemente. La duración total de la etapa está determinada por el trabajo más largo, no por la suma.

Versionar automáticamente un paquete de biblioteca basado en el historial de commits para comunicar claramente el impacto de los cambios (rupturas, características, correcciones).

Integre una herramienta como GitVersion en el pipeline CI. Analiza mensajes de commit, ramas y etiquetas para calcular automáticamente una versión SemVer (Mayor.Menor.Parche).

Por qué: SemVer proporciona un versionado significativo en el que los consumidores pueden confiar para la gestión de dependencias, a diferencia de los números de compilación o los hashes de commit.

Desplegar una aplicación en múltiples regiones geográficas una por una, con validación después de cada despliegue regional.

Utilice un pipeline YAML multietapa con etapas secuenciales, una para cada región, usando `dependsOn` para forzar el orden. Use puertas de entorno entre etapas para la validación.

Por qué: Este modelo de despliegue basado en anillos contiene el radio de impacto de un despliegue defectuoso a una sola región, permitiendo la reversión antes de afectar a todos los usuarios.

Configurar un pipeline para soportar un modelo de desarrollo basado en tronco (trunk-based development), asegurando que la rama principal sea siempre desplegable.

Configure un disparador CI en la rama `main`. Imponga PRs con una política de validación de compilación que ejecute pruebas rápidas y completas. Integre notificaciones rápidas (p. ej., a Teams/Slack) para fallos de compilación.

Por qué: La retroalimentación inmediata es crítica en el desarrollo basado en tronco. Esta combinación evita que se fusione código defectuoso y asegura una remediación rápida cuando ocurren problemas.

Pasar artefactos grandes (p. ej., modelos ML, >5GB) entre etapas del pipeline de manera eficiente.

Suba el artefacto grande a Azure Blob Storage en la etapa productora. Pase el URI del blob a la etapa consumidora como una variable de salida.

Por qué: Azure Blob Storage es más rentable y de mayor rendimiento que los artefactos de pipeline incorporados para archivos de varios gigabytes.

Reducir los tiempos de compilación evitando la descarga repetida de dependencias (p. ej., NuGet, npm) en cada ejecución.

Utilice la tarea `Cache@2`. Defina una clave basada en el archivo de bloqueo del paquete (p. ej., `packages.lock.json`). La tarea almacenará y restaurará la carpeta de dependencias.

Por qué: Puede ahorrar varios minutos por compilación restaurando desde una caché local rápida en lugar de obtener desde repositorios externos.

Compilar o desplegar el mismo código en paralelo contra múltiples destinos (p. ej., diferentes SO, regiones).

Use una `strategy: matrix` en el trabajo del pipeline YAML. Defina variables para cada combinación, lo que generará un trabajo para cada entrada de la matriz.

Por qué: Una estrategia de matriz mantiene la definición del pipeline DRY, creando múltiples variaciones de trabajo a partir de una única definición y ejecutándolas en paralelo.

Implementar un despliegue canary en AKS que cambie automáticamente el tráfico y promocione o revierta basándose en métricas en tiempo real.

Utilice un controlador de entrega progresiva como Flagger, integrado con una malla de servicios (p. ej., Istio) y un proveedor de métricas (p. ej., Prometheus).

Por qué: Flagger automatiza todo el proceso de análisis canary, proporcionando una entrega progresiva más segura y confiable que los scripts manuales.

Un pipeline de aplicación necesita activarse cuando el código cambia en su propio repositorio O en un repositorio de biblioteca compartida separado.

En el YAML de la aplicación, defina la biblioteca compartida bajo `resources.repositories` y configure un bloque `trigger` en ese recurso.

Por qué: Crea una dependencia declarativa entre repositorios, asegurando que la aplicación siempre se reconstruya con los últimos componentes compartidos.

Un pipeline necesita crear infraestructura temporal para pruebas y asegurar que se destruya después, incluso si las pruebas fallan.

Utilice un pipeline multietapa con etapas separadas de aplicación y destrucción para IaC (Terraform/Bicep). Configure la etapa de destrucción con `condition: always()` .

Por qué: La condición `always()` garantiza que la etapa de limpieza se ejecute independientemente del éxito o fracaso de las etapas anteriores, evitando recursos huérfanos.

Evitar que un despliegue de producción avance a menos que haya una solicitud de cambio aprobada en una herramienta ITSM como ServiceNow.

Configure una puerta de Entorno que invoque la puerta "Query ServiceNow" para verificar el estado de la solicitud de cambio.

Por qué: Automatiza la integración con los procesos de gestión de cambios empresariales, asegurando el cumplimiento sin traspasos manuales.

Proporcionar un pool de agentes de compilación autohospedados que escala dinámicamente con la demanda para reducir los tiempos de cola y controlar los costos.

Configure un pool de agentes de Azure DevOps utilizando un Conjunto de Escalado de Máquinas Virtuales de Azure (VMSS), configurado para escalar automáticamente según el número de trabajos pendientes.

Por qué: Los agentes VMSS combinan la personalización de los agentes autohospedados con la elasticidad de los agentes alojados en la nube, optimizando el rendimiento y el costo.

Desplegar cambios de esquema de base de datos de una manera que prevenga la pérdida de datos y soporte reversiones.

Utilice una herramienta de migración (p. ej., Flyway, DbUp). Implemente el patrón expandir/contraer para cambios de esquema para mantener la compatibilidad hacia atrás.

Por qué: Las herramientas de migración proporcionan versionado y control. El patrón expandir/contraer desacopla las reversiones de la aplicación y la base de datos, permitiendo despliegues más seguros.

Los agentes autohospedados se están quedando sin espacio en disco debido a los artefactos de compilación acumulados.

En el YAML del pipeline, a nivel de trabajo, configure `workspace: clean: all`.

Por qué: Esta configuración preventiva del pipeline resuelve la causa raíz sin requerir intervención manual o cambios continuos en la infraestructura.

Las pruebas de integración requieren una instancia de base de datos aislada para cada ejecución del pipeline.

Defina un recurso de contenedor (p. ej., SQL Server, Postgres) como un servicio en el YAML del pipeline. El trabajo de prueba puede entonces conectarse a este servicio efímero.

Por qué: Proporciona dependencias rápidas, aisladas y limpiadas automáticamente para las pruebas, previniendo interferencias en las pruebas y simplificando la configuración.

Mejorar la confiabilidad y el rendimiento de la restauración de paquetes desde repositorios públicos (p. ej., npmjs, nuget.org).

En Azure Artifacts, cree un feed y configure fuentes ascendentes apuntando a los repositorios públicos. Haga que los clientes consuman paquetes del feed de Azure Artifacts.

Por qué: El feed almacena en caché los paquetes de fuentes ascendentes, protegiendo contra interrupciones de repositorios públicos y acelerando las restauraciones de paquetes de uso frecuente.

Desplegar un chart de Helm en múltiples entornos (dev, prod) con diferentes valores de configuración.

Utilice archivos `values-<env>.yaml` separados para cada entorno. En la tarea `HelmDeploy`, use la entrada `valueFile` para especificar el archivo apropiado y `overrideValues` para inyectar valores dinámicos como etiquetas de imagen.

Por qué: Este patrón separa la configuración estática del entorno de las variables dinámicas del pipeline, manteniendo los despliegues limpios y mantenibles.

Administrar y consumir de forma segura secretos (p. ej., cadenas de conexión) en pipelines sin codificarlos directamente.

Almacene secretos en Azure Key Vault. En Azure DevOps, cree un Grupo de Variables vinculado al Key Vault. Referencie los secretos del grupo de variables en el pipeline.

Por qué: Centraliza la gestión de secretos, permite la rotación sin cambios en el pipeline y proporciona un control de acceso y auditoría robustos a través de Key Vault.

Implementar escaneo de seguridad en el pipeline CI para detectar vulnerabilidades en el código de la aplicación (SAST) y dependencias de terceros (SCA).

Integre la extensión Microsoft Security DevOps, que incluye múltiples escáneres. Considere también GitHub Advanced Security para Azure DevOps para una suite nativa y completa.

Por qué: Este enfoque de "shift-left" identifica vulnerabilidades temprano en el ciclo de vida del desarrollo, reduciendo costos y riesgos.

Restringir el acceso de los desarrolladores a los entornos de producción para evitar cambios directos, al mismo tiempo que se permite el acceso de emergencia auditado.

Elimine los roles permanentes de Colaborador/Propietario. Use Conexiones de Servicio de pipeline para los despliegues. Para emergencias, use Azure AD Privileged Identity Management (PIM) para acceso elevado Just-In-Time (JIT).

Por qué: PIM proporciona acceso elevado con límite de tiempo, con aprobación y completamente auditado, adhiriéndose al principio de mínimo privilegio.

Proporcionar secretos a microservicios en AKS de forma segura, con rotación automática y acceso específico de la carga de trabajo.

Utilice Azure Key Vault integrado con el Secrets Store CSI Driver para AKS. Use identidad de carga de trabajo para que los pods se autentiquen en Key Vault.

Por qué: Monta secretos directamente en los pods desde Key Vault, evitando Kubernetes Secrets. Permite identidad a nivel de pod y rotación de secretos sin interrupciones.

Referencia

Asegurar que solo las imágenes de contenedor escaneadas y firmadas puedan desplegarse en un clúster de Kubernetes de producción.

Utilice la confianza de contenido de Azure Container Registry (ACR) para la firma de imágenes. Use Microsoft Defender for Containers para el escaneo. Use Azure Policy para Kubernetes para aplicar políticas en AKS.

Por qué: Proporciona una estrategia de seguridad de imágenes de contenedor integral, basada en políticas y de defensa en profundidad, desde la construcción hasta el tiempo de ejecución.

Conectar Azure Pipelines a recursos de Azure sin usar secretos de cliente o certificados.

Cree una conexión de servicio de Azure Resource Manager usando "Workload Identity Federation".

Por qué: Elimina la necesidad de gestionar y rotar secretos, mejorando la postura de seguridad del sistema CI/CD.

Desplegar en la suscripción de Azure de un cliente desde su organización de Azure DevOps sin intercambiar secretos.

Despliegue un agente autohospedado dentro del entorno Azure del cliente. Asigne una Identidad Administrada a la VM/VMSS del agente y otórguele los roles RBAC necesarios.

Por qué: Mantiene todos los principios de autenticación dentro del inquilino del cliente, adhiriéndose a un modelo de confianza cero. No hay secretos que crucen los límites del inquilino.

Administrar el trabajo para múltiples equipos en un producto grande, permitiendo la autonomía del equipo mientras se proporciona visibilidad entre equipos para el liderazgo.

Utilice un único Proyecto con Rutas de Área para cada equipo para darles backlogs filtrados. Utilice Planes de Entrega para visualizar el progreso y las dependencias entre equipos.

Por qué: Permite informes acumulativos y seguimiento de dependencias mientras cada equipo gestiona sus propios sprints y elementos de trabajo de forma independiente.

Vincular automáticamente commits/PRs a elementos de trabajo y transicionar el estado del elemento de trabajo (p. ej., a "Resuelto") al fusionar una PR.

En la Configuración del Proyecto, habilite "Completar automáticamente elementos de trabajo con solicitudes de extracción". Los desarrolladores deben usar `#<ID>` en los mensajes de commit o vincular PRs.

Por qué: Reduce la sobrecarga manual para los desarrolladores, mantiene actualizado el estado de los elementos de trabajo y mejora la trazabilidad entre el código y los requisitos.

Medir métricas clave de proceso como Tiempo de Ciclo, Tiempo de Entrega y métricas DORA para el análisis de flujo de valor.

Utilice el servicio Azure DevOps Analytics y su feed OData. Conecte Power BI o use widgets de panel incorporados para visualizar estas métricas.

Por qué: El servicio Analytics proporciona los datos subyacentes para las métricas clave de flujo y SRE, lo que permite la mejora de procesos basada en datos.

Investigar tiempos de respuesta lentos intermitentes que están ocultos por las métricas de rendimiento promedio.

En Application Insights, use la pestaña Rendimiento con análisis de percentiles (P95, P99) y Búsqueda de Transacciones para profundizar en muestras específicas de solicitudes lentas.

Por qué: Los promedios pueden ser engañosos. Los percentiles revelan la "cola larga" de los problemas de rendimiento, que a menudo representan a los usuarios más frustrados.

Rastrear una única solicitud de usuario mientras viaja a través de múltiples microservicios para identificar cuellos de botella o puntos de fallo.

Instrumente todos los servicios con el SDK de Application Insights. Propaga automáticamente un ID de correlación de Contexto de Trazas W3C a través de las llamadas de servicio.

Por qué: Proporciona una vista unificada de una transacción distribuida en el Mapa de Aplicación, lo que permite depurar interacciones complejas.

Monitorear proactivamente el Objetivo de Nivel de Servicio (SLO) de una aplicación y recibir alertas *antes* de que se incumpla el SLO.

Defina SLIs usando consultas KQL en Azure Monitor. Cree una regla de alerta que se active en función de la tasa de consumo del presupuesto de errores (qué tan rápido se está consumiendo el presupuesto).

Por qué: Las alertas de tasa de consumo son predictivas, proporcionando tiempo para reaccionar antes de que se incumpla un SLO y los usuarios se vean significativamente afectados.

Validar que un despliegue fue funcionalmente exitoso desde la perspectiva del usuario, no solo que las tareas del pipeline se completaron.

Como paso posterior al despliegue o puerta de lanzamiento, ejecute pruebas de disponibilidad de Application Insights (monitoreo sintético) que simulen flujos clave de usuario.

Por qué: El éxito del pipeline solo indica que se movieron bits. Las pruebas sintéticas confirman que la aplicación realmente está funcionando, detectando configuraciones erróneas o fallos de dependencia.

Correlacionar visualmente los eventos de despliegue con cambios en el rendimiento de la aplicación y las métricas de tasa de error.

Utilice la tarea de Azure Pipelines para crear "Anotaciones de Lanzamiento" en Application Insights, lo que coloca un marcador en los gráficos de métricas.

Por qué: Proporciona retroalimentación visual inmediata para identificar rápidamente si un despliegue reciente introdujo una regresión de rendimiento o un error.

Probar proactivamente la resiliencia de la aplicación y la infraestructura ante fallas de manera controlada.

Integre Azure Chaos Studio en los pipelines de lanzamiento. Cree experimentos que inyecten fallas (p. ej., apagado de VM, latencia de red) y validen el comportamiento del sistema.

Por qué: Va más allá de probar el comportamiento esperado para probar fallas inesperadas, construyendo confianza en la resiliencia del sistema.