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 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 seperate beta site or introducing the technical debt and complexity of a hard-coded solution, you can use a feature flagging mechanism to define 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 was of implementing and controlling feature flags. Lets see how it could work:

Step 1: 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.

Step 2: Define any variants – you may with 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 one of the new feature

Step 3: Engineering Release your software ahead of time with the new feature turned off.

Step 4: 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.

Step 5: Gain feedback and insights. You can use tools like google analytics or heap – gain first hand feedback with tools such as intercom.

Step 6: 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..

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 cohorts, run gradual scale ups and monitor feature variant usage and metrics.