Designing and Implementing Microsoft DevOps Solutions (AZ-400) — Questões de prática e simulado

Os deployment jobs do Azure Pipelines oferecem três estratégias: runOnce, rolling e canary. runOnce executa cada hook do ciclo de vida (preDeploy, deploy, routeTraffic, postRouteTraffic) exatamente uma vez. rolling substitui as instâncias da aplicação em um conjunto fixo de VMs, em lotes controlados por maxParallel, e por enquanto só tem suporte para recursos de VM. canary é a estratégia avançada para exposição incremental: executa preDeploy uma vez e depois repete deploy, routeTraffic e postRouteTraffic a cada incremento (por exemplo, 10% e depois 20%), monitorando a saúde em postRouteTraffic antes de promover para 100%. A variável strategy.increment fica disponível durante esses hooks que se repetem. Observe que blueGreen não é uma palavra-chave de estratégia nativa dos deployment jobs. Dica de prova: rollout em porcentagens escalonadas com health checks entre os incrementos é canary; substituição em lotes em VMs é rolling; execução única é runOnce.

Um histórico de commits linear na branch main significa que não há merge commits — cada commit segue em sequência. A política de squash merge no Azure Repos faz isso combinando todos os commits de um pull request em um único commit na branch de destino. Quando habilitada como uma política de branch na branch main, todos os PRs precisam usar squash merge, garantindo que a branch main nunca contenha merge commits ou histórico de ramificações. Isso cria um histórico limpo e linear, fácil de ler e de fazer bisect. Rebase merge também cria um histórico linear ao reaplicar commits em vez de criar merge commits. Basic merge cria merge commits e não mantém a linearidade. Dica de prova: Squash merge = um único commit por PR (histórico linear); rebase = reaplica commits (linear); basic merge = merge commit (não linear).