A bit of googling for this blog post and... it turns out that there is plenty of history surrounding feature toggling already. In fact there is already an open-source .NET library FeatureToggle by Jason Roberts (who is also lives in Perth) which started back in 2012!
What does that mean for my project? For one I'll need to come up with a new name, as Jason already has dibs on the NuGet package name (including >5,000 downloads!). Having a quick look at Jason's codebase it appears to be a sophisticated solution with plenty of extensibility points.
So should I fork?. I know us software developers love to reinvent the wheel, but I do honestly think my thoughts around feature toggle are tangential to Jason's. So to reinforce that I am going to rename the project to FeatureVersioning. Why versioning? Well my latest experience with feature toggle was adding new functionality across a number of existing features — so we wanted to be able to toggle between the current and new version of different features across different environments. And most importantly, to be able release them to production in any order, and without a big-bang release.
What about new features? Well the non-existent feature can be considered version "0" and the first iteration version "1". As part of this project, I built a "dashboard" page which shows the defined features and their enabled versions across the environments, similar to the following:
|Feature||DEV||DEV (Feature)||TST||TST (Feature)||PROD|
In the above example we have 5 environments:
In our example, we are actively testing new versions of the Calculator and Editor features. There is also a brand new feature UserManager which isn't ready for testing, but can be accessed in the DEV (Feature) environment.
So now we have the general concepts of FeatureVersioning, what support do we want in our new library? That's for the next post.