Designing and Implementing Microsoft DevOps Solutions (AZ-400) — Übungsfragen und Probeprüfung

Deployment-Jobs in Azure Pipelines unterstützen drei Strategien: runOnce, rolling und canary. runOnce führt jeden Lifecycle-Hook (preDeploy, deploy, routeTraffic, postRouteTraffic) genau einmal aus. rolling ersetzt die Anwendungsinstanzen auf einer festen Menge von VMs in Batches, die über maxParallel gesteuert werden, und wird derzeit nur für VM-Ressourcen unterstützt. canary ist die fortgeschrittene Strategie für eine schrittweise Freigabe: preDeploy läuft einmal, danach werden deploy, routeTraffic und postRouteTraffic für jedes Inkrement wiederholt (zum Beispiel 10%, dann 20%), wobei in postRouteTraffic der Health-Status überwacht wird, bevor auf 100% erhöht wird. Die Variable strategy.increment steht während dieser wiederholten Hooks zur Verfügung. Beachte: blueGreen ist kein integriertes Strategie-Schlüsselwort für Deployment-Jobs. Prüfungstipp: gestaffelter prozentualer Rollout mit Health-Checks zwischen den Inkrementen bedeutet canary; batchweises Ersetzen auf VMs bedeutet rolling; einmalige Ausführung bedeutet runOnce.

Eine lineare Commit-Historie auf dem main Branch bedeutet keine Merge Commits - jeder Commit folgt sequenziell. Die Squash merge Policy in Azure Repos erreicht dies, indem sie alle Commits aus einem Pull Request zu einem einzelnen Commit auf dem Ziel-Branch zusammenfasst. Wenn sie als Branch Policy auf dem main Branch aktiviert ist, müssen alle PRs Squash merge verwenden, wodurch sichergestellt wird, dass der main Branch niemals Merge Commits oder Branching-Historie enthält. Das erzeugt eine saubere, lineare Historie, die leicht zu lesen und zu bisecten ist. Rebase merge erzeugt ebenfalls eine lineare Historie, indem Commits erneut abgespielt werden, statt Merge Commits zu erstellen. Basic merge erstellt Merge Commits und erhält keine Linearität. Prüfungstipp: Squash merge = ein einzelner Commit pro PR (lineare Historie); rebase = Commits erneut abspielen (linear); basic merge = Merge Commit (nicht linear).

Ein Cumulative Flow Diagram stapelt für jede Board-Spalte ein eigenes Band und zeigt, wie viele Elemente an jedem Tag in jeder Spalte lagen. Wird ein Band im Lauf der Zeit breiter, deutet das auf einen Engpass in dieser Spalte hin. Außerdem vermittelt das Diagramm einen Eindruck von der laufenden Arbeit (Work in Progress) und der Durchlaufzeit (Lead Time). Ein Sprint-Burndown verfolgt die verbleibende Arbeit innerhalb eines Sprints, ein Cycle-Time-Diagramm zeigt, wie lange einzelne Elemente gedauert haben, und Velocity vergleicht die erledigte Arbeit über mehrere Sprints hinweg. Prüfungstipp: Wenn ein Szenario danach fragt, wie viele Elemente im Zeitverlauf in jeder Spalte lagen, wähle das CFD.