Maksim Kabakou - Fotolia

Tip

Ways to use feature flags in DevOps

What's in a name? Whether you call them feature flags or toggles, this approach benefits enterprise IT all the same. Learn the basics and see how to apply them to DevOps.

The feature flag is a versatile and powerful tool for software developers. However, the usefulness of feature flags doesn't stop with the developers, but can benefit DevOps teams, too.

A feature flag enables conditional execution of code based on simple if-then checks placed within the code itself. Developers use feature flags to enable or disable portions of the code while it evolves, which can facilitate the testing of newly implemented code without branches or forks. In operations, staff can optimize the behavior of live software in production, with key features and functionality under the control of feature flags. Feature flags enable different software options without multiple versions to support.

Basics of feature flags

In its simplest form, a feature flag is little more than a simple variable set as true or false. The feature flag enables or disables a portion of software code -- usually a feature or function -- that is wrapped in a conditional if-then statement, which uses the feature flag's variable. For example, the code portion is executed if the conditional statement is true. It is ignored -- not executed -- if the conditional statement is false.

This generic code snippet demonstrates the flag's simplicity:

theFeatureFlag = TRUE
…
…
if theFeatureFlag = TRUE then {
	              execute the code here
	                        …
	                        …
                                }

Developers, testers and IT operations staff can basically turn new code on or off without disrupting the existing software and infrastructure.

Feature flag use cases

Flags are a simple method for developers and testers to test new features and functionality. Additionally, IT operations admins can use feature flags to tailor the same single software product to the organization's preferences -- or even make automatic adjustments for the prevailing production systems and infrastructure. And, because feature flags are a simple mechanism, there is no proliferation of separate software versions, which can confuse and frustrate users.

Feature flags are popular in DevOps organizations because they require developers and operations to work together to tailor and optimize the software.

Developers can also use feature flags for creative purposes, such as A/B testing. For example, developers want to optimize and enhance a software product's existing subroutine to improve performance on certain hardware. Rather than create separate versions of the software for different servers, developers can use feature flags to switch between the old and new subroutines. Organizations then can enable or disable the optimization depending on their hardware infrastructure.

Below is a generic example of this type of feature toggle:

theNewFeatureFlag = TRUE (or FALSE)
…
…
if theNewFeatureFlag = TRUE then {
                        …execute the NEW code here
                                …
                                …
                                }
else {
                 …execute the OLD code instead
                                …
                                …
                                }

There are static and dynamic feature flags. The feature flags in the examples above are basically hardcoded into the software itself. This setup is common for situations wherein IT admins must test new features or code that likely won't move into the production environment. In cases where the flag needs to be dynamic, developers can write separate text or YAML-formatted configuration files to contain the flag settings, which the software opens and reads at startup.

IT organizations can also use feature flags to adapt software to different operational environments or deployment targets. Consider a software product that must perform complex calculations. A GPU would accelerate and enhance performance greatly, but the software can operate using the CPU, imposing a high load on that CPU.

A feature flag can check for the presence of the GPU and take action:

…run code to check for the presence of a GPU
…now automatically set the feature flag accordingly

if GPUpresent = TRUE then {
	              set theGPUisPresent = TRUE
                                  }
else {
                      set theGPUisPresent = FALSE
                                  }
 
…the software goes on to do some common, boring work
…blah
…blah
…blah
…then the software has to do its calculations

if theGPUisPresent = TRUE then {
     …perform the calculations using the GPU (do it the easy way)
                                   …
                                   …
                                   }
else {
    …perform the calculations using the CPU (or do it the hard way)
                                   …
                                   …
                                   }

This feature flag enables the software to take advantage of a GPU, if present, to perform the calculations faster and more efficiently, but to accomplish the calculations via CPU if necessary. This approach enables many kinds of adaptations within a software product.

Feature flag benefits for DevOps

It's clear how feature flags benefit software developers, but it's less obvious how feature flags can benefit the IT operations team -- or the business.

Let's look at five common ways that feature flags can enhance IT operations.

1. Simplify application deployment. App deployment and updates typically result in downtime. But feature flags enable a software product to include a variety of features and functions that can be deliberately enabled or disabled -- even if it's only for testing and validation purposes. The net result is fewer software versions, less procurement confusion and fewer overall software installations to support.

2. Localize for a global user base. Different regions establish and enforce different requirements for business operations around a variety of factors. Feature flags enable IT admins to configure software for a wide array of operating environments, enabling or disabling the features and functions that are appropriate for that specific demographic.

For example, suppose that country A allows organizations to collect any personally identifiable data, but country B does not allow collection of birth dates. With a 'country' feature flag, the software can eliminate the birth date field from data entry screens when the software is deployed in country B.

Another common use of demographic support is language localization, using feature flags to decide which language is shown in software interfaces and reporting. Thanks to feature flags, the software remains the same for operations work, such as patches, performance monitoring and security scans. Admins follow the same processes for the software regardless of country, rather than having to update and support a separate product in each country.

3. Validate production. Although enterprise software is tested thoroughly before it is released into production, it is almost impossible for software developers and professional testers to check every possible combination of data center hardware, software and other infrastructure and dependencies before a product goes live. When a software update carries the risk of unintended consequences, DevOps staff can still deploy quickly rather than wait for endless combinations of tests. They can add a feature flag to disable new code or switch back to the previous version.

For example, the team creates a complex new algorithm to replace an existing algorithm. But in production with live data, the new algorithm generates unexpected or unusable results for a given set of conditions. Operations can change the software's configuration file to switch back to the previous algorithm -- and create a help ticket for software developers to address the issues.

4. Toggle compute load or optimizations. All software uses some amount of compute resources -- including CPU, memory and network I/O. Software is designed to use advanced resources, such as multiple CPUs, GPUs to handle sophisticated math and large amounts of memory for features such as in-memory data for fast searches and computations. Not all deployment targets can provide all of the compute resources that a software product could use -- some servers might be older or contain fewer processors or less memory than others.

Working with the software developers, IT admins can use feature flags to detect available resources on a server and configure the software's compute load in a way that won't stress the server. Ideally, this could help to maintain good software performance on a broad selection of target systems.

5. Include premium features. Feature flags can also fulfill more business-savvy purposes. Flags can enable or disable advanced or premium features -- such as the difference between free trial, paid and premium software versions. In the same way that a flag can turn a given feature on or off, the same flags can control certain features based on the software's license level. New users can try the software's basic features before paying for it, and then use licenses to gain access to additional features as desired. This also simplifies deployment for operations, although software licensing requires additional management.

Red flag: Technical debt

The use of feature flags can incur some amount of technical debt that eventually must be addressed. For example, if a feature flag is used to test a new feature or evaluate alternative implementations of a given function (perhaps a redesign), it should be removed in subsequent builds as the new code is validated and accepted. Feature flags need regular review and ongoing management. Otherwise, the code base can easily bloat and become unnecessarily convoluted with legacy code segments.

Dig Deeper on Application Rollout Planning and Problems