Feature Toggles - Separating Release From Deployment

Posted 02/01/2016

A problem that organisations can be faced with when scaling agile development is how to get features delivered to production quickly when there are many teams working on the same piece of software. Initially this might result in a release coordination problem, where branch merges and the releases to test or production environments are performed serially, causing delays; as well as bigger, more infrequent releases, and unhappy customers.

One of the first steps in this case is usually to refactor the structure / architecture of the software. Including breaking it down into smaller, more decoupled components that can be developed, maintained, and released separately. If this is not feasible or has been done already, then separating release from deployment with feature toggles can be a strategy to consider.


What is a feature toggle?

A feature toggle (or feature flag) is a switch in the software that turns functionality on or off. There are frameworks available (open source or proprietary) that can simplify the implementation and management of them.


How does a feature toggle help with this problem?

When a feature is behind a feature toggle, it allows the following to happen:

  • If a defect is found in a build of the software where there are other independent features that would add value; then the build could still go live but with the defective new feature turned off. This doesn't stop the team that worked on the feature from working to fix it, and creating a new build that is then released afterwards with the feature turned on.
  • It allows features to be deployed to production at a convenient time operationally, and then empowers product managers to release the feature to users by turning the feature toggle on (and at a time that’s convenient for them, without being blocked because it would have otherwise been impractical to deploy at that time).
  • Enables features to be turned on across the full server estate at the same time (where deploying without feature toggles could result in a longer rollout period over load balanced servers, resulting in a possible inconsistent user experience.)
  • Reduces merge pain if developers are committing their new features to main / trunk behind feature toggles, and as result commit more frequently.
  • Features can be turned on or off when demonstrating to users / customers before release for feedback.
  • It’s a stepping stone to doing A/B and multivariate testing.

Gotchas if left unchecked

Feature toggles can solve certain problems, but they do so by adding configuration complexity. This needs to be managed correctly, or it can cause unexpected results:

  • Ensure automated tests are ran against the build of the software and the configuration of the feature toggles (on / off states) before committing to production.  This is particularly relevant when the feature toggle is a component part of a bigger feature, or when there are dependencies between feature toggles.
  • Make the feature toggle states clearly visible, and communicate changes to the product / development teams and other relevant stakeholders. Some feature toggle products provide email notifications etc.
  • Have a good way of synchronising the feature toggle states between environments. When the number of feature toggles increases, an incorrect feature toggle configuration on a developer's machine, or test environment could result in incorrect decisions being made in the dev and testing process resulting in lost time.
  • Retire unused feature toggles, otherwise they become technical debt that creates unnecessary complexity, and potential for confusion and error.

In many companies deployment pipelines, feature toggles have become a key component of achieving Continuous Delivery, and increased agility.