Deployment is not a release; a step-by-step example with feature flags

Feature Deployment and its release to customers have been coupled together for a long time now. As an effective software engineer, it is very important to separate deployment and release. Each deployment should not necessarily release a new version of the software. Do you want to know how to dissociate software release and deployment? In this post, we will look into a practical example of how to separate your technical software deployment process from a feature release process that the business can decide to perform independently using feature flags. Let’s get going!

Photo by Vladislav Klapin on Unsplash

Why use feature flags?

Feature flags (also referred to as feature toggles or feature switches) are a handy technique used by software teams to enable or disable product functionality without changing any code. Feature flags can be achieved by using a simple `if else` statement to using a full-on feature flag as a service like Flagsmith. Even though it adds complexity, the unparalleled flexibility and safety provided by feature flags are great reasons to utilize them.

With feature flags, software teams can deploy new features making them available to a defined subset of users. This subset can be a single user or 90% of the customer base. Even if things go wrong, feature flags make the blast radius a lot smaller which makes the damage, if any, minimal and potentially negligible. On the bright side, the code is in production and if it works for one user it can very well work for more users and use cases.

Advantages of feature flag

There are numerous advantages to using feature flags in production for software engineering teams, some of them include:

1. Ability to test a feature on production end to end with a select subset of users.
2. Easily add or remove users who can get access to the features.
3. Power to catch bugs in production without affecting customers. Even though a feature might be tested multiple times by multiple teams some bugs do slip into production. Feature flags can substantially reduce the blast radius even if this happens.
4. It is much easier to manage code as all the code can land into the main branch, it will get deployed but the new feature is only accessible to a predefined set of users.
5. An added benefit of experimenting with a feature to a whitelist of users for fast feedback.

Example: Add an advert block to a blog

With all of these great advantages of feature flags in our minds, let’s look at a simple and practical example of showing an advertisement block on a blog. We will not do any user segmentation for this tutorial as it is a blog open to all and doesn’t need any user registration or login. We will do this by creating a feature flag on Flagsmith.

Create the feature flag on Flagsmith

To create a new feature flag on Flagsmith, first, we will need to login to Flagsmith. To login to Flagsmith, please head to its login page:

Then click either “GitHub” or “Google” to log in, yes it is that simple. Then authorize Flagsmith with the login provider and we should be logged in to Flagsmith as below:

Now we will add our “Blog” project which has no ads till now and our feature flag will show and hide the ads block without the need of a deployment a.k.a any code changes. We will create a project named “Our Blog” for this demo as follows:

Subsequently, Flagsmith will automatically create “Development” and “Production” environments for us.

Next, we will click the “Create Your First Feature” button and create our “show_ads” feature flag as below:

After we click the “Create Feature” button our feature flag is created on both Development and Production environments.

We will leave the feature flag off for now. We can already look at the sample code on Flagsmith and test what response we can expect when calling the flag in the “Try It Out” section:

For the next part, we will add the feature flag code in our blog.

Add the feature flag code to the blog to show/hide Ads

We are taking a usual programming blog for this tutorial. We will not go into the details of how the blog is built. We will use client-side JavaScript to implement the feature flag code. Currently, there are no ads, on the blog’s sidebar. It looks something as follows:

We can view the blog before the Ads in this preview link too. Next we will add the following code in the Ad block after adding the Flagsmith javascript in the head of the HTML. To show our Carbon ads we need to add a script inside the div we want to show the ad in, let’s see how it is done:

This is plain HTML and client-side JavaScript you can adapt to any framework or Content Management System (CMS) of your choice. Time to quickly analyze what the code is doing.

1. We check if the feature is turned on in Flagsmith with `flagsmith.hasFeature(“show_ads”)`
2. If the feature is on, we do a console.log for our own debugging purpose
3. Then we assemble another script element with `src` pointing to the right Carbon Ad
4. Lastly, we append this script into our div with the id “ads” which will show the ad if the feature flag is on.
5. If the feature flag is off, we never reach inside the `if` statement meaning the ad will not be shown.

You can view the related code changes in this commit on GitHub too. Time to deploy the changes. After the changes are deployed and we visit the blog it will look the same. Next, we will enable the feature flag on Flagsmith like below:

After the change is confirmed our “show_ads” feature flag will be in the “On” state. If we check the deployed code when the flag is on we will see something like the below:

Hurray! Our feature flag is working fine. If we turn off the flag and refresh the page we will see a sidebar without the ad. I will keep the flag turned on if you want to view the sidebar with the ad on it.

Next Steps

This was a quick way to get a feature flag working with Flagsmith. If you want to go to production with this or similar kind of feature flags use the “Production” environment. The only difference is the `environmentID` variable in the script which can be easily injected with an environment variable in your deployment script.

This tutorial is a fast way to test out how you can leverage feature flags and Flagsmith to get your feature flags up and running quickly. Better ways to do it would be to create users, traits, and segments to serve a new feature to a target group with feature flags. Every major feature should be behind feature flags.

Conclusion

We have seen a good way to get started with Feature flags in a very quick time and with low effort. The main thing to understand here is to decouple your technical deployment process from the business-led feature release process. With this newfound power, you may even want to delete your staging environment, I will leave that decision up to you.

Make your software system live ready and let the business people, mainly the product owners decide if they want to release the new feature to one user or million users. Give them the switch, the magic switch of feature flags and roll out features without the need to deploy any code changes, happy feature flagging!