Deploying is not the same as releasing
A deployment puts new code on servers; a release exposes it to users. Keeping the two apart lets you ship often while staying in control of the risk.
Canary release with automated health checks
- 5%
- 25%
- 50%
- 100%
Share of user traffic per version
≤ 1%
≤ 300 ms
New version deployed, not yet receiving traffic
Four strategies, each for a different situation
They can be combined: a canary release behind a feature flag is common. The choice depends on your architecture, your traffic and how your users are organized.
Blue-green deployment
Two identical production environments. The new version is deployed to the idle one and verified, then all traffic switches over at once. Switching back is just as fast.
- Best for
- Web apps and APIs where a quick, complete rollback matters most.
- How I usually implement it
- Azure App Service deployment slots with a slot swap, or two back ends behind Azure Front Door or Application Gateway.
Canary release
The new version first receives a small percentage of traffic. Health metrics decide whether that share grows or is withdrawn.
- Best for
- Services with enough traffic and good telemetry to judge a small sample.
- How I usually implement it
- Traffic splitting between App Service slots or Azure Container Apps revisions, or weighted origins in Azure Front Door.
Deployment rings
Users are grouped in rings, for example the project team, then a pilot department, then everyone. Each ring is a chance to catch issues with a limited audience.
- Best for
- Internal business applications, including Dynamics 365 roll-outs, with clearly separated user groups.
- How I usually implement it
- Separate environments or security groups per ring, promoted by pipeline stages with an approval between rings.
Feature flags
New functionality is deployed switched off and turned on per user group when the business is ready, without a new deployment.
- Best for
- Separating the business go-live date from the technical deployment.
- How I usually implement it
- Feature management in Azure App Configuration; in Dynamics 365, environment variables or configuration records checked by the code.
Planning the way back
Every release strategy is only as good as its rollback. I agree on it with the team before the release, not during the incident.
- Decide in advance how a release will be rolled back, and test that path in a lower environment.
- Keep database changes backward compatible (expand first, contract later) so the previous version still works after a rollback.
- Trigger the rollback automatically on clear health signals instead of waiting for a meeting.
- For Dynamics 365 solutions, going back usually means fixing forward with a new version, which makes small releases and good test coverage even more important.
- Give every release window a clear owner and publish short release notes, so support knows what changed.