Sitecore, Feature Toggles, and Deployment Velocity

The ability to separate a code deployment and a feature release is hugely important if you want to really get the most out of your Continuous Delivery pipelines.  The art of doing this is known as creating "feature toggles" or "feature switches". 

What is a "Feature Toggle"?

When doing Continuous Integration and Continuous delivery we are expected to integrate at least daily by committing code into a common integration branch called the "trunk" (see trunk-based development or mainline development).  When merging into the trunk. the code must me production ready at all times but some times we are working on features that take weeks before they are ready for our customer to consume.  How can this work? We must create feature toggles which is any configuration that can be used to enable/disable a feature in any given environment.  Feature toggles allow us to deploy code that is incomplete, scheduled to be released at a later date, has a defect, etc. and have it sleep, un-executed, until we decide it is ready.



Development when using feature toggles can go something like this:

• Get a request to change behavior.
• Rather than modifying existing classes, create new classes (sometimes even new modules) and develop them using unit tests as much as possible.
• When all the unit tests pass, commit to the trunk and pull latest changes from the trunk.
• Refactor the code until the area where the change is needed is isolated and the new and the old functionality can be swapped through configuration or IoC.  When refactoring be sure NOT to break any existing unit tests and you very often need to add more tests to ensure you are not changing existing behavior.
• When the isolation is complete and all the unit tests pass, commit to the trunk and pull latest changes from the trunk.
• Now create the configuration that would allow the new code to swap with the old, test the integration locally, and make the appropriate changes, add new tests, etc.
• When the code is working locally and all the unit tests pass, commit to the trunk with the feature disabled and pull latest changes from the trunk.
•  Use configuration transformations in the environments you want to enable the feature in so that the code can be tested.
• Once the code is deployed to production and there is not change that you will need to disable the feature, clean up the old code and configs making the new behavior the default.

Techniques for "Feature Toggles" in a Sitecore project

This has been my preferred way of doing development for close to 10 years and I try to do it for like this for just about every type of project I work on, not just Sitecore, so it feels very natural to me. I have talked to some Sitecore developers that have told me it doesn't work for Sitecore.  I can tell you, Sitecore projects are the easiest projects to do feature toggles on.  In fact, I would go as far as saying it is built into the Sitecore architecture.  How many of you have a DLL called "Sitecore.Support.##.dll" and a config patch to go along with it? 

Here are some ways have implemented feature toggles in Sitecore:

• Content Item updates
• Publishing restrictions
• Sitecore Rules Engine
• Fallback items (use this item if another item doesn't exist)
• Config patches for pipeline processors, events, providers, etc.
• External configuration management
• External API swap
• IoC Container & factories/factory methods