Uitrollen is niet hetzelfde als releasen
Een deployment zet nieuwe code op servers; een release stelt ze open voor gebruikers. Door die twee te scheiden, kunt u vaak opleveren en toch het risico onder controle houden.
Canary release met automatische health checks
- 5%
- 25%
- 50%
- 100%
Aandeel gebruikersverkeer per versie
≤ 1%
≤ 300 ms
Nieuwe versie uitgerold, nog zonder verkeer
Vier strategieën, elk voor een andere situatie
Ze zijn te combineren: een canary release achter een feature flag komt vaak voor. De keuze hangt af van uw architectuur, uw verkeer en hoe uw gebruikers georganiseerd zijn.
Blue-green deployment
Twee identieke productieomgevingen. De nieuwe versie wordt op de inactieve omgeving uitgerold en gecontroleerd, waarna al het verkeer in één keer overschakelt. Terugschakelen gaat even snel.
- Meest geschikt voor
- Webapps en API's waarbij een snelle, volledige rollback het belangrijkst is.
- Hoe we het meestal aanpakken
- Deployment slots in Azure App Service met een slot swap, of twee back-ends achter Azure Front Door of Application Gateway.
Canary release
De nieuwe versie krijgt eerst een klein percentage van het verkeer. Health metrics bepalen of dat aandeel groeit of wordt ingetrokken.
- Meest geschikt voor
- Diensten met genoeg verkeer en goede telemetrie om een kleine steekproef te beoordelen.
- Hoe we het meestal aanpakken
- Verkeer verdelen tussen App Service-slots of revisies in Azure Container Apps, of gewogen origins in Azure Front Door.
Deployment rings
Gebruikers worden in ringen ingedeeld, bijvoorbeeld eerst het projectteam, dan een pilootafdeling en daarna iedereen. Elke ring is een kans om problemen bij een beperkt publiek op te vangen.
- Meest geschikt voor
- Interne bedrijfsapplicaties, ook Dynamics 365-uitrollen, met duidelijk gescheiden gebruikersgroepen.
- Hoe we het meestal aanpakken
- Aparte omgevingen of securitygroepen per ring, doorgezet via pipelinefasen met een goedkeuring tussen de ringen.
Feature flags
Nieuwe functionaliteit wordt uitgeschakeld uitgerold en per gebruikersgroep aangezet zodra de business klaar is, zonder nieuwe deployment.
- Meest geschikt voor
- De zakelijke go-live loskoppelen van de technische deployment.
- Hoe we het meestal aanpakken
- Feature management in Azure App Configuration; in Dynamics 365 omgevingsvariabelen of configuratierecords die de code controleert.
De weg terug plannen
Een releasestrategie is maar zo goed als haar rollback. Die spreken we af vóór de release, niet tijdens het incident.
- Beslis vooraf hoe een release wordt teruggedraaid, en test die weg in een lagere omgeving.
- Houd databasewijzigingen achterwaarts compatibel (eerst uitbreiden, later opruimen), zodat de vorige versie na een rollback nog werkt.
- Start de rollback automatisch op duidelijke health-signalen in plaats van op een vergadering te wachten.
- Bij Dynamics 365-solutions betekent teruggaan meestal vooruit herstellen met een nieuwe versie, waardoor kleine releases en een goede testdekking nog belangrijker worden.
- Geef elk releasevenster een duidelijke eigenaar en publiceer korte release notes, zodat support weet wat er veranderd is.