Feature flags — the rest of the requirements
Feature management system requirements, Part 4
The following article focuses on the additional requirements for feature flag management systems.
Permanent feature flags
The permanent feature flags provide an ability to hide or show the core features of a product.
Good candidates for the permanent feature flags are the core features of a product. It might seem it is too much of added complexity to wrap every product feature in a feature flag, but if we do, we gain more control over it, leading to:
- Safety switch — acts as a safety net in a case when something is causing any kind of damage. For example, there might be a situation when an app is crashing, or the cost is going unacceptably up, and it is better to turn the feature off until the issue is fixed.
- A/B testing — when we put a feature behind a feature flag, it allows us to add another alternative implementation and do a percentage or ring release to verify a product hypothesis.
- Changing log level — we can use a feature flag to control the log level in production, where we want to have a real-time ability to change the log level from
infotodebugfor specific services.
Temporary feature flags
The temporary feature flags are used for new feature development, to hide the changes a team is working on, or when we need to adopt a change, like using a new API endpoint or adopting a changed payload.
After some time, there might be many temporary feature flags that can lead to technical debt. The feature flag owner is responsible for cleaning up the obsolete feature flags.
Usually, nobody is going back to revisit old feature flags. It is a good practice to hold recurring meetings to evaluate what feature flags should be kept or removed.
Isolate the feature development
The temporary feature flags can be used to isolate a code change from the other code changes.
The primary benefit of feature isolation is allowing multiple teams to work on the same code simultaneously without interruptions.
The secondary goal is that the feature isolation makes our code deployable anytime.
Once a feature becomes a part of a product, we clean up the feature flag or it can be transitioned to a permanent feature flag.
Time-limited features
Some product features have a lifespan defined by constraints that will go away over time.
For example, there might be features that only work on specific hardware. It is a question of time when the other hardware providers adopt and start providing the same features. It could be that the voice transcript works on iOS13 but not on iOS12. We know that everyone will have a new phone and over time, nobody will be using iOS12. That means we can create a feature flag that is going to serve true value when iOS13 and app version is higher than a version that contains the voice feature.
Once there are no iOS12 users, we can clean up the feature flag from the code.
Migrating to new API endpoints
It is very convenient to use a temporary feature flag when migrating to a new API.
Let’s look at the following example of when we use the temporary feature flags.
Example #1: Different mobile versions migrating to use new view
The first example is from mobile development. There are usually multiple versions of a mobile app used by all the users.
Imagine that the mobile version v1.2.3, and older versions, are using /v1/user API to render a user profile. We decided to implement a new endpoint /v2/user that returns different data in a different structure.
The mobile puts the usage of the new API, together with the new views, behind a feature flag. Then they create a new version v1.2.4 and release it to the app stores.
Now they can slowly release the feature to all the users who have the v1.2.4 version and higher. The team can first release the feature internally. If there are no issues the team can continue with releasing the feature to more users until it is released to everyone.
Once this is done, the temporary feature flag should be cleaned up from the code.
Example #2: Backend services migrating to new endpoint
We can use a temporary feature flag for a similar situation but on the backend, with micro-services.
Imagine we want to migrate to a new version of API, e.g. /v2/user. But multiple services are using an old /v1/user end-point.
The first step is to update all the services to use the new endpoint and put the usage of the new end-point behind a feature flag. Then we can deploy all the changes to a pre-production environment and test the changes, only enabling the changes for the developers.
Once the development team debugs and fixes all the issues, the team can deploy everything into the production. Then we repeat the testing using a ring deployment or percentage rollout. Once there are no errors and everything works, we release the new services to everyone.
The closing step is to observe the system for a few days. If there are errors (and we should have alerting for this), we can easily the rollback using the feature flag. But if there is nothing wrong, we create another pull requests that remove the feature flag from the code, because the migration was successful.
Example #3: A/B testing in production
Another example, and it could be a rare case — depending on how we work, is when we are implementing an experimental feature.
We might get a requirement to implement a feature that should get A/B tested by a selected user segment or percentage of our user base. We put the A and B features behind a feature flag and release it accordingly. Once the experiment is done, we keep the selected feature variant and remove the temporary feature flag.
Feature flag owner
We want to be able to assign a feature flag to a responsible person (owner of a feature flag). The owner of a feature flag is:
- the one to answer all the questions related to that functionality that is the feature flag providing
- usually responsible for setting the enablement rules
- responsible for cleaning up the feature flag in case it is a temporary feature flag
List of feature flags
To be able to effectively work on the codebases that use feature flags, the developers need to know what feature flags exist, which are permanent and temporary, and who are the owners of the feature flags.
It is convenient to have all the feature flags on single place with ability to filter based on various criteria and see what variations are returned.
What else?
There are other useful features that we did not mention. Here they are:
- feature release approval process
- scheduled releases
- insights into how a feature flag is being evaluated
- ability to define segments
- feature flag prerequisites
- workflows
- history of changes
- code references.
For all that, go to: https://docs.launchdarkly.com/home
LaunchDarkly has even more resources on its web page, feel free to explore: https://resources.launchdarkly.com/ebooks
