Just a quick update: the folks from DevDay Salerno just uploaded the video from my Feature gating talk on Youtube! Unfortunately it’s in Italian but there are subtitles available 🙂
In case you still don’t know I’m writing a series about Feature Gating, the next episode will be online soon!
In this article we’ll explore few ways to check if the feature gates are opened or not. This is the third episode of our series about Feature Gating, last time we discussed about the optimal persistence method for the flags.
The first approach is a static config object injected as dependency in the class cTor:
It’s simple, easy to implement and does the job. The configuration object can be instantiated in the composition root reading data from whatever is your persistence layer and you’re done.
Drawbacks? It’ static. That means you cannot vary your flags based on custom conditions (eg. logged user, time, geolocation).
So what can we do? Something like this:
Replacing the configuration object with a specific service will do the job. This is probably the most common situation and personally I’m quite a fan. The only drawback is the infamous tech debt: very soon the code will be filled with if/else statements. Should we leave them? Remove them? If yes, when? We will discuss in another article a simple strategy for that.
Speaking about strategy, it’s a very interesting pattern that we can exploit:
The idea is to encapsulate the new and the old logic in two classes (lines 10 and 11) and generate a third one which will use the previous featureService to pick the right instance. Finally all you have to do is to inject that class in the consumer and you’re done.
Next time: this is nice, but is really useful? What do we really get using Feature Gating?
In the first article of this series we discussed the general concept behind Feature Gating, now we will talk a little about how we can store the flags.
A very naive approach is using a simple file per environment. You can serialize your flags in any way you want, json, xml, ini… then all you have to do is reading this configuration during the application startup and you’re done.
It’s a very simple method and works very well for small applications and prototypes. Of course you have to remember to deploy the configuration every time something changes. Also you’ll have to implement some sort of flags hot-reloading in the application, otherwise the only option is restarting it (or if you’re under IIS, waiting for app pool recycling).
I said “one file per environment” because I’m pretty sure you have different configurations on DEV, UAT and production. Maybe you want all your flags to be on on DEV and only a small subset on production. Whatever suits your needs.
The next obvious step is persisting the flags in the application database. You can start with a simple table with the flag name and the boolean value.
Later on it will be possible to extend the system by creating relationships to the other tables according to your specific business logic. For example you might want to link flags to user profiles/permissions to allow only subsets of user accessing the features.
This approach gives more flexibility during deployment, although you still need the hot-reloading. Also, linking the flags table to others might create unnecessary clutter and prevent splitting the monolith.
Let’s move forward to another approach: a key/value storage. Redis can be a very good candidate but here’s a list, just in case.
Using this kind of databases you have few nice advantages: first of all you can decouple the feature gating from your application using a microservice.
Also, it would be possible to easily store different types of data not just boolean flags. Suppose for example that you want a feature to be enabled only for users in Canada and Japan. A solution could be storing the country codes in the flag value instead of true/false.
The last step is using a third party service. That means you’ll have to write the integration but most of the times there will be libraries already. Just make sure to pick a product with good documentation and decent user base.
Of course you won’t have anymore control over your data and in the worst case you might have to “bend” a little the system to accommodate your application needs. It’s something that happens every time an external solution is used: might cover 90% of the functionalities you need…but that 10% could require a lot of refactoring on your side.
In the next article I’ll show some design patterns you can use in your code to check the feature gates. Stay tuned!
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
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
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!
Tomorrow I’ll be speaking at the monthly Meetup hosted by the DevDay Salerno community! The topic of the day will be “Feature Gating“, I’ll talk about the general idea, use cases and best practices. The talk will be language-agnostic as this is more a pattern rather than a framework/library. I will show some code but try to keep the discussion more on the “theory-side”.
I have always been more attracted to software architecture and design patterns so I tend to avoid putting too much effort in whatever library is the hype of the moment.
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.
One of the event organizers is an old friend of mine and ex coworker from my Healthware days. A while ago we discussed about having me presenting something but, as often happens, life stood in the way (along with me moving to a different country altogether).
So as soon as I had the chance to plan ahead my trip back to Italy he managed to find a slot for me 🙂
Unfortunately the slides are in Italian so I don’t think I’ll share them on this blog but I will be writing soon a more detailed post so stay tuned!
In the meantime, if you’re near Salerno and fancy a little geekiness come and say hi!
© 2018 Davide Guida
Theme by Anders Noren — Up ↑