Canary Deployment Strategy

This strategy is best for letting the users do the testing!

Canary deployment is a technique to reduce the risk of bringing in a new software update in production by slowly rolling out the change to a small subset of users before allowing everyone to access the software.

In simpler words, it is the practice of making staged releases. The basic idea is to roll out a software update to a small part of users first, so they may test it and provide feedback. Once the change is accepted and made, the final update is rolled out to the rest of the users. In a typical Canary deployment, traffic to an environment is incrementally updated in small phases, with each phase requiring verification to proceed to the next phase.

Stages of Canary Deployment!

In a typical Canary deployment, traffic to an environment is incrementally updated in small phases, with each phase requiring verification to proceed to the next phase. Canary deployment has three stages which include,

Plan and Create The first stage involves building a new canary infrastructure where the latest update is deployed. Some part of the traffic is sent to the canary instance, while most users continue to use the baseline instance.

Analyze Once some traffic is diverted to the canary instance, the team collects data: metrics, logs, information from network traffic monitors and results from synthetic transaction monitors to identify and determine whether the new canary instance is working as it should. Then, the team analyses this data and compares the result to the baseline version.

Roll After the canary analysis is completed, the team decides whether to go ahead with the release and roll it out for the rest of the users or roll back to the previous baseline state for fixing the issues.

BuildPiper Canary Workflow

Here’s how BuildPiper triggers the Canary deployment. The complete execution of BuildPiper Canary Workflow involves these simple steps. Take a look!

• Sign in to the BuildPiper user portal.
• Go to the Canary template section.
• Click on “New Canary Template” to create a new custom canary template.

• Give a name to the template created.
• Add different phases for traffic shifting in the template.

• Specify the configuration of various phases. Choose the Next Phase trigger type: either Manual or Automated. BuildPiper provides these two options to trigger the next phase of the canary deployment.
• Manual Trigger: Here, the users need to manually trigger the next phase of the canary deployment while it is in progress.

• Automated Trigger: Here, the users can define a time duration after which the next phase of the canary template will automatically get triggered.
• Mark the percentage of traffic shift to the Canary deployment.
• Add different phases to the Canary template specifying the percentage of the traffic shift during each phase, if needed.

• Finally, click on the “ Submit” button after adding the phases to the canary template.
• Click on the “Deploy Details” section to attach the canary template to the deployment strategy.
• Choose “Yes” to trigger the Canary deployment.
• Select the canary template that needs to be attached to the canary deployment and view the complete deploy details.

• Choose "Canary" to enable Canary strategy for deployment.

• Give a custom build tag to the services and then click on the “Deploy” button.
• Finally, view the initial canary traffic shift between V1 and V2 on the deployment monitor/dashboard section.

Advantages of Canary Deployment!

The benefits of Canary Deployments include,

• You can test the new version with real users.
• Identify bugs or performance issues before releasing them to a wider audience.
• In case of failure, only a small number of users get affected.
• Minimal infrastructure requirement especially when you use a feature flag.
• Rollback is simple and quick.