How to do Canary Release / Progressive Delivery with ConfigCat
Tags: devops, configcat, featureflag, webdev
Published: 2022-02-16 10:42:51

In this post, we’ll look at how we can easily implement a canary release of a feature in 7 steps using ConfigCat’s feature flagging service through its provided dashboard.

This step-by-step guide will showcase how we can release a new feature incrementally, by first exposing it to low-risk user groups (e.g. team members and possibly friends), and then gradually releasing it to a larger audience - using [ConfigCat](https://configcat.com), a feature flag service to implement everything.


So let’s get right to it. The assumption is that we have logged into our ConfigCat’s dashboard and successfully implemented an instance of a feature flag named “Facebook Sharing Enabled” in our application.

## Step 1 - Unreleased State
![Unreleased State](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cr980fjqt0d3835paubb.png)
We’ll take it from the start, where we have our feature flag set up and initially toggled off for all users.

## Step 2 - Releasing Only to Team Members
![Releasing to Team](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6xdliixi5d7wtwywyljw.png)
Following that, we need to release the feature to only team members. This allows you to get immediate feedback from your team.

## Step 3 - Releasing to Team Members and Friends
![Releasing to team and friends](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/s6tuf0vjuxhhgrfwj92e.png)
Afterwards, we proceed to include friends or people in your circle that you have a good relationship with in the feature’s release by having it available to only team members and these people. This allows you to get feedback from real users who will be cooperative with you.

## Step 4 - Releasing to 1% of Users - But No Sensitive Users
![Releasing to 1%](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6j1ctdz0h074hynam6no.png)
If more feedback is needed, the next step would be to have it released to random people, say 1% of users - making sure to exclude the most risky users (i.e those with high expectations and a lot of money). In the screenshot, we’ve targeted those users from the United States as our sensitive users.

## Step 5 - Releasing to 5% of Users - But No Sensitive Users
![Releasing to 5%](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jco0oyexss6xp3nrjvzz.png)
Now, we proceed to release it to even more random people - say 5% of users, but still excluding any sensitive users. Now we have our feature available to team members, friends, and 5% of our user base - excluding sensitive users.

## Step 6 - Releasing to Everyone Except Sensitive Users
![Releasing to everyone but sensitive users](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/g6u08octgj4y57z5gscc.png)
The next step is to have the feature available to everyone except our sensitive users. At this point, enough confidence has been gained from the received feedback to test it on everyone. The next step is to have the feature available to everyone except our sensitive users.

## Step 7 - Releasing to Everyone
![Releasing to everyone](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3lws5pfkwksfdhczteqe.png)
If all errors have been fixed, UI-glitches corrected, and all the test users are happy with the feature then it’s finally safe to release it to our entire user base - including the sensitive users.

## Conclusion

As we have seen, implementing a canary feature release is no rocket science, especially when using [ConfigCat](https://configcat.com) as it provides a feature management service, with an easy to use dashboard that makes it convenient and intuitive to do just that. Even a non-technical team member can handle canary releases with ConfigCat’s 10 minutes trainable feature flag and configuration management service.