In today's fast paced world, it is important to release software quickly and continuously while adhering to release best practices. The use of feature flags, also known as feature toggles, is a fast and easy way to do this. In this blog, we'll explore using the feature flagging technique by taking some use cases as an example. We'll also touch upon feature flag management, as well as discussing how to build feature flags and how they can be used.
DevOps & Feature Flags: Increasing Deployment Velocity
Consider Sara, a DevOps engineer. She has set up a comprehensive CI/CD pipeline as part of the software deployment process for the product she is building. One day, a software update caused some critical issues in the product’s UX.
Therefore, Sara decided to build something new into her code - a way to quickly and gracefully disable new features that were a part of any future software updates and to preserve the UX for her customers. First, Sara reviewed her pipeline and realized that there were some process-related issues that she had overlooked. Her team had built Feature 1, which had gone through the pipeline but had had to stop before being deployed to production. This was because of the Gate, which represented the host of issues that could prevent the feature from being deployed. These issues included incomplete testing, business considerations, faulty code, and more.
So her team had paused there, and had gone back to developing Feature 2. At the same time, others in the organization were dependent on Feature 1, which had not yet come through to production. In this fast world of continuous releases and feature delivery, this delay became problematic.
Sara knew she had other ways around the problem. She could build off of a feature branch, move the necessary code through the pipeline on a side patch, or deploy a separate revision directly to production while skipping the dev environment. However, these were not very elegant fixes and they required quite a bit of coordination with others.
Since this was a pipeline in a microservice, Sara knew that the problem could be compounded from there. Therefore, she decided to build a solution using feature flags.
What are Feature Flags or Feature Toggles?
Feature Flags, also called feature toggles, feature switches, feature flippers, or conditional features, are a software development technique that allows you to hide, enable, or disable selected features in production. This is done without deploying new code and is especially useful as a part of the CI/CD pipeline. Feature flags account for a DevOps-first mindset so that you can progressively release even before features are complete and approved to be released to production. Because you can make changes without pushing additional code into production, it allows for faster and more controlled experimentation over the feature lifecycle.
Feature flags are considered a best practice of DevOps. CI/CD pipelines can deploy code multiple times a day, and these pipelines are used to release software to end users faster. However, fast does not always mean bug-free or safe. Feature flags are one of the safety measures you can use to turn off a feature that does not perform well in production. Within the context of CD, Feature Flags are the foundation for releasing software faster and with a high degree of control.
Building Feature Flags
A feature flag in your code is essentially an ‘if’ statement. The code inside these conditional statements can be toggled on or off, which is similar to the code being commented out. This is an example of the code of a feature flag:
(source: https://martinfowler.com/articles/feature-toggles.html)
Sometimes, you may want to enable or disable a feature dynamically, such as during a simulation engine’s integration tests. To do this, you can use a Toggle Router. This is a function that can be used to dynamically control which code path is live or enabled. You can create a Toggle Router in many ways, from an in-memory store to a sophisticated distributed system, but the core concept is that it will allow you to run automated tests to verify both sides of a toggled feature.
This is an example of the code that can do this.
(source: https://martinfowler.com/articles/feature-toggles.html)
Using Feature Flags: True Continuous Deployment in the Development Process
To build a solution to her process problem, Sara built a feature as a code branch and added a flag to it. As we’ve seen, the Feature Flag is essentially conditional logic. After adding the feature flag, you can merge it back into the master branch and follow the rest of your pipeline. This time, however, you can immediately deploy your code to production. This is because you have now introduced what’s called a Feature Decision Provider. This is an abstraction that sits outside the pipeline. It provides the ability to turn features on and off after deploying the code to production.
This means that you can deploy code immediately without waiting for all tests to be run and business decisions to be taken. You can turn the given feature on or off whenever technical or business considerations demand.
Sara’s pipeline now looked like the below diagram. By making these modifications, Sara was able to keep feature flags as a kill switch for any future software releases.
One important thing to remember is that Feature Flags allow you to decouple feature rollout from code deployment. This means that code deployment does not equal release! The separation of code deployment and release gives you control over who sees what, and when.
As an example, consider your favorite video streaming service. This video streaming service likely has different tiers of content or privileges unlocked for different payment tiers. For example, let’s say that someone with a Basic plan can login and watch SD videos on 2 different devices, whereas someone with a Premium plan can do so on 4 different devices. Now imagine that this video streaming service is testing the rollout of a Diamond plan, which allows paying customers to login and watch videos on 6 different devices, all in HD.
From a backend perspective, to test whether the infrastructure can take the load, if all videos buffer smoothly with no interruptions, or any other UX issues, it may be best to test the Diamond plan with a limited number of users. You can use Feature Flags to do this. Feature Flags will allow you to turn on Diamond membership privileges for a select number of users, while other users will have continuous and uninterrupted access to their own plans, with no disruptions.
This is also called a canary release, wherein a feature is turned on for a specific cohort of users. Key metrics, such as engagement rate and user satisfaction scores, are monitored to confirm that the new features do not negatively affect end users.
Feature Flags are also used for A/B testing. By disabling a feature for half of users and enabling it for the other half, you can test how well the feature performs for certain predetermined metrics. This is especially useful for non-technical people since they can test various features without having to deploy code.
Finally and most importantly, feature flags are a handy kill switch. If a bug is found post-release, the feature can be rolled back instantly, without needing to compromise on the other parts of the code.
Feature Flags at Cuelogic
We have seen what feature flags are, a simple way of using them, and some of their applications. At Cuelogic, we use features flags to help organizations release software fearlessly and continuously. Our engineering teams use proprietary as well as open source technologies while engineering each feature release. We release features of your software product by leveraging feature branches that form a critical part of continuous delivery. By using feature flags, we help you test new features with a limited user base.
If you want to deploy feature flags as part of your application, but need some help getting started, contact us at info@cuelogic.com. Our experts can give you valuable, customized guidance and implement a comprehensive DevOps-enabled Feature Flags strategy.
