Feature toggles in Sitecore development

Very often we chose the “mainline development” model for running a Sitecore project. In such scenario, we need to maintain develop branch as an integration branch. See mainline development vs feature-driven development for more info. That also means that we are supposed to merge all feature-branches to the integration branch once they are done from the developer point of view.

From the other side, we are supposed to initiate releases from the develop branch once it accumulates desired features for the release. This leads to a potential problem of including both well-tested and immature code into the release.

In case of build errors or broken releases, mainline development model encourages us to perform a fix-forward rather than a rollback if possible and the common and most popular work-around for this problem is introducing feature-toggles.

Introduction of such a functionality normally increases the complexity, however makes the immature code to be ready for safe roll-backs. Additional material can be found here.

The main problem that we want the feature toggles to solve for us is disabling the immature functionality that has been released but by some reason does not properly work.

Feature toggles in Sitecore

Sitecore in fact is not the easiest platform to introduce feature toggles, however I will list here core approaches on how they can be implemented, as they depend on the functionality and the nature of the feature they are designed for.

When we think about disabling the functionality in Sitecore we need to focus on certain points in several dimensions:

Where the change reside
  • backend code
  • configuration
  • database 
What is essential for safe feature disabling/rolling back
  • switch code dependency
  • remove/replace/patch configuration
  • remove inheritance in templates
  • hide feature from the editor
How fast/easy we need to be able to roll-back
  • with additional deployment
  • with any change that requires a restart (like config patch)
  • runtime without the restart by changing settings 
The nature of the change
  • is the feature a new isolated functionality
  • is it a change to an existing functionality

Available instruments and approaches

Since every feature is different in size, complexity, purpose and nature, we can only list all available options and approaches that can be applied for specific situations, rather then creating a bulletproof approach for all features (which is hard to invent). 

  • Sitecore config-driven development. One of the core Sitecore’s architectural principle is its plug & play configuration capabilities. With proper usage of the Sitecore configuration factory we can maintain dependencies as well as control default IoC container. Read more – Inversion of Control and dependency management with Sitecore configuration factory. By keeping main services and abstractions configured we can easily apply a config-patch that disables or changes the feature. As alternative, since our custom code is developed with Helix principles, we keep the related configs isolated. Therefore we can simply remove all feature-related configs in order to disable the feature. 
  • Central config-patches location. With introduction of config layers in Sitecore 9, we can utilize the environment configuration layer and create a central location for all patches. Patch file will follow a dedicated naming convention that would describe the feature being disabling with date and reason. This way we will also maintain a control over the applied toggles which can be later translated into a backlog of things to fix for better management.
  • Inheritance based. Helix principles encourage us to develop functionalities isolated and moduled. One of the key principles here is extending templates by inheriting new ones. With implementations based on this principles it also makes it easy to remove inheritance and this way to disable to feature. 
  • Make the feature unavailable for usage. In some cases it is sufficient to simply hide the component/feature from usage so it is not available for selection by editors. For example in the SXA setup, we can remove the component from available renderings configuration.
  • Publishing restrictions. In certain scenarios, it may make sense to deliver items (or new versions of items) and set the publishing restrictions so they are not available right away to the end users.
  • Non-restart toggles. For features with specific functionality it may be important to support enabling/disabling from within a dedicated Sitecore settings items so we do not need to perform restart-causing actions in order to apply the toggle.

Maintaining/cleaning previously developed toggles

One of the main concerns with introducing the feature toggles is their maintenance after the release and regular cleanup. By leaving all the toggles implemented for release purposes previously we leave a room for configuration mistakes for future releases or feature changes. Therefore we need to introduce the process where we keep a precise track on all the toggles and their current state on the solution as well as we need to keep removing the toggles which are not going to be used anymore in order to decrease the complexity and remove rooms for misconfigurations. One of possible solutions could be maintaining the Central config-patches location described above.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s