Designing and Implementing Microsoft DevOps Solutions (AZ-400) — Preguntas de práctica y simulacro de examen

Los deployment jobs de Azure Pipelines admiten tres estrategias: runOnce, rolling y canary. runOnce ejecuta cada hook del ciclo de vida (preDeploy, deploy, routeTraffic, postRouteTraffic) exactamente una vez. rolling reemplaza las instancias de la aplicación en un conjunto fijo de VMs, en lotes controlados por maxParallel, y por ahora solo se admite en recursos de VM. canary es la estrategia avanzada para una exposición incremental: ejecuta preDeploy una sola vez y luego repite deploy, routeTraffic y postRouteTraffic en cada incremento (por ejemplo, 10% y después 20%), revisando la salud en postRouteTraffic antes de promover al 100%. La variable strategy.increment está disponible durante esos hooks que se repiten. Ten en cuenta que blueGreen no es una palabra clave de estrategia integrada en los deployment jobs. Consejo para el examen: despliegue por porcentajes escalonados con comprobaciones de salud entre incrementos es canary; reemplazo por lotes en VMs es rolling; ejecución única es runOnce.

Un historial de commits lineal en la rama main significa que no hay merge commits: cada commit sigue secuencialmente. La política de squash merge en Azure Repos logra esto al combinar todos los commits de un pull request en un solo commit en la rama de destino. Cuando se habilita como política de rama en la rama main, todos los PR deben usar squash merge, lo que asegura que la rama main nunca contenga merge commits ni historial de ramificación. Esto crea un historial limpio y lineal que es fácil de leer y bisectar. Rebase merge también crea un historial lineal al reproducir commits en lugar de crear merge commits. Basic merge crea merge commits y no mantiene la linealidad. Consejo de examen: Squash merge = un solo commit por PR (historial lineal); rebase = reproducir commits (lineal); basic merge = merge commit (no lineal).