Getting ready to launch a new feature can be nerve-wracking. You want to make sure your users have a good experience and actually use the new feature that your team has put countless hours into developing.
As your product and team grow in size, there are even more points of coordination necessary to pull off a new feature launch where Developers, Product Managers, Marketers and Reliability engineers all have a role. Each feature goes through a number of gates in order to validate the feature is ready for mass adoption. Developers review the quality of code to be released and automated test suites are run, Product Managers review the delivered release for feature-completeness, Marketers plan the positions and message of the launch, and Reliability Engineers ensure the infrastructure is ready to support your application’s new requirements.
Even with all of these checks and balances, bugs will slip through. We’ve all heard someone say “Well, it worked on my machine” before. We encounter these scenarios because of subtle nuances between environments which aren’t always easy to keep in sync. It’s these differences that make it difficult to just lob a new feature into production for all of your users. If the release is broken or has bugs, you will sap momentum from your launch and lose the confidence of your users.
We’ve all heard someone say “Well, it worked on my machine” before.
Why you should release features in cohorts
Bundling features into releases, and slowly rolling those bundles out to your user base is the easiest way to make sure your shiny new feature is ready for the masses. It can be a simple as only making a feature available to members of your own team when the release first hits production, or it can be more specific to cohorts of users based on behaviour, previous feature adoption or even geolocation. This slow release of features requires additional preparation in your application in order to control effectively.
Enter feature flags.
A feature flag is a gate which enables or disables a code pathway depending if a condition is met. In its most rudimentary form, it’s an IF statement wrapped around a particular section of code. This enables you to release code to production, coordinate across teams, and release a feature to your users only when you’re ready. Let’s take a look at different approaches to feature flagging and their unique purposes and effects.
Release flags are simple on/off toggles which facilitate turning a specific section of your application on or off. These types of flags are useful for coordinating the release of a feature at a specific time and date.
Permission-based flags are context-sensitive flags which take into account how a feature is being accessed; most commonly looking at characteristics of the user who is using the application. This type of flag is great for allowing early access to features to influencers or an alpha or beta cohorts or controlling different account features of a user.
Sampling flags are closer to release flags, but only allow a certain percentage of requests to satisfy the gate. Typically used for canary releases, this type of flag enables you to observe the impact of a new feature on a subset of your userbase. This is useful when you want to monitor the impact of a feature on your infrastructure in production, or the reaction of your users overall.
Depending on the stage of your product, approach to release-management, and marketing launches you will want to implement different flag behaviours.
Flags are dead simple with Prefab.cloud
Prefab.cloud offers prebuilt infrastructure as a service. They offer packaged solutions for rate limiting, API call deduplication, distributed config and of course feature flags. If you wanted to implement any of these yourself, you would have to write extra code, and add extra API endpoints and databases. All of this requires ongoing attention and maintenance, so why not offload that work?
Feature flags offered by Prefab give you everything you need to implement any of the previously mentioned types of flags.
To get started with Prefab.cloud simply visit the Manifold dashboard and select the plan which best suits your application.
Developer’s first feature flag
When creating your first flag with Prefab you’ll be faced with a few different fields to fill out, which define the behaviour of the flag when consumed in your application.
The key is a label which facilitates the grouping of a feature flag. These are arbitrary names which can be labelled after different sets of features. Whatever name you define will be used in your code later, for testing the flag’s gate.
This is the percentage of users the flag’s gate will be enabled for. This is used for sampling and can be left at 0% to use only the defined whitelist, or can be set to 100% for a simple release flag (when enabling the feature).
By specifying a list of comma-separated tokens, you are able to enable the flag’s gate for specific cohorts of users (ie.
beta) or by namespace (ie.
When Prefab evaluates your implementation of the flag preference will be given to values defined in the flag’s whitelist, over the percent active. If you have 0% active, and user:456 defined in the whitelist, the flag will be enabled with
user:456 is tested in the gate.
To make the most of our code samples, let’s define a scenario where we are releasing a new feature called
templates which enables a new template field in our record creation flow. We want to test the new feature with a group of influencers who we have hand-picked and tagged with beta in our user profiles.
Our first step is to SSO to the Prefab.cloud dashboard (you can do this by clicking on the Open Prefab.cloud Dashboard button on your resource) and create a new feature flag with the name of template and our beta group whitelisted.
In our application, using metadata assigned to our user’s profile we can test to see if the feature should be enabled for them:
It’s really that simple. Prefab keeps track of the groupings and namespaces, and we can create near infinite combinations of features and user cohorts.
Handing our feature to the masses
Once the attributes metadata is added to our user profiles, and the gates are added for the features we want to control by our flags we can manage the status of our feature directly from Prefab.cloud’s dashboard.
When deployed in production, only users whose profile contains the
beta attribute will be able to operate your
templates feature. Once you’re satisfied with its performance, or the feedback you’ve received from users testing the feature you can simply update the Whitelist percentage for the flag to
100 and remove the
beta group from the whitelist.
If you want to slow the rollout of the feature to all users outside of your influencers you will increase the whitelist percentage from
0 to a higher value over time. Start with
10 percent of your users, save the flag, monitor your application’s activity and then increase the value and save again when you’re comfortable (hitting
100 when the feature is ready for all users).
After your feature has lived in production for a period of time you’re comfortable, simply go back into your code and remove the gate.