{{announcement.body}}
{{announcement.title}}

Feature Flags Are The Answer To Retailers’ Holiday Nightmares

DZone 's Guide to

Feature Flags Are The Answer To Retailers’ Holiday Nightmares

See why feature flags could make the difference in your next deployment with this scenario-based article that contrasts them with canary deployments.

· DevOps Zone ·
Free Resource

Traffic cone

Feature flags for fast targeted deployments

It was 5 p.m. on Thanksgiving, and everyone had left their homes, full of turkey and stuffing, to drive down to your store for the Black Friday sales. Your team was excited about the new feature implemented on your app that will make it easier for customers to locate sales and speed up the check-out process. You had been working on the code for months, running tests and ensuring that everything will operate efficiently on the day. You couldn’t wait to review the amazing data and upgrade this feature for Cyber Monday.

This new feature was supposed to allow your customers to view a digital interactive map that would inform them where all the sale items were located and how many are were still available, while also allowing them to view regular priced items. It also allowed customers to check out with their smartphones. 

“This is going to make customers’ and employees’ lives a lot easier,” you thought,  “and maybe even lead to a customer satisfaction award and a promotion." 

Your boss and stakeholders were eagerly awaiting the feedback, and the PR team had a press release ready to send to the media about the success of these new features — no pressure!

You may also enjoy: The Value of Feature Flags in CI/CD

The features went live, and the crowd burst into the store. All was going great, and everyone was loving the new feature. The routing of the new features to users that signed up for them prior to Black Friday was working exceptionally well. Your email and phone were blowing up with congratulatory messages and thank yous from your team. A huge smile stretched across your face, but that smile soon disappeared and the content of the messages soon changed. The app began to crash when customers were trying to access the new interactive map feature. Customers started to angrily tweet and were getting irritated with your employees. All of this was being caused by a bug — one that wasn’t detected during testing.

In the midst of the madness, you got a report on the other new feature. It was working great, and customers were checking out through the app with ease. The feedback was amazing. That smile returned to your face again, but then quickly disappeared once more as you remembered that you used a canary release. You’d have to halt both features to fix the bug.

You started to panic at the thought of having to have that dreaded talk with your stakeholders where you explained why the entire rollout has to stop. Now your weekend plans of eating leftover turkey sandwiches were ruined. You’ll be spending your weekend fixing the bug and implementing the full rollout again. You punched the nearest Christmas tree and mumbled some not-so-festive words under your breath.

All of this could have been avoided if you had opted to do a feature flag rollout instead of a canary release. You’d be stopping only one of the features instead of the entire rollout.

By now, you must be thinking, “But both are common feature release strategies for testing in production, increasing the safety of continuous delivery and deploying faster. Both aim to minimize the fallout of unforeseen problems and build confidence in a release. Both also gradually expose new code to users on the production infrastructure.” Correct! However, that’s where the similarities end.

The differences between canary releases and feature flag rollouts are significant enough to impact development velocity — and your Thanksgiving weekend plans.

A canary release operates within the infrastructure networking layer to deploy the new features to a small subset of production machines. The canary phase starts with most machines running the version without the new features and a smaller subset of machines running the version with them. A traffic router (usually a load balancer) will route users to the two sets of machines with stickiness turned on to ensure that each user has a consistent experience. Users routed to the canary release will keep getting access to the new features while the rest will not.

Canary releases are orchestrated by your infrastructure and DevOps team. They also have limited targeting capabilities. They either target a percentage of your incoming traffic and/or whitelist certain IP addresses.

While canary releases do make a lot of sense when the thing you are changing is a piece of infrastructure itself or an app that is effectively a single black box, they are not the way to go when you have a manifest of multiple features contained in a single deployment package.

A feature flag, meanwhile, operates within the application code and deploys the new features to all of the production machines. Exposure to the new features is limited to a targeted subset of users by hiding them behind a flag. The traffic router now lives in the application code and is controlled by an if/else statement. This if/else statement is the feature flag. A simple function call made by the if/else statement decides which code path gets executed for each user. The rules for that if/else can be changed on the fly at any time.

Feature flag rollouts are orchestrated by your engineers, product managers, or Agile testers and have infinite flexibility of targeting, allowing any group of users to be affected.

See the difference yet?

But the biggest and most important differentiation is the way these feature releases operate with rollbacks. Canary releases operate at the level of deployment, which means that if there are any issues or bugs, the entire deployment is rolled back. So, if you’re implementing two new features at the same time, it means both have to be rolled back and launched again on another day.

However, feature flag rollouts operate at the most granular code level, which means that if two new features are being implemented and an issue or bug is found, one feature can be rolled back independently of any other without a hotfix or redeployment.

Not having to roll back the entire deployment means avoiding an all-hands fire-drill, not delaying the rest of your team from completing their part, not having an awkward conversation with your stakeholders and being able to continue with your weekend plans.

Feature flag rollouts make for happier and faster-moving engineering teams due to the fact that they can simply make the bug-infested feature fade to black and allow the working feature to shine. It also makes for happier customers, a great reputation and pleases stakeholders, so your holiday plans of eating great food and unwrapping a new pair of socks while falling asleep on your couch in a onesie won’t be disrupted.

Further Reading

The Ultimate Feature Flag Guide: What They Are, How to Use Them, and How to Get Started

Why Having a Feature Flag Microservice Is a Bad Idea

Topics:
feature flags ,canary release ,devops ,feature releases ,rollbacks ,deployment velocity

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}