A Feature Flipping Implementation

When we started thinking about moving from 2 to 12 releases per year it was clear that we had to manage the fact that some new features would have to be in a deactivated state until the ‘epic’ user story was ready to go.  Often small bits of functionality don’t make sense on their own at least from the marketing and sales point of view.  After reading about feature toggles it was clear that this was what we needed.  But the question we posed ourselves was how do we go about implementing that ?

Our product is used by organisations of all sizes to help organise their training needs, create training courses, register staff in online and presence-based courses, provide tutoring and reporting tools etc. etc.  In most cases our clients (especially large organisations) have their own particular structures and particular workflows and most notably their own differing rules on who can do what and to whom.

So from day one we have had the requirement to provide a product that is very finely configurable.  Access to each and every functionality is controlled by a particular privilege.  For example are you allowed to view a certain user’s profile ? There’s a privilege for that.  Can you edit a certain user’s profile? There’s another privilege for that.

Around the same time Sales had been pestering us to give them the possibility of deactivating certain features.  Customer X does not want functionality Y and hence expects to pay less.  Can we make functionality Y invisible to client X?

Quite quickly we realised that our toggles were already in place in the form of these privileges and by grouping them according to some given licence key we could control blocks of features by providing a new licence file. 

Our privileges are heavily used behind the scenes in plumbing code such as by the sitemap provider which validates access to every page.  Otherwise, the visibility of buttons and other page elements are controlled by a function call to the role provider service passing in the privilege name as a parameter.  The important thing here is that we don’t have any specific code that you might want to remove later once a feature is deemed ready.  We only have privilege checks which are functionally always necessary.

btnEditUserProfile.Visible = Page.IsUserInRole(“Edit.User.Profile”);

All our privileges (and other stuff such as application parameters) are declared as application metadata which have a property “LicenceKey”.  This links the metadata to a known internally published licence key which in turn can be added to the client’s licence file if required.  For features in development that are not ready for deploying we use a private licence key such as “dev” or something more specific when there’s the possibility of activating a block of functionality for a client demo for example.

We were lucky that we already had the privilege functionality in place and it was mostly a matter of refactoring the metadata and a small number of services to take account of the licence key.  It’s so far been a great success and very easy to develop fully ‘toggable’ features with very little effort.