Previous
¶ Grayscale Release
¶ What it is
Grayscale release (also known as Canary Release) refers to a release process involving a smooth transition. Gray is between white and black. Only a small group of users will be affected by this release, while most users are still using the stable version. After assessing the update's performance, if the result is good enough, all the users will gradually be 100% switched to the new version. That’s the end of a grayscale release.
¶ Why it is useful
Grayscale publishing can ensure the stability of the overall system. Problems can be found and adjusted at the initial grayscale to secure their influence. It can be easily switched back to the stable version if the test result of the grayscale release is not ideal. This guarantees the user experience of a grander scale of users and helps the product team understand the potential issues very quickly.
¶ When to use it
After a product is live, the grayscale release method can be adopted when there are updates that the production team is not confident enough to open for all users.
¶ How is it done
- Prepare the artefacts for each deployment stage, including build artefacts, test scripts, configuration files, and deployment manifest files.
- Remove the canary server from the load-balancing list
- Upgrade the "canary" application (cut off the original traffic and deploy)
- Automated testing of applications
- Add the canary server back to the load balancing list (connectivity and health check)
- If the online use test of Canary is successful, upgrade the remaining servers (otherwise, roll back)
¶ Do's & Don't
Do's
- Roll out releases with small numbers of users first (a percentage of the userbase - e.g., 1% or 5%).
- Increase the coverage gradually after the first batch of customers has used it, and you see the results.
Don't
- Don’t scale up too slowly. You can go from 1% to 5% to 20% to 100%; no need to go 1% by 1%.
¶ Tools needed
¶ Example
