{{announcement.body}}
{{announcement.title}}
Refcard #305

Getting Started With Feature Flags

As a core component of continuous delivery, feature flagging empowers developers to release software faster, more reliably, and with more control. This Refcard provides an overview of the concept, ways to get started with feature flags, and how to manage features at scale.

Published: Apr. 17, 2020    |    Modified: Apr. 21, 2020
4,984
Free PDF for easy Reference

Brought to you by

CloudBees
refcard cover

Written by

author avatar Nick Rendall Product Marketing Manager, CloudBees
asset cover
Refcard #305

Getting Started With Feature Flags

As a core component of continuous delivery, feature flagging empowers developers to release software faster, more reliably, and with more control. This Refcard provides an overview of the concept, ways to get started with feature flags, and how to manage features at scale.

Published: Apr. 17, 2020    |    Modified: Apr. 21, 2020
4,984
Free PDF for easy Reference

Written by

author avatar Nick Rendall Product Marketing Manager, CloudBees

Brought to you by

CloudBees
Table of Contents

Introduction

What is a Feature Flag?

The History of Feature Flags

What Does a Feature Flag Look Like?

Anatomy of a Feature Flag

Ways to Use Feature Flags

Feature Flags and Technical Debt

How to Get Started

Feature Flags at Scale

The Future of Continuous Delivery

Section 1

Introduction

As any developer can tell you, deploying any code carries technical risk. Software might crash or bugs might emerge. Deploying features carries additional user-related risk. Users might hate the new features or run into account management issues. With traditional deployments, all of this risk is absorbed at once.

Thankfully, the leaders in software development (e.g., Facebook, Twitter, and Uber) pioneered a new method of reducing risk while still enabling rapid innovation and updates in the form of something called a feature flag. Since these companies made the practice mainstream, feature flag management has become an increasingly popular practice across companies today.


This is a preview of the Getting Started With Feature Flags Refcard. To read the entire Refcard, please download the PDF from the link above.

Section 2

What is a Feature Flag?

Feature flags give developers the ability to separate these types of risks, handling them one at a time. They can deploy the new code into production, see how that goes, and then turn on the features later once it’s clear the code is working as expected.

Simply put, a feature flag is a way to change a piece of software's functionality without changing and re-deploying its code. Feature flags involve creating a powerful “if statement” surrounding some chunk of functionality in software (pockets of source code).


This is a preview of the Getting Started With Feature Flags Refcard. To read the entire Refcard, please download the PDF from the link above.

Section 3

The History of Feature Flags

Leading Web 2.0 companies with platforms and services that must maintain performance among high traffic levels led the way in developing and popularizing new deployment techniques. Facebook, in particular, is known as a pioneer of feature flags and for releasing massive amounts of code at scale.

While building its massive social network more than a decade ago, the company realized that its uptime and scale requirements could not be met with traditional site maintenance approaches. (A message saying the site was down while they deployed version 3.0 was not going to cut it). Instead, Facebook just quietly rolled out a never-ending stream of updates without fanfare. Day to day, the site changed in subtle ways, adding and refining functionality.

At the time, this was a mean feat of engineering. Other tech titans such as Uber and Netflix developed similar deployment capabilities as well. The feature flag was philosophically fundamental to this development and set the standard for modern deployment maturity used by leading organizations everywhere today.


This is a preview of the Getting Started With Feature Flags Refcard. To read the entire Refcard, please download the PDF from the link above.

Section 4

What Does a Feature Flag Look Like?

The following is a simple feature flag in code used on an e-commerce site. This software displays a “Happy holidays!” greeting message with a “see more holiday deals” call to action when it is instructed to. The developer has a way to toggle this functionality on and off without re-deploying the code for every holiday or across every instance where it should appear.

It would have a construct like this for the top of a page:

if(feature.isActive("holiday-greeting")) {
   print("Happy holidays," + user.name + "!");

}

And then perhaps something like this at the bottom:

if(feature.isActive("holiday-greeting")) {
   printLink("Click to see more holiday deals", "~/holidayDeals");

}

This is a preview of the Getting Started With Feature Flags Refcard. To read the entire Refcard, please download the PDF from the link above.

Section 5

Anatomy of a Feature Flag

The following terms are helpful to review when discussing feature flags, also sometimes referred to as feature toggles, feature flippers, feature controls, or rollout flags:

Toggle Point

In this example, the toggle point is each occurrence of a “check for feature.”  isActive("holiday-greeting")  represents a single toggle point. Since a feature is rarely just a few linear lines of code, turning a feature on and off can require many, many toggle points.

Toggle Router

The  feature.isActive  function takes the name of the feature flag as an argument and maps the toggle points to the state of that feature flag. In this example, it would be  feature.isActive("holiday-greeting") . It acts as a coherent, single point of knowledge for the state of the feature across many toggle points.  

Toggle Context

The toggle context represents contextual information that the router takes into account when computing the feature’s state. In the  "holiday-greeting"  feature example above, the date would be the toggle context. Other examples might include the logged in user, the geolocation information of the user, a referring URL, etc.

Toggle Configuration

In addition to ambient (known) context, the results of the toggle router for a feature can also be controlled by a simple configuration, as seen in the above example — a manual turn off capability with a toggle configuration.


This is a preview of the Getting Started With Feature Flags Refcard. To read the entire Refcard, please download the PDF from the link above.

Section 6

Ways to Use Feature Flags

The following are various methods for using feature flags:

  • Canary launches
  • Testing in production
  • Turning off functionality with a kill switch
  • Running experiments
  • Removing risk from migrations
  • Improving developer productivity

Source: Better Explained


This is a preview of the Getting Started With Feature Flags Refcard. To read the entire Refcard, please download the PDF from the link above.

Section 7

Feature Flags and Technical Debt

One of the historical knocks on the use of feature flags is that they create technical debt. This is an understandable sentiment since, if implemented by hand, they can lead to massive, ad hoc tangles of conditional logic in the codebase. And that can be downright nasty.

Technical debt is one of the various reasons why it can make sense to consider adopting third-party management systems. These systems can actually save you from technical debt, even as your own, homegrown solution may cause it. But even with such a system, you have to be careful.


This is a preview of the Getting Started With Feature Flags Refcard. To read the entire Refcard, please download the PDF from the link above.

Section 8

How to Get Started

It may seem like turning on or off one little thing in an application is over-engineering. Consider the idea of application logging, however. If a developer were brand new to programming or writing some kind of toy implementation, it might actually be easier to just use their language’s file API to dump some random text to a file than it would be to install and configure a full-blown logging framework.

But how long would that last? Would they hold out until they had to consider log levels? Different styles of appender? Multi-threading? Sooner or later, it would become more painful to keep rolling it themselves than going back and using an established solution.


This is a preview of the Getting Started With Feature Flags Refcard. To read the entire Refcard, please download the PDF from the link above.

Section 9

Feature Flags at Scale

Many organizations start using feature flags with homegrown systems that their developers create. These can be effective for smaller teams and companies. However, once a company is ready to scale their feature flags across their organization and make them a staple of their continuous delivery efforts, they need to consider whether their internal system will scale. Asking questions regarding the following areas can help determine which approach is the best fit.

  • Overhead
  • Visibility and governance
  • Security and data privacy
  • Analytics
  • Developer productivity

As the number of feature flags used internally increases, the answers to these questions become increasingly complex. In fact, in a recent study, 90 percent of developers surveyed said they would consider moving to an external system as the overhead and complexity grew with their flag usage.


This is a preview of the Getting Started With Feature Flags Refcard. To read the entire Refcard, please download the PDF from the link above.

Section 10

The Future of Continuous Delivery

While there are many considerations for adding feature flags into a software delivery lifecycle, the benefits of flagging most, if not all, features are clear. As the methodology and platforms mature, feature flags will become an integrated part of the software development infrastructure, and there may be a time when every feature is released wrapped in a flag for maximum safety and velocity.

At the same time, organizations will move from “if” to “how” in regard to better automating and integrating flags into their strategy. There is a maturity scale that should be considered for getting started with flags — from developing an internal system to most likely choosing an external platform to manage flags and integrate with the greater SDLC.


This is a preview of the Getting Started With Feature Flags Refcard. To read the entire Refcard, please download the PDF from the link above.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}