Feature toggling and A/B testing in production with ASP .Net Core

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

Eg: PressMeButtonText

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

Twitter: @johannormen




Why Microservices and continuous deployment (delivery) is win / win

Microservices is nothing new but has become a standard in many systems during the last years. There have been trends in architectures some engineers use them as a silver-bullet. They used the Architectures even if not required by system nor requirements. DNA, 3-teir, SOA, DDD, CQRS, Onion architecture and so on. Is Microservices just a trend that will destroy systems because people will use it as a silver bullet? Maybe! The future will tell. Let’s investigate why microservices will be a good benefit for the continuous delivery approach.


As most of you know by now, is that continuous delivery (CD) is an approach to deliver functionality in a smooth and almost automatic throughput. CD is an extension to Continuous Integration (CI) that are the configuration that tells you something will happen as soon you check in your code in to your source control. It can run tests, if it fails it will not publish the system or do something else that’s important four you and your business. I use CI to tell the build server to build my system, run some test and send it to production with continuous deployment.

The different between Continuous Deployment and Delivery is just that deployment automatically deploy your code when delivery just give you a package that you can manually deploy


As always it is requiring discipline in your mindset as well in your code. It will be forced since you release everything in to production. So why is microservices a win/win with this approach?

The opposite to microservices architecture is the monolithic systems, it’s a system with a server where all your business capabilities are grouped into one big product. With continuous deployment and delivery, we just need to release lots of code and run lots of tests, this can be tricky for the benefit of a smooth delivery. Maybe you need to migrate your database, change many contracts and increase a big and complex domain model every time you will push some new feature to your CI/CD configuration. You can save you lot of problem with feature toggling but you still need to release the whole system. This is when the micoservice architecture will save you from lots of headache. Micorservices are like small systems with their own architecture, components and tools needed for your business capabilities. I often explain them as CRUD services for different business areas like a product service, invoice service, order service, authentication service and so on. I also like to refer to them as a SOLID principle architecture on an architectural level rather than just on the code level.

Microservices shall have single responsibility (S) for its business area, it shall be designed open for extension (O), like version controlled REST APIs. A new version extends its functions. With backward compatibility you will have a subtypes of the API (L) and so on.


Microservices allows you to deploy specific services instead of the whole application when minor changes is applied. You simply deploy that service and only that service code. If you use containers like Windows Containers or Docker you have even better CD benefits though you don’t need to replace any files on the already running service, you just deploy a new container and can easy activate that one as soon you feel comfortable doing so. With other tools like Azure service fabrics you will get even more nice supporting tools for crashes, rollbacks for versions if one deploys fails etc…

Microservcies also benefit from less merge problems despite the fact that it is simple to use different microservices within your team. Discipline implementation of feature toggle minimize the feature branches so you really go Lean with the whole architecture and spend less time on configuration management.
– Less code within the codebase

– Less problem with merges if using feature toggling, version handling instead of     branches

– Less problem with deploys though you now deploy the whole system, just a   small part of it

– You will have benefits regarding scaling each heavily loaded service instead of scale up the whole system

And lots more… But remember, this is not another silver bullet, it’s just a bullet of many

Who is Johan Normén?
Johan Normén is 37 years old, work 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

Twitter: @Johannormen