Developers often need to quickly gather customer feedback about new features they deliver. However, when doing so it’s easy to forget a critical aspect which leads to an undesired error. If this critical aspect is not properly tested, the stability of the production environment can be at risk. A fast rollback is a common pattern to overcome these kind of issues. Even better: rollback should not even be an option. It would be nice to try out some pilot experiments and be able to control these without redeploying an application. Another technique is needed. Feature flags helps DevOps teams to deliver fast. In this article I’d like to highlight the core concepts and advantages of them as well as some practical methods to start the implementation.
What are feature flags?
To start with: feature toggles, feature flippers and feature bits are al synonyms of feature flags. Let’s stick with feature flags here.
A feature flag is a piece of (software) configuration that acts as a “control switch” to turn a certain application feature on or off. In the past, it was very common to create a piece of code to implement this control switch. A simple sample here in pseudo code here:
if (current day is Friday) {
activate fax function
} else {
activate mail function
}
Consider this switch was created to validate the performance of the fax function only on Fridays when there are not so many active users. Suppose the end-user now always want to use the mail function instead of the fax function. Then the code needs to be changed. The developer needs to recompile, test and push out a new version. Valuable time is lost.
Feature flags do their ground work on the runtime environment. They can be switched on or off based on various conditions. Being able to change this logic without a redeployment would help. This is where feature flags help to speed up the Software Development Life Cycle.
Different types
There are different types of feature flags such as: release toggles which control if a feature is enabled or disabled. Operational toggles which control the code flow on the back-end. For example: control whether or not to use a specific implementation of an API. Experimental toggles: these flags help to enable A/B testing and can be removed once the tests are finished.
Who needs them
Multiple teams and persons are involved when it comes to feature flags:
- Developers: build and maintain feature flags.
- End users: test out a new feature and provide feedback to the team.
- Product Owner: the teams’ representative who “owns” the feature and decides to keep the feature “as is” or make it generally available to all users.
- Other stakeholders which benefit from the functionality which the feature itself controls.
- (Internal) marketing teams to promote new features which are controlled through feature flags.
Advantages
Typical advantages of feature flags are:
- The biggest one: you don’t need to redeploy an application to enable or disable a feature.
- Get a sneak preview of new features before they are officially released. Involve end-users quickly and with confident. This way, feedback reaches the developer teams in a fast manner.
- Being able to quickly switch on or off a feature which does not perform well or generate problems.
- When using a consistent way of implementing feature flags, this provides one generic solution for all teams. It helps to prevent re-inventing the wheel when every team creates their own solution.
- Collaboration between teams is increased: less communication overhead on which features belong to which version of an application. Since feature flags are also pieces of code, the single source of truth is in Git and not somewhere else on a decentralized location. This also increases visibility into the functionality. Organizations are not depended on the knowledge of just a single person who knows all of the bits and pieces. Therefore, risk is reduced.
DevOps perspective
Keep in mind the following techniques to further speed up your DevOps way of working.
People who seek safety work in isolation in feature branches. Those feature branches needs to be merged sooner than later. The longer a feature branches lives, the greater the challenge of merging will be. This is a real problem if you want to deliver fast. With feature flags, developers can work in isolation but at the same time quickly implement their code in the master branch.
Less time needed to merge code between branches. Less code conflicts (as part of merging) helps to keep the team happy. This greatly increases visibility and developers can learn from each other since the code is not “hidden” in a feature branch tucked away in your repository.
You can completely eliminate long lived feature branches. Since long lived feature branches slow down the cycle of CI/CD, there is (now) a good alternative which also keep things on the safe side.
Code freezes (a chosen point in time of the current sprint in which the development work stops) are not needed anymore. Since the code snippets can be switched on or off (even dynamically), you can continue to do your work even after a code freeze takes place.
Feature flags help to support the principle of delivering small increments rather than big blocks of source code which pose a greater risk to deploy.
As soon as everyone is interested in the concept, it’s good to know how to implement them.
Typical implementations
As seen before, source code is not the best way to implement a feature toggle. Application source code should be dedicated to business logic and not to control whether it should be active to the end user. Business logic is where companies can specialize. Components like control switches to turn feature flags on or off distract from that. A better approach would be to create a more dynamic solution.
A couple of examples. Switch feature flags on or off:
- based on the environment an application is deployed. Activate the feature if working with a test environment and ignore it in production. Environments are dynamic, so don’t use static IP addresses to control the switch.
- based on specific requests that access the specific feature. Capture every request and read out the headers which are sent along with the request. If a “special header” is present, activate the feature or not. This is a very dynamic implementation but requires intervention on the client-side. End-users which test from a functional perspective might not be able to use this option.
- by using a special page or (hidden) form in the Graphical User Interface. This gives developers and the end-user a set of controls. From a GUI perspective it is immediately visible if the feature is switched on or not.
- based on the origin of the requests. Suppose your developers connect from a specific network. If true, the feature would switch on, If false, the feature remains hidden for other users.
These implementations are much more flexible compared to when you implement them directly into the source code of an application.
Challenges
Besides the benefits, there are also challenges which should be taken into account.
A simple feature flag has only two values. On and off. More advanced flags use conditions and more parameters to control the logic. Reduce complexity and keep things simple, otherwise you need an expert and extra documentation which explains how your feature flag works 🙂
Suppose you work with multiple teams to create multiple feature flags which also span multiple applications or components. For this use-case it’s important to give all feature flags a decent set of properties: description, owner (reflected to the owner of the feature itself), version, timestamp (e.g. create date, last modified date). Perhaps you can tag them so you know they belong to each other. Everyone should have a common understanding of these properties and fill in the values according to a standardized format.
If you do have a lot of feature flags which also differ per version of an application, things can get complicated. It is very important to have the governance part in place. Who is end responsible for the feature, which version is in production and what does the actual implementation look like. Feature flags can have it’s own life-cycle independent of the other application components, thus governance is an important aspect here.
Clean up unused feature flags. This sounds obvious, but becomes a challenge if you have a lot of them which also have owners of different teams. You don’t want to introduce a tedious processes to handle this, but at least have it clear across the teams which are involved.
Useful resources
DevOps teams need to find a way to start. The following resources are of great help.
First of all, there is an interesting webinar which is dedicated to the discussion of feature branches versus feature flags. It answers common questions like when to use either of them.
Although a bit old, Microsoft shared a very extensive blogpost which talks about the usage of feature flags in VS Team Services. This goes very deep since it also highlights various code snippets and examples.
AWS provides some insights into the usage of feature flags which highlight how to avoid backwards-incompatibility changes and how to use feature flags within the perspective of the AWS CDK.
Java developers can use Togglz which is an open source feature flag framework. There are also commercial feature-flag-as-a-service frameworks like LaunchDarkly.
And last but not least, be sure to check out the excellent feature flag glossary.
Conclusion
In this article I explained what feature flags are and I highlighted a number of use cases. Besides this, I summarized the key advantages and a number of challenges which you need to take into account. I hope this article helped you to decide how this technique can help you speed up your DevOps journey.
