Kubernetes is great for running a lot of different containers at scale, and those containers contain code that is constantly changing, and when there’s a lot of change, there are a lot of risks involved too. Reducing these risks is important to enabling teams to ship product updates and features constantly. Canary deployments will help reduce your environment downtime and release more features quickly to the market. Canary deployment can be based on different factors as demographic data, usability, and stack.

Today, we’ll talk about how to reduce these risks using the pattern of canary deployments and introduce the ways you can put this into practice on your workloads.

In this blog, we’ll look at the following:

  • What is a Canary Deployment?
  • How to deploy your first Canary
  • Working with CTO.ai Service Previews

Introduction to Canary Deployments

Canary deployment is a process where you deploy a new feature and some percentage of traffic on the new feature you deployed. It is the practice of making stage releases where the team rolls out the update to a small number of users first so that the users can test it and provide feedback. Once every change and product update is accepted by all the relevant stakeholders, we roll out the update to the rest of the users. In canary deployments, you can use stable tags to tag your images and deploy new features to customers.

A canary release is an early bird of the application splitting stable and development branches and where companies publish a canary version of their application or product and let the platform power users download and try it out. In contrast, in a canary deployment, we split the users into two groups. A small percentage of these users are going to go to Canary, while the rest users stay on a stable version. In the long run, we can decide whether to roll everyone to the canary deployment or roll back everyone to a more stable version.

How does Canary deployment work?

Canary deployment involves running two application versions simultaneously, where the old version is the stable version, and the new version is the canary version. In deploying your updates, you can use rolling deployments or side-by-side deployments.

  • In a rolling deployment, we install the changes in phases or stages on your instances or servers simultaneously, and your other services, ingress components, or servers continue running the stable version. Rolling deployment is the most common and straightforward way to do a canary deployment, as we are rolling out the new deployment so some groups of users. As soon as the canary runs on one instance, or ingress server component, a few users begin seeing the new updates. As your engineering team grows confident in ensuring every package, component, and feature works in the canary release, they can install it on other servers until all machines, servers, and services run the latest release.
  • Side-by-side deployments: Side-by-side deployments involve the team rolling out a new set of new releases and features to a subset of users using a new or duplicate environment. In the new environment, we’ll create a new development environment and attach the new canary version for users to test and provide feedback. For instance, if the application runs on multiple instances or containers, services, different databases, and endpoints to make the deployment in this scenario, we’ll create a duplicate-like on the service components' resources and install the updates. Once the canary is running in the new environment, we’ll show it to a group of users to get their feedback. Once the deployment is complete, the engineering team will remove the former application environment to free up resources, and the canary version is now the new stable version.

Configuring the Canary

Configuring and deploying a new version of your application is very important to your development lifecycle. In deploying your new version to a subset of users, you have to plan and prepare for downtime if it happens.

When configuring a Canary deployment, you should take note of the following:

  • Stages: How many users do you want to send to your Canary environment first, and in how many stages? In canary deployment, you might only want to send your updated version to your enterprise clients or the customers in the EMEA region. You must determine the number of users this release will be on and prepare for their feedback.
  • Time period: How long are you planning to run the Canary? In some cases, Canary deployments usually run for minutes or hours, as Canary releases can take days or weeks. You must identify and plan the exact time duration of releases and understand when to roll back changes to your previous stable version.

  • Deployment Insights: How do you want to measure your deployment success? You can measure your deployment frequency rate and recovery using DORA Metrics. CTO.ai insights help you prevent failures by understanding the impact of your change by creating a feedback loop, so deployment incidents or insight failures don't happen again and be assured they’re hitting certain benchmarks.

Deploying your first Canary on the Developer Control Plane

Using our Developer Control Plane, you can deploy your first Canary using our platform workflows. With Service preview apps, you can generate a unique URL for specific changes to show enterprise or existing customers, as this doesn’t affect your initial deployment or platform configuration.

Here is a sample demonstration of deploying your first Canary using CTO.ai Service Preview. To enable Service previews, add the service section in your ops.yml file.

services:
 - name: canary-deployment:0.3.4
   description: preview of sample app
   run: node index.js
   port: [ '8080:8080' ]
   domain: ""
   env:
     static:
       - PORT=8080
       - DB_HOST=localhost
       - DB_PORT=3600
       - DB_USER=fake
     secrets:
       - SLACK_SIGNING_SECRET
       - SLACK_BOT_TOKEN

   events:
    - "github:github_org/github_repo:pull_request.opened"
    - "github:github_org/github_repo:pull_request.synchronize"

   trigger:
    - build
    - publish
    - start
  • In your GitHub repository, change or edit your existing codebase and open a Pull Request.

  • Back in your CTO.ai dashboard, click Services, and you’ll see that your Service Preview Apps is running, and click on View.

  • Next, a unique URL will be generated in your browser, and you’ll see the new and latest changes in your application.

Conclusion

Canary deployment is a pattern that allows you to roll out code, features, and changes to an initial subset of users or customers; with CTO.ai service preview, you can continuously keep your code in a deployable state at all times and automate the process of getting it into the hands of real customers through progressive rollouts.