In this article, I want to give you an overview of feature flags, what use cases we see and some considerations on how to properly manage them. In a subsequent article, we will run through an example on how we integrated a feature flag system into our services. Let’s get started.
The Bitpanda Engineering department is organized into scrum teams and each team contributes greatly to the Bitpanda platform. The aim of each team is to deliver software that works in a reliable and fast way, so that users receive features often and can use them early.
Their frequent and reliable use requires high confidence in the quality of development and, of course, good practice. One of the ways to reduce problems and release features with confidence is to use feature flags. Feature flags are also known as feature toggles, feature switches and some other names.
What are Feature Banners?
Feature flags allow functionality inside a software program to be enabled or disabled without using code. Some systems use feature flags through the REST API and, most of the time, an additional web interface for changing the state of the flag. With feature flags, the process of using software is completely disconnected from feature releases. This means that new features can be gradually integrated into the application and used without being visible to users.
Main reasons for using feature flags
There are many reasons why you should use feature flags and how you can benefit from them. In this article, I want to highlight the most important ones.
1 – Break down large features into small manageable pieces
Big feature releases are scary. Many people from different departments are often involved. Many development teams work together and have to integrate their services together. Also, everything needs to work properly so that consumers are happy. As Bitpanda’s user base grows steadily, this tends to become more difficult to achieve. But how can feature flags help here?
First, the feature can be developed in smaller chunks and integrated into the code base without breaking the existing logic. This also means that the merger / removal applications may be smaller and live for a shorter period of time. Smaller members are easier to review by team members and more team members are ready to review as it can be done in a matter of minutes instead of many hours. Don’t expect your colleagues to sit down for a whole day to review massive reactions with a whole bunch of new features.
Secondly, the work can be better distributed within one team or over several teams using smaller chunks. Let’s take the Bitpanda Crypto Index feature as an example. If only one team implemented the feature, it probably wouldn’t be finished today. To achieve great results, every Bitpanda team has to contribute their parts and distribute a piece of the puzzle led by a feature banner, so that users see it when it’s done.
2 – Disconnect uses from feature releases
The use of software and feature releases are disconnected, allowing software engineers and the business to move at their own pace. Software engineers can make the application stable and scalable before the marketing department begins their efforts to promote the new feature.
Combined with the above point of releasing smaller updates, it is easier to identify all software updates. If an error slipped through the review, the switch can be rolled back immediately and fixed, before it affects users. In addition, the software engineers have the context of the mindset change and its resolution could be much faster.
The industry as a whole tends to move into the habit of locating often. In the “State of DevOps” report, a nice graph shows how high performing teams release several times a week and generate fewer issues over time.
3 – Test in production
Testing in production? Yeah, you read it right. Sometimes the test environment does not represent the full spectrum of functionality available in production. This could be the amount of traffic generated, where running a test environment at the same size as the production environment is difficult and costly. Or, in our case, it’s more about third-party integrations.
At Bitpanda, we support many payment providers and blockchain nodes that do not always support a test environment that is a reproduction of the production environment. It is even sometimes the case that the vendor test system behaves differently from its production system.
For this purpose, it only makes sense to enable the new provider or blockchain node for employees to test it properly, before it can be used by everyone.
Full integration can be tested in advance and can be rolled out to more and more users. It is important to keep an eye on monitoring and support tickets during this time. With this approach, issues can be identified early and if something goes wrong only a small percentage of consumers are affected.
Using feature flags
To use feature flags yourself, you can either create your own implementation, or use one of the feature banner services available. Each application must integrate the system separately. Mobile apps, web frontages and backend services must be able to access the feature flag system.
When Bitpanda was small, we had our own operations for each of our products.
The number of products and the engineering department grew, so we are currently using a common system and want to move all products to use LaunchDarkly. LaunchDarkly provides a highly available API and UI for managing feature flags, along with some advanced features.
We’ll run through an example of how we use LaunchDarkly in a subsequent article. If you want to run a system of your own or you want to use an open source tool, that’s possible too. For example, Unleash is a popular open source feature banner system that is also integrated with GitLab.
Considerations when using feature flags
Now that we know the benefits of feature banners we should also look at some disadvantages and how to avoid them.
One consideration on using feature flags properly is having good test coverage and a continuous integration pipeline that performs automated testing on all code changes. Using this, the software engineering team can reduce the risk of breaking functionality on new code changes. Running automated tests is good practice anyway and when it comes to feature flags, all permutation should be tested to ensure compatibility. The disadvantage here is the increasing complexity of conducting additional tests and exchanges.
To keep track of complexity, it makes sense not to have too many feature flags and make sure they are not mutually exclusive. To keep the feature flags low, they should be as short-lived as possible and then removed when the feature is fully released. I would recommend keeping a ticket in the product backlog for flag removal. In addition, some feature flag systems can warn if the feature flag is ready for removal as no application is trying to retrieve the state.
Another complication issue is dependent feature flags. They should be avoided! It makes it very difficult to know the state of the system. Try to keep the structure clean and tidy. If a feature needs a new REST API endpoint, then secure the endpoint with a feature flag. If the calculation logic changes, try to create one code path where the decision between the new and old logic takes place.
Who is responsible for enabling / disabling features?
As software deployments and feature releases are better disconnected through the use of feature flags, the responsibility for enabling / disabling features can be shifted. The product owner could obtain the permission to introduce a feature in collaboration with other departments. Each team has to decide individually whether they want this and make sure some audit is in place to track which feature is enabled when. We aim to free bugs, but there is always the possibility that some bugs may sneak in. Although automated testing is in place and the feature has been tested properly. With good coordination and great monitoring, your next feature release is highly likely to be successful.
Summary
Feature banners can help increase the number of successful feature releases quite significantly by decoupling software usage from feature releases. The process is more in keeping with the continuous delivery method with higher success rates. The gradual release of small parts makes it easier to keep track of what’s happening. If the number of feature flags remains limited and the application has great test coverage, there is no reason not to use feature flags.