Feature Roll-Out

This is the fifteenth blog of a series of posts about the topics Continuous Integration and Continuous Delivery. It explains how important continuous integration is, to deliver software in short iterations to the customer with a high quality standard.

As funny as it sounds but one of the main problems about Continuous Delivery is the permanent delivery. It can be that one feature is not completely implemented yet and spans multiple releases to get ready. The main idea of Continuous Delivery is to split big requirements into smaller junks which still gives the user new possibilities. Unfortunately, this is not always possible and therefore the feature-flagging technique gets important.

Feature Flagging simply means that every big new functionality should be built in a way that it can be easily turned on and off like in the following listing shown:

public void PlaceOrder(Order order)
{
  var orderSystem = CreateNewInstance();
  orderSystem.Place(order);
}

public IOrderSystem CreateNewInstance()
{
  if (FeatureFlagManager.IsAvailable("NewOrderSystem"))
  {
    return new OrderSystem();
  }
  else
  {
    return new LegacyOrderSystem();
  }
}

Advantages of Feature Flagging
This approach gives a lot of advantages and great flexibility during the roll-out of a new version:

• Features can be switched on and off, even for a certain group of users if the feature flag component has been implemented to support it.
• A feature can be smoothly rolled out for a small group of users (like administrators, testers, people from a country, etc...) and does not affect the other users. Therefore some people can test the feature in the real world environment before it is available for public use.
• The roll-out can be done step-by-step. It can be coordinated and monitored what effects it has on the whole system regarding performance or usability. This approach is especially in web applications with many users extremely useful where the load cannot be simulated on a staging environment anymore.
• If any problem occurs the old variant is just one click away and there is no need for a big rollback with possible data inconsistency or loss.
• Furthermore the problems can be identified by a small group of users and do not affect all users at once which might cause an extreme increase of the support tickets.

Problems with Feature Flagging
Of course, the trade-off of this approach is that the design of new components has to be thought through.
The code for implementing feature flagging (e.g. if clauses, factories or attributes) should not spread around the whole code and make it much more difficult to maintain. If a feature has been completely rolled out, it should be even removed to simplify the code afterwards again.
The applied changes (e.g. database schema change) have to be compatible for both code parts. This has to be considered anyhow to support hot deployments where the application stays online during a deployment.
Additionally, the test effort is higher because both cases have to be tested as well as the possible dependencies between these cases.

But in the end I think that Feature Flagging and step-by-step roll-out is a really important concept which is worth to use in bigger web applications. It helps to reduce the risk of deployments dramatically.