Featureflow

Why Beta?

Betas are an important approach to ensuring you release the right stuff to your customers.

Betas are usually pre-released to a subset of customers, they should involve a feedback mechanism of some sort (whether direct or implied through analytics) and are primarily designed to ensure that features and quality of a particular feature set are up to standard.

But there are challenges with running betas.

How do you manage beta rollout in an effective and simple way? Should you create an entire separate deployment (beta.mysite.com), how do you control the beta features, how do you release beta features and allow opt-in?
How do you manage and configure beta cohorts? How do you define the cohorts to target, should the logic be hard-coded into the application, if so how do you ensure your entire application stack honours the same cohort configuration?

Managing betas with Feature flags

To help with the risks and challenges of beta releases, teams are adopting the approach of using feature flags. Instead of releasing an entirely separate beta site or introducing the technical debt and complexity of a hard-coded solution, you can use a feature flagging mechanism to define beta rules.

Feature flagging simply means adding 'if' statements to your code and providing configuration to toggle a or b. Whilst there are a number of open source solutions out there, using a managed solution such as Featureflow provides a turnkey best practice way of implementing and controlling feature flags. Let's see how it could work:

Set up your beta feature

Set up your beta feature as a feature flag 'my-new-feature' – your engineering team will wrap the new beta feature in a feature flag.

Define any variants

You may wish in your beta to test out two variants of a feature – for example you may have three variants:

off – The client does not see the new feature
variant 1 – The client sees variant one of the new feature
variant 2 – The client sees variant two of the new feature

Release with feature turned off

Engineering releases your software ahead of time with the new feature turned off.

Define your beta cohort

Product teams can define your beta cohort and enable the feature only for that cohort – for example it may be 'users with email ending @mycompany.com' or 'users with role beta_user' – betas could be individual opt-in or even based on region.

Gain feedback and insights

You can use tools like Google Analytics or Heap – gain first-hand feedback with tools such as Intercom.

Rollout to the masses

Once you are happy then the product team can decide to go live. This can involve gradually scaling out your new feature to 10%, 50%, 100% of users, or scaling up to users by region or any other sensible parameters.

Why use a platform like Featureflow?

This is a valuable approach. It is hard to achieve with custom code, especially in environments with multiple systems or microservices – coordination of systems and targeting of cohorts is hard.

This is where a platform like Featureflow comes in. Customers using Featureflow can achieve all this functionality with just a couple of lines of code. Featureflow provides a simple developer API for engineering teams in multiple platforms and languages and an easy-to-use console for product teams.

With Featureflow you can:

Target specific cohorts with precision
Run gradual percentage-based rollouts
Monitor feature variant usage and metrics
Coordinate across multiple systems and microservices

Beta testing with feature flags