Dark launching is the term for releasing features to a subset of your users, seeing how they respond, and making updates to your features accordingly. It’s somewhat like what every project manager does to monitor application health, but focused entirely on a single new feature. In this modern age of continuous delivery and deployment, feature releases are happening more frequently than ever before. But at the same time, we need a way to maintain the quality in our applications despite this fast-paced release cycle.
The Benefits of the Dark Launch
A typical dark launch begins by wrapping a new feature in a feature toggle (or feature flag). Once the feature is pushed to production, the development team (or project manager, or even marketing team) can begin turning the new version on for users, starting with a small percentage like 1% or 5% and moving up to larger percentages if everything continues running smoothly.
During this process, end user feedback is being gathered, either with direct methods like surveys or indirect methods like behavior tracking. If the team monitoring the feature notices that it’s causing trouble (users are converting less often, submitting more help tickets, spending less time on the page or in the app), they can turn off the feature flag with the click of a button and have their working application back.
The Drawbacks of Dark Launches (and Feature Flags in General)
The central drawback of using feature flags for anything is that they can easily turn into technical debt. Unused feature flags can clutter up codebases, in the end making it more difficult, not less, to confidently release new features.
This is a solvable problem, however. Managing your technical debt from feature flags can be done by only wrapping a piece of new code in a feature flag if you’re sure you’ll need to turn it off and on, and by ensuring your feature flag lifecycle is visible so you remove unused feature flags after a certain period of inactivity. For more details check out this video or this article.
The Differences Between Dark Launching and Canary Releases
Dark launches and canary releases are fairly similar: both deal with releasing new features in the production environment to a subset of real users before releasing to everyone, and both decouple deployment from release. However, there are a few key differences.
For one, dark launches typically look directly at user response to features on the front end. They’ll be used to release a new option for a shopping cart on an ecommerce store. On the other hand, canary releases are more commonly used to test new features on the back-end. They’ll be used to transition slowly to a new infrastructure.
For another, dark launches are commonly released to a group of users that doesn’t know they’re being tested on and don’t have the new feature pointed out to them in any way: hence the “dark” in “dark launch”. On the other hand, users can sometimes opt-in to beta test canary releases.