{{ !articles[0].partner.isSponsoringArticle ? "Platinum" : "Portal" }} Partner

Agile Release Pattern: Feature-On/Off-Switch

Published by
If you want to release frequently, a problem you may encounter is that some features, even though functionally complete, don’t stand well on their own, but require other features to be valuable to the user. If you want to release the system in this state, you need a way to hide features. A Feature-on/off-switch is a simple idea for dealing with this.

A feature-on/off-switch is some mechanism to hide features from a system. A feature-on/off-switch must be able to remove menu items concerning the feature and also to prevent adventuresome users from accessing the feature. It may be as crude as commenting out code (not recommended!), to enabling the feature based on a complex set of conditions (also not recommended).

I’ve encountered features switches triggered by the following mechanisms:

  • A configuration file or configuration database table tells the system whether to turn the feature on or off.
  • The feature is turned on for users that have a specific role (typically something like BETA_TESTER)
  • The feature is turned on when the system is deployed as /foo-preview, but not when the system is deployed as /foo
  • The feature is turned on after a specific date. This may seem weird, but was a potential solution when we were waiting for a release of another system and operations-freeze during summer was in effect.

There are probably many more conditions you may use to trigger a feature-on/off-switch. Maybe some of my readers have good examples?


Published at DZone with permission of {{ articles[0].authors[0].realName }}, DZone MVB.

Opinions expressed by DZone contributors are their own.

{{ tag }}, {{tag}},

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}
{{ parent.authors[0].realName || parent.author}}

{{ parent.authors[0].tagline || parent.tagline }}

{{ parent.views }} ViewsClicks