Canary Deployment – what is it?
Canary Deployment is an approach to mitigating the risks of a new update to existing software bringing it to production. This is done by sequentially testing without involving users and then involving a small number of users and when it works fine, deploy it entirely.
It is something like releasing a beta version. Deploying a new feature all in sudden is not secure neither for company owners nor for the users. In unleash-hosted, this practices is easiest done by using the gradualRollout activation strategy.
The key idea in a Canary deployment, is to gradually enable your new feature to your users. Initially you probably want to validate the new implementation for a few of your internal testers. Proven okay, the next step would be to enable the new implementation for a handful of your internal users, e.g. all employees of the company. Then the new implementation should gradually be enabled for a larger and larger part of the user population. Each iteration is supported by carefully considering key metrics of the application; performance numbers, reported issues and similar are examples.
Thus, Canary Deployment is the safest way of adding a new feature to existing software.
When and why to use Canary Deployment?
When you have finally made the decision of making changes to your software because it lacks a requirement and you want to add a new feature. This is the right time to use the Canary Deployment technique. Why? Because it proceeds in phases so, it will save you from downtime after the release and delivers a smooth experience to your users.
Advantages
- It saves the software from crashing, down falling traffic during the update.
- Makes the software working perfectly while changes are being implemented.
- Canary Deployment is platform-independent, it can be applied to a website, desktop or mobile application. Unleash-hosted provides SDKs for a large number of programming languages.
- It is also deployable to the cloud and hybrid software solutions.
- This technique allows to observe and carefully consider the metrics about the how update is impacting the production and users.
- The deployment can be reversed safely if some issues occur.
Disadvantages
One disadvantage of utilizing canary deployment is that you need to deal with different variants of your software simultaneously. You can even choose to have multiple renditions running in production simultaneously, be that as it may, it is ideal to downplay the number of contemporary changes.
Another situation where utilizing canary deployment is difficult, is the point at which you disperse software that is introduced in the clients’ PCs or cell phones. For this situation, you have less command over when they move up to the new version.
Contemplating the changes in the database is highly complicated in canary deployment.
Typical Canary Deployment Strategies
The fundamental complication of canary deployment is to devise an approach to direct a few clients to the new application. Likewise, a few applications may consistently require a similar gathering of clients for testing, where others may need an alternate gathering without fail.
Adopt the following strategies
- Dispose of the canary deployment to the internal users first and then head towards external users
- Assign the routing on the bases of IP addresses
- Launch the new version in specific geolocation in the world
- At first, make use of an app logic to introduce a new version to a particular group of users. Test it and remove the logic when the application is all set to launch entirely.
Implementing Canary deployment using Unleash
- Step 1 is to create a new Feature toggle in unleash-hosted, and use the UserWithId activation strategy. In the management view of unleash-hosted, define the users that shall have access to the newly deployed feature.
This will enable the new feature only for the listed users. NB! The users defined in the management view has to be available in the context where the unleash SDK is running.
- Step 2 is to enable the feature for 1% of the user population. In unleash-hosted, the gradualRollout activation strategy is used. In this example I’m using the gradualRolloutUserId activation strategy. This strategy will include the UserId in the hash to make sure that the same user get a consistent behaviour during the Canary deployment. What this means, is that if a user visits the same site multiple times over the days or weeks when the new feature is being rolled out, the user will always get or not get access to the feature – as long as the rollout percentage is not changed. Use the glider to set the proper percentage – in the example below, the activation is set to 1%
- Step 3 is to validate the metrics chosen to confirm that the implementation is as expected. Please use your favorite Application monitoring system for this step.
- Step 4 is to gradually increase the percentage and repeat step 3.
Six Best Canary Deployment Practices
- Continuously use canaries (deploy in phases)
- Consider the suitable time for implementing Canary
- Abstain from concentrating canaries on anomalies in your administration pool
- For basic administrations, implement more canaries (phases) and screen them for longer periods
- Your canary procedure should cover 5% to 10% of your administration’s burden
- Your canary deployment coverage ought to be little enough that total disappointment of the underlying canary set won’t overpower the rest of the working
Bottom Line
Canary deployment saves software solutions from crashing while upgrading them to a new version. This approach is a win-win situation for the development company and the users. It does not affect the user experience and saves the business for application owners.
