Enable or Disable Functionality without Deploying the New Code Using Feature Flag

Introduction

A feature flag is a development process/ pattern used to enable or disable functionality ever without planting code. It’s the way to control the behavior of your software or application without needing to redeploy or change the code.

Feature flags allow the release of a new feature in your platform with zero downtime. We can control this feature flag with the help of configuration files, or it can be more remote for example you can use a service like azure app config.

Feature flags may be used to perform a “soft rollout” of new product features. New features can be quickly integrated and built into feature switches as part of a planned release. Feature flags can be set to “off” by default, so after deployment, the code will remain dormant in production, disabling new features until a feature switch is explicitly enabled. The team then decides when to turn on the feature flag. This activates the code so the team can perform QA and make sure it’s working as expected. If the team finds a problem during this process, they can immediately turn off the feature flag to disable the new code and minimize user exposure to the problem.

The feature flag can be used to isolate new changes while preserving known stable code. This allows developers to avoid long-running feature branches, which are often locked into the main branch of the repository behind feature toggles. Once the new code is ready, you don’t need disruptive collaborative merge-and-deploy scenarios. Teams can toggle feature flags to enable new systems.

In its simplest form, a feature flag acts as a toggle between the “on” and “off” states of a feature. When a developer launches a new product feature, they create a corresponding new Git branch that contains all the code for the new feature, unlike the main branch. When a developer completes a new feature, they merge the feature branch into the main branch and deploy it. Feature branches are different from feature flags.

Feature flags are allowed on feature branches. To create a feature flag, a developer creates a feature branch and commits a new feature flag code to the feature branch. After instrumentation, the feature branch is merged and deployed, and the feature flag is accessible in the production.

What kind of things can go wrong during a deployment, where a feature flag can help?

These are some examples:

• Changing database queries can slow down existing functionality.
• Changes in the logic of existing features can produce unexpected behavior, edge cases not considered, and more.
• Changes in how we store or process information, such as saving new columns in the database can accidentally start inserting invalid values or generate too many writes to the database.

Cons of Feature Flag

1. Feature switches introduce additional complexity to your code by adding additional conditions and behavior variations, or by adding additional routing rules and configuration logic.
2. Feature switchers with multiple components significantly increase cognitive load. Thinking about two or more components and how their different configurations interact is much more difficult than thinking about a single component.

         Combinatorial explosion:

3. Once teams start using feature toggles, sooner or later there will be many. I highly recommend managing some features, so you know when to remove specific toggles and appropriate code and tests.
4. Another nasty effect of multiple feature toggles occurs when they start interacting. You could end up in a combinatorial explosion situation of state switching. Effectively, you are creating a multitude of system configurations. Having automated tests for each configuration becomes much harder.
5. When you have a lot of feature toggles, but you are not sure you can turn it off anymore, will the application still work? In that situation, you are kind of dependent on a certain state of that toggle, and when that time comes then there’s a time to start cleaning up that and remove the dead code and make sure that you kind of only execute the code that you want to execute.

Cost of Feature Flag

• As we have seen, using feature flags extensively changes the way we work and requires a bit of additional planning and coordination. But there are also additional costs associated with feature flags that we need to keep in mind. First, we have a runtime cost. When we check if a feature flag is enabled to an actor, we need to first load the metadata information of the flag, which is stored in MySQL but cached in Memcached. We are currently looking at keeping feature metadata and the list of actors in memory all the time to reduce this overhead. There is one exception to this. Some feature flags are considered “large”. An example of this was GitHub Actions, a feature that we rolled out to tens of thousands of users every week. For these large feature flags, when they are still not fully enabled, we need to do a per-actor query to MySQL to check if the actor is in the list of enabled actors.
• For runtime, there’s also a cost in the form of technical debt. Once a feature flag is fully enabled, it leaves a lot of dead code and old tests in the repository that needs to be deleted. Usually, we do this manually after a feature has been rolled out for a few days or weeks depending on the case. But now we are automating the process. We have created a script that can trigger and call the workflow locally or manually.

Testing Feature Flag using 2 Products

Here, I have used one product named Flagsmith it’s a feature flag service that also has an open source version we can host on our own.

Here I have created the “show_landing_page” feature-flag and made it off by default.

So, in the UI I’m just showing the data which is the stories:

Here is another product called Optimizely’s quick start guide for Full Stack React SDK

Firstly, I need to install the SDK in react application with the command

npm install –save @optimizely/react-sdk

After that, below image, you can see the SDK key that you need to enroll in your react code

Here we can see the SDK key I have pasted

We can see the flag optimizely turned off so as per the react code we can see the changes in the UI and as we make it turn on the UI will change again as per the condition of the code

Output:

Here are some useful links to know more about Feature-Flag:

1. https://www.atlassian.com/continuous-delivery/principles/feature-flags
2. https://harness.io/blog/get-started-feature-flags
3. https://github.blog/2021-04-27-ship-code-faster-safer-feature-flags/

Conclusion

Feature flags are a valuable tool for developers to manage the rollout of new features in their software. They allow developers to easily toggle features on or off, without the need to deploy new code. This can be useful for gathering feedback, disabling features with bugs, conducting A/B testing, and allowing certain users or user groups to access features before they are released to the public. Overall, feature flags can help developers to manage the deployment of new features more effectively and can help to improve the stability and performance of their applications.

About CloudThat

CloudThat is also the official AWS (Amazon Web Services) Advanced Consulting Partner and Training partner and Microsoft gold partner, helping people develop knowledge of the cloud and help their businesses aim for higher goals using best in industry cloud computing practices and expertise. We are on a mission to build a robust cloud computing ecosystem by disseminating knowledge on technological intricacies within the cloud space. Our blogs, webinars, case studies, and white papers enable all the stakeholders in the cloud computing sphere.

Drop a query if you have any questions regarding Feature Flag and I will get back to you quickly.

To get started, go through our Consultancy page and Managed Services Package that is CloudThat’s offerings.