In this post, I will share my study notes that I took while preparing for the exam Azure AZ400 “Plan the deployment environment strategy”.
Design a release strategy (blue/green, canary, ring)
Deploying code can be risky.
Depending on the business model, deployment can produce downtimes that might cost money.
To mitigate risk, it is possible to implement the best possible release strategy.
All these strategies target to release code in a controlled way and they leverage on making a release easy to roll back or on releasing the code to targeted subsets of users or a targeted subset of machines.
The blue-green deployment approach does this by ensuring you have two production environments, as identical as possible. At any time one of them, let’s say blue for the example, is live. As you prepare a new release of your software you do your final stage of testing in the green environment. Once the software is working in the green environment, you switch the router so that all incoming requests go to the green environment — the blue one is now idle.
Databases can often be a challenge with this technique, particularly when you need to change the schema to support a new version of the software. The trick is to separate the deployment of schema changes from application upgrades. So first apply a database refactoring to change the schema to support both the new and old version of the application, deploy that, check everything is working fine so you have a rollback point, then deploy the new version of the application. (And when the upgrade has bedded down remove the database support for the old version.)
One of the goals that my colleagues and I urge on our clients is that of a completely automated deployment process…
Canary deployments, Rings
With rings, we evaluate the impact, or “blast radius,” through observation, testing, diagnosis of telemetry, and most importantly, user feedback. Rings make it possible to progressively deploy…