Taking the risk out of software releases with feature flags
Dark launching is a process that allows you to release production-ready software features to a small group of users while hiding them from the rest of the user base prior to a full release. A dark launch can also include deploying code to a production environment but without exposing it to any production traffic.
With the rise of Continuous Delivery, development teams are under pressure to roll out new features faster than ever and to get more feedback on those features earlier. That’s where dark launching comes in: a technique that allows your team to gather user feedback, fix bugs, and assess performance—all at scale. Dark launching, a practice enabled by feature flags, gives teams a low-risk way to deploy code more frequently.
What is a dark launch?
Dark launching allows development teams to test the efficacy of new, production-ready features without releasing them to an entire user base.
The simplest way to dark launch is with feature flags or feature toggles, which enable or disable functionality remotely without deploying code. Feature flags are if-then logic statements in your code that allow you to decouple code deployments from feature release. Once a feature is pushed to production, your development team can make it visible to a small group of users, then scale up as needed.
Throughout the dark launch process, software teams might keep a close eye on user responses to decide whether the feature should be rolled out to a wider audience. They’re also paying attention to how the new functionality affects system performance. If the feature doesn’t catch on, users submit negative feedback, or system errors start cropping up, the feature flag can be disabled with one click (without having to restart your application) while the feature undergoes further refinement.
With dark launches, software teams don’t have to rely on risky, all-or-nothing feature releases. That’s why tech giants like Google, Facebook, and Amazon have embraced dark launching to ensure the efficacy of their feature releases and the stability of their app infrastructure.
What are some examples of dark launching?
Any new feature can be dark launched if it’s wrapped in a feature flag or toggle. Let’s look at a few real-world examples:
Scenario 1: I want to release an experimental one-click checkout to see if it increases sales.
To dark launch this feature, you would enable it for 1% of your end users, then to 5%, and 10%, tracking performance along the way (a percentage deployment). If you see that the checkout is increasing sales, then you can gradually increase the feature rollout percentage.
However, if you see that sales are worse, customers are confused, or that it degrades your app’s performance, you can simply roll back the feature for further evaluation and refinement.
Scenario 2: I want to test new application infrastructure without switching all of my traffic.
Before switching all of your traffic to a new system architecture, you can dark launch new infrastructure by routing traffic via a flag specifically geared for configuration management.
Suppose you want to stop maintaining your own queuing system and switch to a managed service. You might create a flag that sends some jobs to the new managed service, while still sending most to the old queuing system (and you have workers set up to listen on both).
Then, you can gradually transition to an all-managed service as you monitor performance and other metrics. For another example, you can ramp traffic up and down during the daytime hours (when your DevOps team is awake), rather than perform a hard cutover during the midnight hours.
Scenario 3: I want to specifically release a feature for beta testing.
This type of dark launch specifically targets users in your “beta” group or target users via an ID (like email or UID.) This enables the new feature for these particular users, while all of your other users receive the current feature set.
At any time, you can add or remove beta users, get real user feedback, and assess system performance. Note, you can also perform a canary launch by percentage—i.e., you deploy a feature to, say, a random 5% of users initially.
You can also run a canary launch with feature flags. In some cases, a canary launch (test) is synonymous with a beta test. But in other cases, you may choose to run an initial canary test on 2% of users to make sure nothing concerning happens in production. And then, you might release the new feature to a small, pre-defined beta group.
Scenario 4: I want to release a new feature to my VIP users first.
Dark launching via feature flags and toggles will allow you to roll out a new feature to your VIP users before doing a widespread release. You can also allow your users to opt-in and out of dark launched features, similar to a self-selected beta.
How dark launches make feature releases less risky
Traditionally, deploying new features can be a risky endeavor. It’s not uncommon for software teams to toil for weeks leading up to launch and hope for the best, only to scramble frantically when things go wrong.
Contrast this higher-risk approach with dark launching, which lets you test new features on a subset of your users instead of 100%. Just switch the feature toggle to “on” and assess the terrain one step at a time. There's no better way to know what works than to run real experiments with real users. Dark launching thus enables the kind of iterative, continuous approach seen in modern software development.
Big, all-or-nothing launches make software teams fragile. However, the more dark launches you do, the flatter your risk profile.
Why DevOps teams love dark launching
Dark launching with feature flags lets DevOps teams focus on building better products, not putting out fires. Here are just a few reasons why that is:
More room to run experiments
Dark launching empowers DevOps teams to run more experiments with new versions of software applications without incurring extra risk. What’s more, they can run those experiments on both front-end and back-end features in production. Thus, when a winning feature variation has been identified, you release that variation to your users immediately.
Real-time feature control
With feature flags, DevOps teams can dynamically control the entire lifecycle of any feature or service from start to finish.
Safer changes to the tech stack
DevOps teams can use feature flags to safely upgrade their tech stack. In essence, they can perform a dark launch but for infrastructure migrations. For example, if you’re implementing a new cloud database, you can create feature flag rules that route a percentage of web requests or specific types of web requests to the new database while routing the rest of the requests to the legacy database. If the new database performs well at this early stage, you can gradually read and write more data to the new system over time.
Reduce or eliminate costly pre-production testing
Dark launching with feature flags allows you to safely test in production. As such, in many cases, teams can remove their staging environments, which often are expensive and labor-intensive to maintain. Instead of devoting time to getting your staging environment to simulate production, you can spend time actually gauging how a feature performs in a real-world production environment—but in a controlled way.
Running canary tests with feature flags
Canary testing (also called a canary release or canary deployment) is a powerful way to test new software features with a small group of real users. Traditionally, canary tests require multiple production environments and complex routing configurations. But feature flags let you expose new features to that small set of users while everyone else uses the original application—all within the same production environment.
Here’s what that could look like:
1. Roll out your application with the new feature, but without exposing it to any users yet.
2. Using a feature management platform like LaunchDarkly, expose the new feature to a small group of users. The majority of users will use the original application, but the canary users will have access to the new feature.
3. Gradually expose the feature to more users until you reach 100% of your user base.
4. Remove the feature flag, and you’re done!
A canary launch isn’t the only deployment strategy that can be optimized by dark launching, though.
Running A/B tests with feature flags
Teams can use feature flags to run A/B tests on a carefully-defined subset of your users in a production environment, while hiding the new feature from the rest of the user base (those not included in the A/B test).
By A/B testing a feature within a small sample of users instead of the whole group, you can mitigate risk and gather more granular data—all in a real-world production environment.
How to dark launch new features at infinite scale with a feature management platform
Software teams that rely on homegrown feature flag systems often end up with a lot of technical debt—and a lot of avoidable headaches. That’s because unused feature flags clutter up codebases, making it harder, not easier, to smoothly and safely release new features. What’s more, as an organization expands its use of feature flags, it can become extremely difficult to support the added scale and complexity with an in-house system.
You can avoid this problem with a feature management platform like LaunchDarkly, which has the enterprise-grade architecture to deliver the speed, scale, and reliability for software teams of all sizes. As you might expect given the name, LaunchDarkly gives software orgs the ability to dark launch at enterprise scale across a wide range of complex use cases.
LaunchDarkly’s sophisticated targeting capabilities, clean UI, robust access control, and enhanced security enable your DevOps team to ship fast and rest easy.
Request a demo of LaunchDarkly’s feature management platform.
.webp)
