This is an Excella Consultant Productivity Toolkit - it is intended to provide guidance and assistance to Excella's consultants. If you are a member of the Excella community, feel free to contribute!
Excella is committed to Continuous and Progressive Development of software for our clients. One of the key components of Progressive Delivery is Feature Flags (also known as Feature Toggles), the ability to dynamically enable and disable functionality of an application. This toolkit provides examples for developers on how to implement this pattern.
For a more thorough overview of Feature Flags, refer to FeatureFlags.io
Excella is a polyglot organization - we support multiple programming languages and stacks. For a generalized Feature Flag solution, we are looking for an open-source, deployable, and language-agnostic service. Our current solution of choice is Flagr. Flagr is a standalone service with both a REST interface and a simple graphical user interface.
In this repository you will find examples of how to integrate with Flagr in the following languages:
A pattern that has been successful with our clients is a targeted user rollout of features. Instead of feature being all-or-nothing, it could be enabled for a specific subset of users and not others.
For example, imagine an internal application for an organization that is used in multiple departments. In order to manage training and expectations, it would be helpful to deploy new features only to users that have received training on them. We can add configuration for this into Flagr to avoid cluttering up our application code with logic around specific departments that will change over time. For a more detailed example, see here (TODO: Link)
Unit testing with feature flags should be simple. Best practice is to make each unit of code small enough that it is not aware of or affected by any feature flags. You can see a psuedocode example of doing unit tests with feature flags on launchdarkly. If you are in a situation where a unit of code must know about a feature flag, you can simply mock out the feature flag inside of the unit test.
It gets more difficult to run integration and E2E tests with feature flags. Since each flag has different combinations you must test, as you add more and more feature flags you begin to experience combinatorial explosion. It is still possible to test combinations but it should only be done for situations where you know one flag would definitely affect another. Other than that, you should find a different testing strategy that still gives your team confidence without attempting to test every combination of flag states.
You can read more about other testing strategies in the blog posts below:
launchdarkly, optimizely #1, optimizely #2
When integrating Feature Flags into your application, you will create a set of Guards, code blocks that determine access to your feature (usually in the form of an if statement or similar structure). It is important to remove these guards once a feature has been fully promoted, both for code cleanliness and safety. With the speed of agile development, removing these guards can be forgotten or deprioritized. Here are some tips for ensuring they are removed.
- For each feature, use only a single guard if possible, two to three at most. If you find that it takes more than three guards to isolate your feature, its likely there is a design flaw in your feature implementation.
- Add a comment next to your guard with an easily searchable tag for the name of the feature.
- If possible, create a branch / pull request that removes the guard at the same time that the guard is implemented. In the best case scenario, this allows the guard to be removed in a single merge. Worst case - you've provided a guide on how to remove the guard.
- Immediately create a ticket / card in whatever agile framework you are using to represent the work of removing the guard, and make sure it stays visible in the backlog to be picked up as soon as the feature is fully promoted.
By default, Flagr does not require any credentials to access. While useful for development, this is generally unacceptable in a production system. If you peruse the Environment Variable Configuration section of the Flagr documentation, you will see some options for authentication. We recommend using the JWT method as this allows for integration with existing identity platforms.
Another production concern is logging and auditing. Specifically, it's important to keep track of who is modifying flags and when. Flagr has this capability built in as well - if you look at the above-linked configuration, there are options for exporting to tools like New Relic and Prometheus, as well as writing change records to a messaging tool like Apache Kafka or AWS Kinesis. When preparing for production, you should choose one of these options that matches your architecture and enable it as soon as possible.