Deploymentslots en swappen

Implementatiesites zijn actieve, afzonderlijke omgevingen voor een App Service-webapp, elk met een eigen hostnaam (bijvoorbeeld myapp-staging.azurewebsites.net). Sites delen hetzelfde App Service-plan en dezelfde resources als de productiesite, maar worden onafhankelijk uitgevoerd. Ze maken blue-green-implementaties mogelijk — je valideert een nieuwe release in een testsite en wisselt die vervolgens zonder downtime om naar productie. Sites zijn beschikbaar vanaf de Standard-laag.

Voeg via Azure Portal of de CLI een nieuwe implementatiesite toe aan je webapp. Elke site krijgt een eigen URL, applicatie-instellingen en verbindingsreeksen. Je kunt maximaal 5 sites maken in de Standard-laag en maximaal 20 sites in de Premium-laag. Veelgebruikte sitenamen zijn staging, canary, hotfix en integration, die verschillende fasen van de releasepijplijn aanduiden.

Voordat je sites omwisselt, is het belangrijk om de testsite op te warmen, zodat de nieuwe versie volledig is geïnitialiseerd. Een koude App Service-instantie verwerkt de eerste aanvragen traag terwijl de runtime wordt geïnitialiseerd, en dat is onaanvaardbaar in productie. Schakel Auto Swap in of stuur handmatig HTTP-opwarmingsaanvragen naar de testsite. App Service ondersteunt ook een applicationInitialization-configuratie om opwarmingspaden te definiëren die 200 moeten retourneren voordat de site als gereed wordt beschouwd.

Bij een swap worden de testsite en productiesite atomair omgewisseld. Tijdens een swap leidt App Service het verkeer eerst naar de testinstanties waarop de nieuwe code draait en wacht het tot deze zijn geïnitialiseerd. Daarna wordt al het productieverkeer omgeleid naar de nieuwe instanties en worden de oude productie-instanties de nieuwe testsite. Hierdoor is terugdraaien eenvoudig — voer gewoon opnieuw een swap uit.

Applicatie-instellingen kunnen worden gemarkeerd als sitegebonden (specifiek voor een site) of niet-sitegebonden (worden omgewisseld). Niet-sitegebonden instellingen gaan met de implementatiesite mee wanneer je sites omwisselt — de verbindingsreeks voor je stagingdatabase volgt de code dus naar productie. Sitegebonden instellingen blijven ongeacht swaps bij de site — productie behoudt altijd de verbindingsreeks voor de productiedatabase. Markeer instellingen als sitegebonden met het selectievakje 'deployment slot setting' of via de CLI.

App Service ondersteunt het verdelen van verkeer: een percentage van het productieverkeer wordt naar een niet-productiesite geleid zonder een volledige swap uit te voeren. Hiermee kun je canary-releases uitvoeren, waarbij je het verkeer geleidelijk verschuift van 5% naar 10% en vervolgens naar 50% naarmate je meer vertrouwen krijgt in de nieuwe release. Gebruikers die op de canarysite terechtkomen, ontvangen een sticky-cookie waardoor ze voor consistente sessies op dezelfde versie blijven.

Auto Swap wisselt een testsite automatisch om naar productie zodra er nieuwe code naar is geïmplementeerd. Dit is ideaal voor CI/CD-pijplijnen waarin je elke geslaagde implementatie onmiddellijk live wilt zetten. Auto Swap wacht totdat de HTTP-aanvragen van de testsite 200 retourneren voordat de swap wordt voltooid. Schakel dit per site in via de portal of CLI — maar wees voorzichtig, want er is geen handmatige goedkeuringsstap tussen implementatie en productie.

Volg deze aanbevolen werkwijzen voor implementatiesites: valideer altijd in staging voordat je naar productie omwisselt, gebruik sitegebonden instellingen om de databaseverbindingen van productie gescheiden te houden van staging, voer na de implementatie smoketests uit tegen de URL van de testsite, configureer paden voor statuscontroles zodat App Service de swap niet voltooit als de nieuwe versie ongezond is en voorzie je implementaties van tags, zodat je kunt traceren welke commit in elke site actief is.

In een typische CI/CD-pijplijn compileert en test de bouwfase de code, pusht de implementatiefase het artefact naar de testsite, voert een integratietestfase geautomatiseerde tests uit tegen de staging-URL en wisselt de swapfase staging om naar productie — eventueel na een handmatige goedkeuring. Dit patroon wordt standaard ondersteund in zowel Azure Pipelines als GitHub Actions met de App Service-implementatieactie.

Bewaar tijdens en na een site-swap de belangrijkste metrische gegevens in Azure Monitor om te bevestigen dat de nieuwe versie gezond is. Let op pieken in HTTP 5xx-fouten, de gemiddelde reactietijd en het CPU-/geheugengebruik. Stel waarschuwingen voor metrische gegevens in die worden geactiveerd wanneer foutpercentages een drempel overschrijden — zo krijg je een signaal om snel terug te wisselen. De slimme detectie van Application Insights kan je na een implementatie automatisch waarschuwen voor afwijkingen.

Implementatiesites hebben de voorkeur boven volledig afzonderlijke App Service-apps voor staging en productie, omdat sites hetzelfde plan delen (geen extra kosten), omwisselen met één klik en terugdraaien ondersteunen, verkeer kunnen verdelen en onder dezelfde App Service-resource worden beheerd. Gebruik alleen afzonderlijke apps wanneer staging fundamenteel verschillende plan-SKU's, isolatievereisten of volledig afzonderlijke facturering nodig heeft.

In deze les heb je geleerd dat implementatiesites geïsoleerde omgevingen bieden voor blue-green-implementaties, dat sitegebonden instellingen omgevingsspecifieke configuratie (zoals database-URL's) aan de site koppelen in plaats van aan de code en dat je met verkeersverdeling canary-releases kunt uitvoeren door een percentage van het productieverkeer naar een nieuwe versie te leiden. Hierna bekijken we automatisch schalen en aangepaste domeinen.