Davide Guida | my personal thoughts about life, coding, the universe and everything.

my personal thoughts about life, coding, the universe and everything.

Show menu Hide menu

Page 2 of 23

Feature Gating

Feature Gating part 2 : how can we store the flags?

28 February 2018 / / 0 Comments

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!

Feature Gating

Feature Gating part 1 : what is it?

26 February 2018 / / 0 Comments

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!

DevDays Salerno - Feature Gating

DevDay Salerno: let’s talk about Feature Gating!

23 February 2018 / / 0 Comments

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!

 

How an AppDomain can help you isolate your method calls

19 February 2018 / / 0 Comments

In one of my latest pet-projects (which with a bit of luck is about to become a real project, knock on wood!) I have been in need of executing code in total isolation form the containing application. 

Without giving too many details, the system allows plugins to be uploaded ( as standard .NET assemblies ), stored and eventually executed. However, in order to avoid a rogue plugin to jeopardise the entire application with nasty stuff like infinite loops or random exceptions, I needed a way to isolate their execution.

Being this a new project, I started writing it using .NET Core but had to revert very quickly to the ol’ reliable Framework. Seems that as of now Assemblies can be loaded in memory but there’s no way to unload them.
Just for the sake of documentation, the class responsible of loading is AssemblyLoadContext . Unfortunately loaded assemblies will be kept in memory till the containing process gets closed (more details here).

So what’s the alternative? AppDomains ! As often happens, the MS documentation does a pretty good job explaining what they are and how should be used so I’ll move straight to the point.

I wrote a small example and pushed it to GitHub, you can find it here.

The core is the Isolator class: as you can see from the code it can be instantiated passing the Type of the class you want to isolate and the name of the method you want to run on it. Something like this:

using (var isolatedFoo = new Isolator(typeof(Foo), “Bar”))
     isolatedFoo.Run();

Under the hood the Isolator will:

  • create a new AppDomain
  • load the assembly containing typeof(Foo) 
  • create an instance of Foo
  • execute the “Bar” method on said instance

Also, being a very polite class, it will unload the AppDomain during the Dispose() .

More under the hood, the real magic happens inside the IsolatorRunner class. As you can see from the code it inherits from MarshalByRefObject, this will allow the instance to act as an intermediary between the two AppDomains, with a proxy that will be automatically generated to intercept the calls on the other side.

Being this a quick example, I didn’t focus on the quality of the interfaces. So for example being forced to use a string to denote the method to execute is a little…disappointing. 

I’ll work a little more in the next days (weeks?) and try to come up with a nicer API, maybe using Expressions and Funcs 🙂

Entity Framework Core

How to reset the entities state on a Entity Framework Db Context

26 January 2018 / / 0 Comments

I had two bad days. Those days wasted chasing a stupid bug. I had a test class with 4 test cases on my infrastructure layer. If executed one by one, they pass. If the whole suite was executed, only the first one was passing.

At the end I found out that it was due to the Entity Framework Core db Context tracking the state of the entities. More or less. 
In a nutshell, every time a call to SaveChanges() fails,  the subsequent call on the same instance of the db context will retry the operations. 

So let’s say your code is making an INSERT with bad data and fails. Maybe you catch that and then you do another write operation reusing the db context instance.

Well that will fail too. Miserably.

Maybe it’s more correct to say that the second call will look for changes on the entities and will try to commit them. Which is basically the standard and expected behaviour.

Since usually db context instances are created for every request this might not be a big issue.

However, in case you are writing tests using XUnit Fixtures, the instance is created once per test class and reused for all the tests in that class. So in this case it might affect test results.

A potential solution is to reset the state of the changed entities, something like this:

Another option is to avoid entirely reusing the db context and generating a new one from scratch.
In my code the db context was registered on the DI container and injected as dependency. I changed the consumer classes to use a Factory instead and that fixed the tests too 🙂

« Older posts Newer posts »

© 2018 Davide Guida

Theme by Anders Noren — Up ↑