{{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: Sep. 15, 2020
6,216
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: Sep. 15, 2020
6,216
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?

Ways to Use Feature Flags

Enhancing Traditional Continuous Delivery

Feature Flags and Technical Debt

How to Get Started

Feature Flags at Scale

Feature Flags Will Become Standard in Most Organizations

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.

Feature flags give developers the ability to separate these risks, dealing with one at a time. They can put 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.


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?

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 regard to 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. Recently, feature flags have been used in tandem with continuous delivery (CD) tools to help forward-looking organizations bring features, rather than releases, to market more quickly.


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 and an associated “see more holiday deals” call to action to a site visitor 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

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

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

Enhancing Traditional Continuous Delivery

Continuous delivery can be difficult to truly master in more complex organizations. Feature flags provide guard rails for teams wanting to start or grow their current CD program. Feature flags can enable a shift from full release to feature-level granularity, which keeps release teams on schedule and helps avoid large rollbacks due to former feature dependencies within a release.

Feature kill switches provide the safety of turning off any buggy features without having to redeploy the entire release. 

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 reasons why it can make sense to consider adopting a third-party management system. These systems can actually save you from technical debt, even as your own home-rolled solution may cause it. But even with such a system, you have to be careful.

In general, codebases tend toward entropy — they tend to rot unless you actively curate them. It’s no different with your implementation of feature flag management. 


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, but 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 it would be to go back and use 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

Feature Flags Will Become Standard in Most Organizations

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, features 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...


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 }}