Skip to main content

Feature Types

Overview

Feature Types within the DevCycle dashboard are a way of describing and handling Feature Toggles / Feature Flags in more complex and diverse ways. Typically one would use a Feature Flag tool to do extremely simple toggling of a feature to be on or off. In reality, this simple approach can be very limiting as you become more familiar with the concept of Feature Flags.

With this in mind, DevCycle prefers to view Feature Toggles as a part of a Feature. A Feature may have one or many toggles, and may have states other than On or Off. A Feature may have something other than a boolean that should be variable across the potential states (or Variations).

To help with this concept, when creating a Feature in the DevCycle dashboard, you will be able to choose a Type which will pre-fill some options in the Feature and help kick-start your usage of the Feature.

This article outlines the various Feature Types, what they do, and how to think about them.

For more information on Feature Types and using Toggles, read Feature toggles (aka Feature Flags) by Pete Hodgson on the Martin Fowler site. It contains deep information on when to use feature toggles, how to use them, and how to think about them. Much of the DevCycle methodology is based around the concepts in this article.

Types within DevCycle.

Release

Description

Use a Release Feature Flag to separate a feature from deployment and allow for a true continuous delivery (development) cycle. Use these flags to allow for in-progress features and code to be merged into your main branch without concerns. A release could be transitory or long-term in nature depending on your plans with it. If the Feature is completed and deemed not a risk after reaching a complete rollout, the toggle can be safely removed from your code to keep things clean.

Example Uses

  • Ship incomplete, untested, or otherwise unready code to production which will not be turned on.
  • Allow product managers to control the release and rollout of a feature on their own schedules.
  • Merge incomplete code into main branches without interfering with testing or the release process.
  • Coordinate a feature release with a marketing campaign so the feature is not released early but not held back by a deploy.
  • Deploy features at the last moment possible.

Defaults set in DevCycle

When a Feature is created with this type, the following will be pre-set in the Feature:

  • A Boolean Variable will be created with same key as feature. This can be considered your "toggle" or "flag"
  • There will be two Variations: Variation ON and Variation OFF.
  • The Boolean variable will have On / Off set to true/false in each Variation accordingly.
  • Development and Staging Environments will automatically target "All Users". Rule will be named "All Users"
  • Rules will be set to serve Variation ON.
  • Development and Staging Environments will be enabled immediately.
  • Production Environment will not be enabled and will not have a default rule.

Ops

Description

When releasing features with unknown performance implications, use an Ops Feature Flag to ensure the safety of your systems during the deployment of the feature. These types of Features may have short-lived toggles (once safety is confirmed remove it), or may remain in the system long-term as there may be reasons to have an emergency kill switch.

Example Uses

  • Enable a slow rollout of the feature automatically to allow for monitoring of related systems.
  • Schedule a full release date of a feature once system stability is confirmed.
  • Maintain a persistent kill switch that is easy to hit at any time.
  • Connect this Feature to toggles on other features to all for rollbacks of other related infrastructure when not needed.

Defaults set in DevCycle

When a Feature is created with this type, the following will be pre-set in the Feature:

  • A Boolean Variable will be created with same key as feature. This can be considered your base "toggle" or "flag".
  • There will be two Variations: Variation ON and Variation OFF.
  • The Boolean variable will have On / Off set to true/false in each Variation accordingly.
  • Development Environments will automatically target the current user (if email is set).
  • Rule will be set to Variation ON
  • Development Environments will be enabled immediately.
  • Production and Staging Environments will not be enabled
  • Production will have a pre-se stepped rollout of Variation ON set up with empty schedules with 10%, 50%, and 100% steps.

Experiment

Description

Experiments can be used to send users down various paths or provide different functionality of a single feature, either as an A/B test or multivariate testing. Experimentation is extremely useful for making data-driven decisions by monitoring the impacts of various code paths. These types of Features can change quite often and should be modified to continually optimize the results of the Experiment. The Experiment type could be used for many things such as:

Example Uses

  • Personalization: Giving users with specific properties specific variations of a Feature
  • Testing Wording on your website or application to drive more engagement or a specific action
  • Setting weights as variables on an Algorithm, using various variations to test tweaks of weights
  • Test multiple landing pages against each other on a website via url split testing
  • Change entire Website or Application flows to reduce drop-offs
  • Modify Ad timing to determine ideal length

Defaults set in DevCycle

When a Feature is created with this type, the following will be pre-set in the Feature:

  • A Boolean Variable will be created with same key as feature. This can be considered your base "toggle" or "flag".
  • There will be Three Variations: Variation A, Variation B, and Control. Use Control to represent your applications DEFAULT behavior so it may be compared against the other variations.
  • The Boolean variable will have Variation A and Variation B set to false and true, respectively, with Control being false.
  • Development Environments will automatically target ALL users. Audience name will be called "Testing group."
  • Development Environments will be enabled immediately.
  • Distribution will be set to 33/33/33 between Variations A, Variation B, and Control
  • Production and Staging Environments will not be enabled and will not have a default rule.

Permission

Description

A Permission Feature is used to manage different product features that are gated based on specific user's properties. These Features can contain many toggles which define subsets of functionality available to users in this feature. These types of Features in DevCycle can be used for many useful things.

Example Uses

  • Creating sets of "premium" functions that are OFF for users who are on a free plan.
  • Allowing for beta opt-in for new features and functionality
  • Gating users based on their permission levels within your platform, each piece of functionality behind a toggle, and each variation being a different role.
  • Allowing all internal users to have a set of features far before release.

Defaults set in DevCycle

When a Feature is created with this type, the following will be pre-set in the Feature:

  • A Boolean Variable will be created with same key as feature. This can be considered your "toggle" or "flag"
  • There will be two Variations: Variation ON and Variation OFF.
  • The Boolean variable will have On / Off set to true/false in each Variation accordingly.
  • Development, Staging, and Production Environments will automatically target your organization's Email. Rule will be named "Internal Users"
  • Rules will be set to serve Variation ON.
  • Development and Staging Environments will be enabled immediately.