The pace of change in the software industry keeps accelerating. Speed and responsiveness are more than ever key to facing constant changes, and we must be ready to respond to these changes by adding new features to our software products. Feature Flags, also known as Feature Toggles can help keep up with this task.
What are the Feature Flags?
Feature Flag is a technique and set of patterns that allows DevOps teams to enable or disable parts or features of the software in local or production environments. This, in turn, allows these teams to deploy new features without compromising the whole system, having more speed in the deployment of new features, more control over the functionality of the system in case of failures, and last but not least, ensure that software continues to follow the Continuous Integration principle without the need of having multiple feature branches. Thus, the production code may have unfinished features, but they would be hidden by the Feature Flags.
Feature Flag Types
There are different categories within Feature Flags that can be classified according to their life span and their level of dynamism.
Release toggle
Release Toggle allows us to enable or disable an unfinished feature. This allows us to mix our productive code with the new functionality without having to worry about if it works or if it has not passed all the tests, as this functionality will be hidden in production. These Feature Flags let teams work optimally with Continuous Integration.
Ops Toggle
Let’s say our development team has developed a feature, and we are not sure how it will affect the system’s performance. With Ops Toggle we ensure that we will be able to enable or disable that new feature easily and quickly while in production. The system will never be compromised, as we will be able to react quickly to the problem and avoid more serious performance issues.
Experiment Toggle
This Flag Feature type is the most used by large companies and by extensive applications. Let's imagine that we have a new feature with many changes in a pre-existing process, and we want to analytically know how users would react to these changes. With Experiment Toggles we can easily apply A/B testing and let users decide which functionality they will see: the new one or the old one. With this, we get the users themselves to decide, and we get to have both functionalities at the same time, which will allow us to collect usage and functionality analytics.
Permissioning Toggles
The most common use for this type of toggles is if our application has paid features, since this will allow us to display said features in case the customers activate that service.
Implement and Manage Feature Flags
As with everything good in the software development world, Feature Flags introduce great benefits, but they come with some responsibilities in their use and maintenance, especially if the Feature Flags are going to be a long time part of our code. The organization and structure of our code is very important to reduce technical debts throughout the life of the application. There are certain patterns that help us plan the introduction of Feature Flags in our code:
Do Not Overuse Conditionals
The easiest way to implement Feature Flags is to use conditionals to make decisions about when a functionality will be used or not. Conditionals are useful if the Feature Flag is short-lived, or if we have very few of them. In other cases, the best course of action would be to implement a Strategy Pattern where the decision is made based on a strategy that will be taken into account when we create our objects.
Decoupling of decision making from logic
A very common mistake when implementing Feature Flags is making the decision to use one functionality or another within the same code function where the logic is. This should be avoided at all costs and decision making should be decoupled from the logic. This ensures that we do not break the principle of Single Responsibility, and avoid problems if we wanted to extend the scope of our Feature Flags.
Flag Naming
We must be careful when naming our Feature Flags. Inadequate use of names can lead to duplication and other types of confusion that will lead to technical debts.
Documentation/Logging
Just as it happens with the nomenclature, it is very important to have our Feature Flags well documented. Every developer in the team must know which Feature Flags are being implemented, what they do, and their status.
Feature Flag Configuration
How or where do we store the configuration that will allow us to make our system more flexible using Feature Flags? There are different approaches to this question, but the most common are:
Parameters
One of the easiest ways to configure our application is using parameters or environment variables. However, it does have limitations when we want to do testing and in many circumstances, it implies having to restart the application or even redeploy it.
File
Having a file with the Feature Flags configuration is useful but sometimes impractical, since in order to change the Flag Features state, we will probably need to redeploy the application.
Database
It is the most used and practical configuration of all, since we have all the configurations centralized in a database. The application would not need to restart or redeploy when we want to update a Feature Flag. The most common case is to have an administration area in our application, so that administrators can configure it in real time.
What Now?
Personally, I encourage the use of Feature Flags to improve our development and implementation processes. There are many libraries for almost all programming languages that will help us get started on this path.
We have seen that Feature Flags are a very useful technique to have a good continuous integration in our application, to be able to manage changes quickly and to have progressive deliveries. But like any technique in development, it requires some structure and organization to avoid falling into technical debt if it’s overused or mismanaged.
