IT organizations have a wealth of options for their application deployment methodology, from a straight cutover to a variety of advanced launches, such as canary, blue/green and feature flags.
DevOps organizations can implement changes from one version of software to the next by embedding switches into the code. These feature flags, also called feature toggles, turn on and off application features via the configuration instructions.
Feature flags aren't just for software developers and engineers, said Chris Condo, principal analyst at Forrester. The flags originated in software development, but that isn't their endpoint.
"People are using them not just to govern this progressive release strategy; they're using them as part of their day-to-day logic of how their apps operate," he said.
DevOps desynchronizes release cadences
DevOps has emphasized a shift-left movement in IT, which pushes tasks like test and operations management earlier into the code-creation process. Especially with modern distributed applications that can be split into hundreds -- if not thousands -- of microservices, release cycles are blown to pieces, and thinking must change. Each microservice releases on its own schedule, which makes testing difficult, because there can never be a truly up-to-date test environment.
Chris Condo
"A lot of teams face a situation where the only source of truth is production," Condo explained.
If the only way to be sure code works in production is to test it in that live environment, developers must test inactive code. As the number of features and services on IT's docket expands, release management becomes increasingly difficult for both the software developers and IT operations.
"The only way to do that is with these feature toggles, where you can directly [control] whether that feature is on or off," Condo said.
Toggle set to A: Practical use in IT
Feature flags are conditional on/off switches placed into code deployments. They operate much in the same way that the <!-- --> HTML tag comments out whatever code or text lies within, rendering it invisible or inactive. Flags, for example, enable software teams to tentatively add a feature to a live application by inserting the new, inactive code to ensure it integrates smoothly with the standing environment. Then, the admin flips the switch to activate.
People are using [feature flags] ... as part of their day-to-day logic of how their apps operate.
Chris CondoPrincipal analyst, Forrester
DevOps shops can use feature flags in conjunction with other application deployment methods, including what Condo referred to as a progressive release methodology. Rather than the typical pattern of releasing approved code and then deploying that release to production, a progressive release instead deploys latent code to production, where it is then tested or held until a designated time and switched on. A feature flag, in this instance, makes that final changeover as simple as pressing a button.
But feature flags also create significant technical debt if left unchecked -- technical debt that IT admins must clean up or otherwise manage during troubleshooting, new releases and other ops tasks.
Organizations that rely on feature flags have two options, Condo said: "They could leave the feature flag there, because they have some greater strategy about how they manage things ... or [flag code removal] becomes part of the normal routine, and [admins] remove that code so that it never gets turned off accidentally and [there are] fewer flags to manage."
To show how feature flags work in real life, Condo provided two example scenarios.
Taking software deployments global
An automotive manufacturing company based in Germany uses feature flags to control feature release to global demographics. Because software is a differentiator in the automotive industry, a manufacturer must carefully select which features reach which demographics.
Each country has its own security, governance and privacy laws -- not to mention translation variations -- and consumers must opt in to specific features. And creating specific software variations for cars that ship to the U.S. versus those that ship to France involves a complete transformation of workflow.
"This company uses feature flags to manage localization of the different workflows, because it's easier than trying to build it into the code base," Condo explained.
The manufacturer has the opportunity to instruct its satellite offices in every location on which flags to toggle on for their particular demographic via a centralized switchboard.
"They found a very flexible pattern [to] expose those different kinds of [localized] workflow patterns to their users," he said.
The key to smooth management
Another creative use for feature flags in DevOps organizations lies in a SaaS vendor's license package management, Condo said. This particular SaaS vendor offers three service tiers -- silver, gold and platinum -- managed with license keys. It manages those license keys with feature toggles. If User A wants to explore the benefits of a higher-tier service -- through a transition from gold to platinum, for example -- the vendor offers a trial period.
"They just add that user's user ID to the platinum package for a week, and if [the upgrade is declined], they just move User A back over to the gold [tier]."
Alternatives to feature flags
Not every organization is ready for the infrastructure coding and technical debt management required to successfully use feature flags. But teams can improve release management in other ways that fit comfortably with existing operations techniques.
Dark launches apply code to a portion of systems, such as those for a particular segment of users or internal reviewers, which means a disruptive code failure doesn't crash the entire production environment. They're also called canary launches, as the initial group acts as a warning system for problems with the launch that would affect everyone -- much like canaries did for poisonous gases in coal mines. Organizations that follow a phased launch schedule gradually increase the number of users that see new code.
A cutover launch moves everything from the old to the new and can be disruptive. But that doesn't mean a cutover launch is dangerous or cavalier. Cutover launches demand precise planning and communication to enact a perfectly coordinated changeover and ultimately form the final step in most phased launch methodologies.
"If you're changing the underlying infrastructure or architecture, you might choose the strategy that best fits what the change actually constitutes. So, you might find that you can't completely get rid of a hard changeover," Condo said.
App deployments that require a hard cutover benefit from the safety net of a blue/green deployment methodology. This cutover method requires two identical environments, one of which is idle while the other is live. Once the updated environment is suitably tested and functional, IT activates the idle environment and redirects traffic to it. But the original setup remains in case the organization needs to revert to it quickly.
While blue/green deployments require double the IT resources of conventional deployments, they enable teams to test new features in production without having to learn feature flagging or how to segment deployments into phases.
Dig Deeper on Systems automation and orchestration
Chris Condo
