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.

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.

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.

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.

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.

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.

Testing in production increases QA teams’ confidence that the code will perform as intended in real environments. Flags also provide higher granularity of release to end users based on any of their characteristics in your system (e.g., email address, geography, version), allowing for more targeted testing or rollout, experimentation, and customization. Release teams can move beyond focusing on the moving bits between different target environments to focusing on growing customer value with feature flags in continuous delivery.

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.

The complexity of feature flags only increases as usage grows across an organization, as does the importance of flag visibility and governance across teams and tools. Feature flag usage in silos exists when certain, select developers are aware of specific flags’ status, but there is no structure and process for visibility and decision making across the greater CI/CD lifecycle. This scenario is a recipe for disaster in larger organizations where there are many developers and new features are being developed regularly.

Feature flags can impact the entire CI/CD process, and development teams should be purposeful in how they incorporate them into their tools and processes. Some enterprise feature flag management tools offer CI/CD tool integration out of the box to expedite this process. Otherwise, teams can expect to spend ample development time building out flag visibility views into their current toolsets. Once visibility of flag status and approval flow across CI/CD is common across development, operations, and shared services teams, feature development and release can be expedited with the assurance that flags will not be updated without the knowledge of all teams involved.

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.

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.

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. The same goes for 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.

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

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.