FeatureToggle ideas

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:

In the above example we have 5 environments:

• DEV: This is where your CI deploys to, with the same feature versioning as PROD, to allow you to perform regression testing etc.
• DEV (Feature): CI also deploys to this environment, but feature versions are set to the latest for all features, to allow early access to new feature versions.
• TST: Gated deployments (perhaps by the test team), with the same feature versioning as PROD, to allow you to perform regression testing etc.
• TST (Feature): Also gated deployments, with features set to the latest version for those currently being tested.
• PROD: Production, with feature versions set to those which have been signed off.

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.