Do you remember the old days when we used asp 3.0 or earlier version and it was common to fix things in production? Ad-hoc was king, kind of, if you did not forget to add the changes to the source control.
The funniest thing with innovation is that we mostly take to steps back to jump three steps ahead. Feature toggling, A/B testing, DevOps, CI and CD and Hypothesis development make this test in production popular once again, but this time in a more controlled manner. Instead of change code in production and test it, we simple want to do the same thing today but with automation, so we do not need to add or change the code in production to get the same result. We simple add the changes to our master code push it and it will get released into production for testing. In this blogpost I will give you some examples how you can manage this in a structured and simplest possible way.
First of all, what we want to do is test our ideas our hypothesis in production, we will also make it possible to turn feature on and off in production. Here is an earlier blogpost if you wonder why we want this.
and here https://johannormen.com/2016/04/07/how-pain-driven-developmentdesign-pdd-can-be-used-as-an-extension-to-hypothesis-driven-development-design-hdd/
To make this happen we need some discipline, first of all we must get rid of our pride to do the best possible solution from start, we don’t want to waste too much time (and money) to just get the information if a feature is worth implement as full scale. So we need a controlled AD-hoc approach. This can be solved with a feature toggle framework. I made one here, but feel free to use others. https://github.com/jnormen/NS2.FeatureToggler
This frame work will help you to encapsulate the AD-Hoc code so it will be ease to remove and also easy to read.
You simple create a class that implements IFeature like this.
public <nameOfTheFeatureIWantToTurnOnAndOff> : IFeature
And then use an if statement like
if ( Feature<PressMeButtonText>.Is().Enabled )
To handle nice CI and CD we also need a god structure in our solution. If you remember clean code that’s all about just clean code, it’s also important to have clean structure and architecture. In my case I love to use one project not many and also a folder called module, in this I put all the code for different domain boundaries. Kind of the same way we separate Microservices and so on.
A module can be everything regarding products, carts, invoices, users and so on. To indicate for the developers there is a test of a feature ongoing, I simply add a featuretoggle folder in my module. If there is no such folder then there is no feature on that module for test in production.
Here is where the discipline comes in. You really need to remove stuff you do not use to help others and yourself to understand what’s going on with the code, architecture etc. The same rule as for remarked code.
So this is how I made my folder and project structure:
Every code that is just for the FeatureToggler exist in this folder, the IFeature class, scripts, styles if needed. I use gulp for my build pipeline so I just let all the sass, less or js files to be included in my bundle if needed as well. Therefore, I also add the modules in my gulpfile. Eg:
I also made a more advanced gulp-pipline to move views from my module to the views folder structure. I know it seems insane but I want all code to exist in my own module not laying around everywhere in the project. So if I want to update a view I do it in my module views and it will be copied to the views folder for ASP .Net Mvc to handle it. In this case I can delete the whole module folder and get rid of all the codes with just a click.
My feature toggle framework uses appsettings.json to turn off and on features. I also made it possible to add a method to my feature class if I want to do more advanced code to indicate if the feature is on or off. Like some A/B Testing routines, if a person is in a special role and so on.
This can be done by just implement a IsEnabled() function that return a Boolean on the class that implements IFeature. (This is a dynamic method so it’s not required by the IFeature implementation.)
public bool IsEnabled()
… your special code to indicate if the feature is on or off…
To use the Configuration in ASP .Net MVC .Core just send in the Configuration to the static SetConfiguration method in your startup.cs
To set a feature on and off this way simple add the class name and the value in appsettings.json like this
Now let say that I want to test if a person press my button if the text is something else then the ordinary button and color is red. (I know really bad example, but it’s just to show you how you can handle your code).
Go to the view you where you want to test your feature, add a razor if statement and all the code needed just for the test. It doesn’t matter if it’s inline code, remember it’s just a test, nothing more and nothing less.
I added my test style and my test script and my test button. Within my new feature. My old code is still there in the else criteria. Now I’m ready to push this little code into my master branch and let Visual Studio Team Services (VSTS) trigger the CI and build configuration and add it to production. A tip, you can use Docker or Windows Containers here as well for better testing benefits and so on. I do not use feature branches just my master. Therefore, it’s also important to have tests in your CI & CD pipeline. And here are why containers are so useful as well, easy to rollback and then fix if any problem with this newly added code.
For more information regarding feature toggle and source control
If you want to add the test on many different view I recommend to do some shared module and create an ad-hoc web components instead.
The build pipeline with gulp will include it as well so no manual work at all, beside creating the folders and the web component file. (Angular 1, 2, Aurelia, React, Ko or whatever you like.)
And in production we can see something like this. In this case the feature is off and we got the standard button.
And here it’s on.
Remember it’s also important to log data so you can evaluate what buttons get most clicks. So you can decide if this feature is worth implement in full scale.
Remove the feature
I did this feature framework help you with the cleanup. You can add if statements in the code without any framework, but then it can be harder to know where to clean up in your code. In this case, just delete the feature toggle folder in your module folder. And build your project.
You will then get compilation errors and it will help you clean up just that feature.
So just delete the if statement. Or add the new code in its place.
Easy right? The structure is self-explained, the code is mostly clean, the test is a was ad-hos solution just to save time to get data if it’s forth implement at all and so on.
Who is Johan Normén?
Johan Normén works as a speaker, mentor, team leader, agile coach, and senior .net developer at Softhouse in Gothenburg Sweden. He has over 18 years business experienced and worked in many different projects and roles. Was one of the creators of Swenug (Sweden .Net User Group) with over 3000 members all over the country. He started the computer era as game designer at the age of 12 with his Amiga and team. He has been nominated as the top 10 developers in Sweden in the Swedish version of Computer Sweden 2015 and member of IDG Expert Network Team