Microsoft AZ-400: Releasebeheer en Deploymentstrategieën — Studiegids

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

Onderdeel van de Microsoft DevOps Engineer Expert AZ-400 — Studiegids. Oefen met geverifieerde antwoorden in het Microsoft-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Releasemanagement op Azure draait om herhaalbare, beleidsgestuurde levering die de beschikbaarheid beschermt en tegelijkertijd de feedback versnelt. Het beheersen van implementatiestrategieën, gecontroleerde validaties (gates), ring-gebaseerde blootstelling en ‘dark launches’ met feature flags stelt teams in staat om continu te leveren zonder in te boeten aan veiligheid. Azure Pipelines, Azure Deployment Environments, Azure Front Door/Traffic Manager en Azure App Configuration bieden een samenhangende toolchain voor progressieve levering, orkestratie van meerdere omgevingen en auditeerbaar wijzigingsbeheer. Dit gedeelte legt uit wanneer en hoe u elke mogelijkheid gebruikt, hoe u ze met elkaar verbindt, en welke rollback- en documentatiepraktijken worden verwacht in productiewaardige pipelines.

Implementatiestrategieën en Progressieve Levering

Blue-green (rood/zwart) implementeert de nieuwe versie in een parallelle omgeving (groen), terwijl de huidige (blauw) het verkeer afhandelt. Op Azure App Service implementeren deployment slots blue-green: implementeer naar de staging-omgeving, warm deze op en voer vervolgens een ‘slot swap’ uit. Een rollback is onmiddellijk door terug te swappen, wat blue-green de snelste rollback-optie maakt. Combineer ‘slot swaps’ met “Swap with preview” om bindings en app-instellingen te valideren voordat het verkeer wordt verplaatst.

Canary-implementaties worden eerst uitgerold naar een klein deel van de gebruikers, waarna het verkeer geleidelijk wordt verhoogd zolang de status goed blijft. Op Azure implementeert u canary met:

Azure Front Door gewogen routering om verkeer te splitsen tussen oude en nieuwe backends op de applicatielaag, met health probes en WAF.
Azure Traffic Manager gewogen eindpunten voor DNS-gebaseerde, wereldwijde canaries wanneer u controle op regionaal niveau nodig heeft.
AKS canary via Ingress (bijv. NGINX canary-annotaties) of traffic splitting met een service mesh. Gates moeten foutbudgetten, latentiepercentielen en saturatie beoordelen voordat ze doorgaan.

Rolling updates vervangen instances geleidelijk, waardoor de kosten van een dubbele vloot worden vermeden. Configureer in AKS rollingUpdate met maxSurge en maxUnavailable; zorg ervoor dat readiness/liveness probes en PDB’s de beschikbaarheid beschermen. Gebruik voor VM Scale Sets een ‘rolling upgrade’-beleid met ‘application health probes’. Rolling updates zijn economisch, maar het herstel van systemische regressies is langzamer dan bij blue-green.

Feature flags ontkoppelen de release van de implementatie. ‘Dark launching’ levert codepaden die standaard zijn uitgeschakeld, waardoor de infrastructuur wordt getest zonder functies bloot te stellen. Gebruik flags om dure migraties te bewaken, de UI geleidelijk te onthullen en problematisch gedrag snel uit te schakelen. Dit is een aanvulling op canary en rings: implementeer breed en schakel vervolgens geleidelijk in.

Ring-gebaseerde implementatie formaliseert progressieve blootstelling over cohorten. Definieer ringen zoals R0 (intern), R1 (canary-klanten), R2 (één regio) en R3+ (wereldwijd). De criteria voor promotie moeten objectief zijn: naleving van SLO’s, geen Sev2+ incidenten en acceptabele zakelijke KPI’s. Koppel ringen aan het verschuiven van verkeer (Front Door/Traffic Manager), omgevingscontroles en goedkeuringsgates om vroegtijdig te stoppen of terug te draaien.

Azure Front Door versus Traffic Manager voor progressieve verkeersverschuiving: Front Door werkt op laag 7 met onmiddellijke wijzigingen, health probes, sessieaffiniteit, padgebaseerde routering en gewogen splitsingen—ideaal voor canaries en A/B-testen op de applicatielaag. Traffic Manager werkt op DNS-niveau; het is beter voor geo-routing, cross-cloud failover of canaries op regionaal niveau, maar heeft te maken met DNS TTL-overwegingen en geen functies op de applicatielaag.

Omgevingen, Goedkeuringen en Gates

Azure Deployment Environments standaardiseren de provisioning van dev/test-omgevingen met vangrails. Omgevingsdefinities zijn infrastructure-as-code templates (Bicep/ARM/Terraform) die herhaalbare stacks beschrijven. Definities bevinden zich in catalogi—Git-repositories die bij de service zijn geregistreerd—wat versiebeheerde, vindbare blauwdrukken voor omgevingen mogelijk maakt. Ontwikkelaars kunnen via selfservice dev/test-instances aanmaken binnen de beperkingen van bedrijfsbeleid (quota’s, RBAC, netwerken), waardoor ‘snowflakes’ worden geëlimineerd en lagere omgevingen worden afgestemd op de productietopologie.

Goedkeuringen zorgen voor controles met menselijke tussenkomst waar dat nodig is. In Azure Pipelines:

Pre-deployment goedkeuringen blokkeren een stage totdat aangewezen goedkeurders toestemming geven. Gebruik dit voor risicovolle overgangen, bijv. van staging naar productie of ring-escalatie voorbij de canary-fase.
Post-deployment goedkeuringen bevestigen validatieactiviteiten (UAT-aftekening, auditstappen) voordat de release als voltooid wordt gemarkeerd.
Configureer time-outs voor goedkeuringen zodat verzoeken automatisch verlopen; verlopen goedkeuringen laten de stage mislukken en voorkomen ongecontroleerde ‘drift’. Vereis meerdere goedkeurders of sequentiële goedkeuringen wanneer scheiding van taken noodzakelijk is. Pas goedkeuringen toe op omgevingen en service connections via “Approvals and checks” voor consistente governance.

Release gates dwingen objectief bewijs af vóór promotie. Azure Pipelines ondersteunt controles zoals:

Azure Monitor-controles die metrics of alerts opvragen (bijv. geen actieve Sev2-alerts, foutenpercentage onder de drempelwaarde, p95-latentie onder het doel). Gates worden met een gedefinieerd interval opnieuw geëvalueerd tot succes/mislukking of een time-out.
Invoke REST API-controles om externe kwaliteitsdiensten, loadtests of interne compliance-eindpunten aan te roepen. Parse de antwoorden en blokkeer als niet aan de criteria wordt voldaan.
Work item query-controles om te verzekeren dat vereiste taken, bugs of wijzigingsverzoeken de juiste status hebben vóór de release (bijv. alle “Must Fix”-defecten zijn opgelost). Gebruik query’s die zijn afgestemd op de release of het commit-bereik.

Implementeer gates op de grenzen van ringen en tijdens de canary-fase om over te stappen van subjectieve naar meetbare promotiebeslissingen.

Pipelines voor Meerdere Omgevingen, Variabelen en Afhankelijkheden

Ontwerp YAML-pipelines met meerdere stadia met expliciete afhankelijkheden en omgevingsscoping. Gebruik deployment jobs met strategieblokken (runOnce, rolling, canary) om een progressieve uitrol te modelleren en voeg hooks toe voor preDeploy, routeTraffic, postRouteTraffic en on: failure voor geautomatiseerde rollback. Stadia moeten dependsOn en conditions declareren, zodat latere omgevingen alleen worden uitgevoerd nadat eerdere omgevingen door gates en goedkeuringen zijn gekomen.

Beheer omgevingsspecifieke configuratie via:

Variabelengroepen met een scope per omgeving, gekoppeld aan Azure Key Vault voor secrets. Verwijs naar groepen per stadium en houd gevoelige waarden buiten de broncodebeheer.
YAML-templates en runtime parameters om implementaties over services heen te standaardiseren en omgevingsspecifieke waarden door te geven (connection strings, standaardwaarden voor feature flags, Front Door-weging).
Tokenization- of transformatietaken voor appsettings en Kubernetes-manifesten, om een drift-vrije ‘configuration as code’ te garanderen.

Voor implementaties naar meerdere omgevingen, geef de voorkeur aan onveranderlijke artefacten met promotie (één keer bouwen, vele malen implementeren). Koppel work items aan commits en builds om de traceerbaarheid te behouden terwijl hetzelfde artefact van dev naar prod stroomt, wat nauwkeurige release notes en audits mogelijk maakt.

Rollbackstrategieën en Databaseoverwegingen

Plan rollbacks voordat u live gaat:

Automatische rollback gebruikt statussignalen om terug te draaien zonder menselijke tussenkomst. In AKS, stel maxSurge/maxUnavailable conservatief in en schakel automatische rollback in bij mislukte uitrol; gebruik kubectl rollout undo of vertrouw op de failure hooks van de implementatiestrategie om een vorige ReplicaSet te activeren. In Azure App Service is een slot swap terugdraaien onmiddellijk; combineer dit met health checks en deployment gates om automatisch te beslissen.
Handmatige rollback is geschikt wanneer herstel het oordeel van een operator vereist (datarisico, gedeeltelijke storing). Zorg voor one-click pipelinetaken die de weging van Front Door/Traffic Manager omleiden, slot swaps ongedaan maken of de laatst bekende goede build opnieuw implementeren. Houd het vorige artefact direct beschikbaar en documenteer het beslissingsproces.
Database-rollback vereist extra zorg. Vermijd backward-incompatible wijzigingen. Gebruik de expand-contract-methode: voeg kolommen/tabellen toe en vul deze terwijl lees- en schijfbewerkingen compatibel blijven; implementeer indien nodig code die naar beide schema’s schrijft; verwijder pas later de verouderde elementen. Voor Azure SQL Database, combineer:
- DACPAC of migratieframeworks (EF Core) met idempotente, geversioneerde scripts en pre/post-deployment validatie.
- Online operaties (index rebuilds met resumable, partition switching) om lock-conflicten te minimaliseren.
- Point-in-time restore en actieve geo-replicatie als laatste redmiddel, waarbij het risico op dataverlies wordt erkend. Schakel features uit via flags vóór een schema-downgrade. Maak promoties afhankelijk van de databasestatus (DTU/CPU, deadlocks), vastgelegd in Azure Monitor en Query Store.

Feature Flags met Azure App Configuration en Automatisering van Release Notes

Azure App Configuration centraliseert feature management met SDK’s voor .NET, Java, Node.js en andere. Gebruik labels om vlaggen af te bakenen per omgeving of ring en activeer dynamische vernieuwing zodat applicaties wijzigingen oppikken zonder herimplementatie.

Targeting-filters maken granulaire activering mogelijk op basis van gebruiker/groep, claims, apparaat of aangepaste attributen. Definieer cohorten (bijv. interne tenants, VIP-klanten) om aan te sluiten bij ringen.
Percentage-rollout stelt features geleidelijk bloot aan een willekeurige subset. Begin met 1–5%, valideer KPI’s en voer dit vervolgens op. Coördineer met de weging van Front Door voor gelaagde controle op gebruikers- en verkeersniveau.
Kill switches schakelen een feature onmiddellijk uit wanneer er zich incidenten voordoen. Beveilig risicovolle paden (betalingen, data-schrijfacties) met een globale ‘uit’-schakelaar die geen enkele implementatie vereist om uit te voeren. Log alle schakelacties voor auditdoeleinden en correleer ze met incidenten.

Automatiseer release notes voor traceerbaarheid en communicatie:

Dwing het koppelen van work items af door te eisen dat commit-berichten en PR’s verwijzen naar ID’s. Azure DevOps associeert builds en releases automatisch met work items en commits.
Genereer changelogs in pipelines met de ‘Generate Release Notes’-taak of REST API-aanroepen om wijzigingen en work items op te sommen sinds de laatste succesvolle implementatie naar de doelomgeving. Produceer Markdown met secties voor features, fixes, breaking changes en databasemigraties.
Publiceer de notities naar de project-Wiki, verpak ze als een build-artefact en voeg ze toe aan de release. Voeg implementatiemetadata toe (buildnummer, commit SHA, omgeving, goedkeurders, gepasseerde gates) voor compliance.

Praktijkscenario

Adobe moet een nieuwe personalisatie-engine introduceren op haar marketingwebsites die op Azure worden gehost, zonder de conversieratio’s in gevaar te brengen tijdens piekcampagnes. Het team moet frequent implementeren, de feature progressief blootstellen, SLO’s valideren en onmiddellijk terugdraaien als KPI’s verslechteren.

Definieer omgevingen met Azure Deployment Environments

Maak omgevingsdefinities (Bicep) voor de app, AKS, Azure SQL en Front Door in een catalogus die wordt ondersteund door Git. Ontwikkelaars provisioneren zelf veilig dev/test-omgevingen, wat pariteit met productie garandeert en kortstondige (ephemeral) test-stacks voor experimenten mogelijk maakt. ADE dwingt quota’s en RBAC af om uitgaven en toegang te beheren.

Bouw eenmalig, implementeer meervoudig met multi-stage YAML

Een enkel artefact wordt gepromoveerd door de stages ring-r0, ring-r1, ring-r2 en prod. Stages zijn van elkaar afhankelijk en gebruiken deployment jobs met een strategie: canary en rolling waar van toepassing, wat consistente binaries over de ringen heen garandeert.

Gebruik blue-green met App Service-slots voor de legacy web-tier

Implementeer naar een staging-slot, warm deze op en wissel (swap) vervolgens voor interne gebruikers van ring-r0. Als de SLO’s van Adobe verslechteren, biedt een ‘slot swap back’ de snelste rollback met vrijwel geen downtime.

Introduceer canary via gewogen routering (weighted routing) van Azure Front Door

Registreer zowel de legacy als de nieuwe personalisatie-backends. Begin met 1% verkeer naar de nieuwe backend in ring-r1. De health probes en onmiddellijke gewichtsupdates van Front Door maken veilige, snelle aanpassingen mogelijk die zijn afgestemd op verkeerspatronen.

Beveilig promoties met objectieve controles (gates)

Voeg Azure Monitor-controles toe voor p95-latency, foutenpercentage en conversie-KPI’s afkomstig van Application Insights. Voeg een REST API-controle toe aan Adobe’s interne experimentatiedienst om ‘guardrail’-statistieken te bevestigen. Configureer een ‘work item query’-controle om ervoor te zorgen dat ‘Must Fix’-bugs zijn gesloten voordat naar de volgende ring wordt gepromoveerd. Gates evalueren periodiek en hebben een time-out om vastgelopen wijzigingen te voorkomen.

Vereis goedkeuringen bij kritieke overgangen

Pre-deployment goedkeuringen voor ring-r2 en prod vereisen ‘sign-off’ van marketing en SRE, met een time-out van 4 uur om ‘dangling’ releases te voorkomen. Post-deployment goedkeuringen bevestigen dat UAT en de validatie van analytics zijn voltooid voordat de release wordt afgesloten.

Beheer blootstelling met feature flags van Azure App Configuration

Implementeer ‘dark launching’ zodat de nieuwe engine aanwezig is, maar aanvankelijk uitgeschakeld. Gebruik targeting-filters om de feature in te schakelen voor intern personeel (ring-r0) en geselecteerde klantcohorten (ring-r1). Pas percentage-rollout toe om de blootstelling uit te breiden. Een kill switch schakelt de engine wereldwijd binnen enkele seconden uit zonder herimplementatie als er afwijkingen optreden.

Bescherm data met expand-contract-migraties

Implementeer eerst additieve SQL-wijzigingen, vul data asynchroon aan (backfill) en gebruik ‘dual-write’ waar nodig. Pas nadat de stabiliteit is bewezen, wordt het verouderde (deprecated) schema verwijderd. Gates monitoren DTU, deadlocks en langlopende queries om onveilige promotie te voorkomen.

Automatiseer rollback-paden

Failure hooks op deployment jobs triggeren een rollback: de gewichten van Front Door keren terug naar 0% voor de nieuwe backend; App Service voert een omgekeerde ‘slot swap’ uit; AKS voert kubectl rollout undo uit. Een handmatige ‘one-click’ rollback blijft beschikbaar voor operators voor complexe scenario’s.

Automatiseer releasedocumentatie

De pipeline genereert Markdown release notes van de gekoppelde work items en commits, en benadrukt de ingeschakelde features, databasewijzigingen en de gepasseerde gates. De notities worden gepubliceerd naar de Azure DevOps Wiki en toegevoegd aan de release, wat voldoet aan de eisen voor audit en zichtbaarheid voor stakeholders.

Deze aanpak benut de kracht van elke tool: ADE voor veilige, reproduceerbare omgevingen; YAML-strategieën en goedkeuringen voor een beheerste flow; Front Door en App Configuration voor gelaagde, progressieve levering; Azure Monitor en gates voor objectieve kwaliteitscontrole; en geautomatiseerde rollbacks en release notes voor veerkracht en traceerbaarheid.

← Containerisatie en Kubernetes · Alle domeinen · Beveiliging →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →