“Are feature flags better for risk mitigation, fast feedback, hypothesis-driven development or subscription tiers?”
Yes.
Feature flags can be used to enable many different behaviors within the final product, they can give product owners fine-grained control over the product’s behavior and user accessibility both throughout the development lifecycle as well as within the client facing product. They are valuable technique to power more effective DevOps and drive innovation throughout the development and delivery process.
Common types of feature flags include:
Kill Switch
A feature flag is a condition in your code, an IF/THEN for two different options.
At its simplest, a feature flag can be used to flag a new or risky behavior. The great thing about a kill switch is that they can be made available within the product separate from a deployment.
You can turn on the new feature at any time. If the feature doesn’t behave as expected, it’s possible to shut it off quickly. This allows for development on other features to continue without forcing a complete rollback of your production code.
With feature flagging, you’re mitigating risk by making every feature encapsulated and controlled so if a feature has problems in production, they can be turned off rather than having a deployment rolled-back.
Beta Feedback / Canary Release
For faster feedback, beyond an on/off switch, you can control at a very granular level who sees the new feature. This allows you to expose a new feature to an advanced group of “friendly” customers who are willing to try out some new features you are developing. These beta testers can review the feature and take it for a spin and give you great feedback that might not have been considered when building out the original use-cases for the product.
Hypothesis-Driven Development & A/B Testing
Hypothesis-Driven Development Feature flags are also good for long-term access level control. They help prove out certain metrics by being able to measure the end-user behavior depending on whether or not a feature is enabled for a group of users and measuring their behavior. For example, if you have a feature that only advanced users should access, you can use a feature to have a different experience for “Newbie” vs “Power users”.
You can use also feature flags to control localization, due to various regulations throughout the world, you may find that you need to enable features in one country and disable it in others in order to stay within regulatory compliance for that particular nation.
Subscription Plans and Permissions Toggles
You can bundle several flags together to form a subscription, for example you can have a bronze, silver, and gold tier and enable various sets of features that each subscription plan might have available to them based on what subscription is tied to their account. This is a model that many of the “Freemium” apps out there subscribe to, where everyone is granted access to a base set of features, but other features are reserved only for customers who are in the paid groups.
Managing the technical debt of Feature Flags
Feature Flags have a tendency to multiply rapidly, particularly when first introduced. Toggles need to be viewed as technical debt and they come with a carrying cost, so it’s important to also keep them from proliferating within the application.
In order to keep the number of feature flags manageable, a team must be proactive in removing feature flags that are no longer needed. Once a particular canary feature has been turned on in production and has proven stable, it should be removed and expired. Other techniques might include adding governance to your development rules by placing a limit on the number of feature flags a system is allowed to have. Once the limit is reached in order to add another feature flag, you’ll need to review the current set and remove some existing flags in order to make room under the cap.
The post Feature Flags as a Continuous Delivery Release Tool appeared first on Experiences of an Inland Empire Dad.
Top comments (0)