Last week I was invited as speaker at the monthly DevDay Salerno to talk about Feature Gating. The recording will be soon available on YouTube (even though it will be in italian, sorry).

Seems that the topic captured some interest so I thought it was a good idea to write a little about it here. 

In this series of articles we will

• discover what Feature Gating is
• what strategy can we use to persist our data
• some design patterns
• how Feature Gating can help us and why should we be using it
• how to fight the infamous tech debt

So let’s start!

As I wrote already in my last post, Feature Gating is an interesting and easy tool to leverage when you want more flexibility during production deployment. It helps controlling and shipping new features faster allowing practices like canary releases and A/B testing.

But what’s the heart of it? An IF block. Nothing else. 

Suppose you’re asked to rewrite a functionality, the first thing you would probably do is commenting the old code and replace it with a new function. Something like this:

Then (probably, hopefully) you update your tests and deploy to production. And right after you discover that maybe

• the code is not exactly doing what it’s supposed to do
• performances are lower than expected
• a bug slipped through
• whatever

So how can you control this without updating the code and deploying again? Let’s see a very simple solution:

We introduced another actor, this “checkFeatureIsOn” function. It will take the name of the feature and return a boolean flag indicating whether or not use the new codepath.

In the next article we will explore how would you store all the flags. Stay tuned!

Did you like this post? Then