Learning about Feature Flags

“Feature flags”, sometimes called “feature flag toggles”, are a key piece of functionality in applications that practice continuous deployment, where any code that passes the automated testing phase, is released automatically into the production environment. The major misconception about continuous deployment, is that these code changes are made available to end users. Feature flags, essentially a conditional statement (aka, an if statement), allow you to wrap code and disable the functionality in certain environments.

How do Feature Flags work?

Let’s run through a scenario:

1. The developer takes a piece of work off the Kanban board, in this scenario, let’s imagine the work requires a new menu. They create a new feature flag. Note that the feature flag is not enabled in any environments – if this code is committed right now, the code would go to dev, QA, and production and there would be no change to end users – everyone would continue to see the old menu. The feature flag ensures that existing functionality doesn’t change.
2. The developer develops the feature, (the new menu), creating an if statement around the feature. To develop and test this feature, the developer enables the feature in their development environment. When the page loads, an if statement checks if the feature flag is enabled, showing the new menu, otherwise the old menu is shown. Again, if the developer merges this code with the main branch today, end users in production would continue to see old menu, as the feature would still be disabled for them.
3. As the feature is completed, the developer can merge it with the main branch and enable the feature on QA – when the QA team is ready, and then in production, when the business is ready for end users to use the feature.
4. The main advantage of this process, is that a release of a new feature wrapped in a feature flag takes out most of the deployment risk. The business can enable the feature flag when they are ready, knowing that the feature potentially could have been deployed for some time. This is also an advantage if the system has a critical error. For example, if a new launched feature, for whatever reason, is generating a critical error, we can disable the feature quickly by just disabling the relevant feature flag. Think about this same scenario without feature flags, and ask yourself, “How long does it take my team to release a single line of code”? For most, it’s hours, (often with a production hack sidestepping most of the normal development process), if not days or weeks, where-as a feature flag can be toggled in just seconds.

Disadvantages

There are disadvantages of feature flags, everything has a balance in this world. The main risks include:

• Deploying development code to production: There is always a risk pushing code in development to production. This can be mitigated by automated testing, good feature flag practices, and a good DevOps process, to ensure you don’t merge in code that isn’t tested. This item is the one most likely to cause issues early in your feature flags journey, but it’s also probably the easiest to address.
• Technical debt: Once a feature has been deployed, the old feature and the condition wrapping it has to be removed. In many cases, as well as the feature flag and the if statement that is checking it, we also need to remove the old code we aren’t using anymore – in our example today, the old menu.
• Complexity: Some feature flags may have more than a simple on/off, perhaps they have a red/blue/yellow toggle. Other situations may have multiple feature flags mixed in the same section of code… making a spaghetti mess that needs to be unraveled (see the technical debt item above).

Many of these disadvantages can be mitigated by keeping feature flags as short lived as possible, as well as careful planning and working to keep the sprint and development cycles simple. Do you really need 5 feature flags with that new feature, when perhaps one or two will do?

Advanced feature flag systems

Advanced feature flags allow us to have more control over how our features roll out

• For example, we could enable features by user, role, or geographic location. This could allow us to test a feature on a particular end user, or end users located in a particular location or job title.
• Some applications like to gradually roll out features to users over time. For example, on enabling the feature, only 10% of users see the new feature, but every few hours/days, the roll out will increase, until all users see the new features. This is really useful when we are testing scale and performance of a new feature, and we need to monitor resources as we increase scale.
• Feature flags also allow us to test features, this is often called “A/B testing”. For example, what if we had list of products for sale, and weren’t sure if it we would sell more products if it was a horizontal list or vertical list? With feature flags we could split our users to into two groups, and see which group buys more products, validating the best option. This is really what we were promised DevOps would be, the capability to create features, test them, and then respond to our users activities.

All of these advanced features can be rolled together. Perhaps we want to only enable a new feature to 50% of consultants in our Sydney and Melbourne offices? Or perhaps we want all employees in the HR department with 2 or more years of tenure to see the feature.

Wrap up

This short discussion is just the beginning of feature flags. There are a number of products out there that help with feature flag management. The best, in our opinion, is definitely launchdarkly.com, but there is also a cost involved – we would love to use launchedarkly.com on SamLearnsAzure.com, but as we have a limited budget and are are dealing with a small number of users.

Therefore, over the coming weeks, we are going to implement a very simple custom Feature Flags solution. (this series is continued here)

References

• launchdarkly.com