How we use Feature Flags at Vinterior

We use feature flags at Vinterior to move faster and make changes safely.

Feature flags (or feature toggles) are well explained in this article Feature Toggles (aka Feature Flags). It is a way of having the system show or hide a feature based on a setting updatable outside of the codebase.

The feature flag solution we use is called flipper. It’s a ruby gem and gives us a lot of flexibility.

It allows us to
a) turn a feature on for everyone or no-one.
b) turn a feature on for a % of users.
c) turn a feature on for only specified users.
d) turn a feature on for a % of the time.

When do we use feature flags?

We user feature flags all the time for all kinds of reasons.

Deploying Work In Progress

We like to keep our Pull Requests (PRs) small, which makes for easier, faster PR reviews and helps us deploy lots. Feature flags allow us to hide work in progress code so it can be deployed to production before the feature is complete.

This stops long-lived feature branches and the problems of multiple people branching off feature branches. As our master branch is consistently being updated with in-progress features everyone can branch off master deploy a small part of the solution safely behind a feature flag.

Example:
When developing our guest checkout we deployed our changes page by page as the change impacted widely across the site. This meant there was code in production that wasn’t run in production for a few days after it was deployed when the feature was turned on.

Testing features on production internally

This means we can add our internal team to see and test specific new features before any customers see it.

Example:
When we added lazy loading to our images we tested internally first as we’d seen some erratic behaviour and wanted to be confident that it worked consistently on the pages.

Canary testing

If we want to limit the risk of a change, we can add a small percentage of users to the feature and keep an eye on the relevant metrics. This is useful for changes to checkout processes and was invaluable when we changed how payments were processed.

Example:
Implementing Strong Customer Authentication (SCA) was a rather painful process and being able to limit the number of users who saw the new code versus the old code meant we limited our risk. It also meant that when we found a bug we could turn off the feature instantly until the bug was fixed so no additional customers were affected.

A/B testing

We’ve added what feature flags each customer is behind in our Google Analytics DataLayer so can analyse the performance of feature_flagged vs not_feature_flagged users in Google analytics.

Example:
When we experimented with adding estimated delivery prices to items we were easily able to compare the conversion rates of users who had seen the estimated price vs those that did not in Google analytics.

Launch a change instantly

Our homepage and brand visuals are all in our codebase which means changing them at a specific time would require a developer to deploy some code. By adding a feature flag to the homepage anyone in the company can go and change the feature value to update the visuals.

Example:
When launching our Black Friday sale the homepage visuals were deployed a few days prior to the sale but put behind a feature flag. This allowed marketing to see the page in advance of the sale exactly as it would appear to customers and meant that on the morning of the sale they could click a button in our admin area to update the homepage for everyone.

The trade-off

So we use them a lot. But they don’t come for free.

Feature flags are technical debt that will need to be repaid. Removing the feature flag is often procrastinated on in favour of delivering new shiny features and improvements. Each feature flag adds additional complexity to the codebase and they quickly pile up.