A continuous delivery practice, which allows you to release new features only to a group of users and invisible to others. The Dark Launch enables the team to understand the real life impact of new features, which may be unexpected for users in the sense that no users asked for them. These type of release allows the team to only expose a part of the user population to the new feature and carefully observe and measure the user interaction. It is one of the last steps for validating a product/market fit for new features. Dark launching is a quick and easy way to present new features to your end users and then capture their behaviors and feedback. Rather than launch the features to your entire group of users at once, this method allows you to test the waters to make sure your application works as planned before you go live.
This is a feedback loop practice, which allows the team to get prompt feedback from real life use of their changes. The Dark Launch provides safety by limiting the impact of new features to only a subset of the users. It allows the team to build better understanding of the impact created by the new feature and the ways the users would interact with it. Often novel ways of interaction can surface, ways which were not initially envisioned by the team. This can be both positive and negative and the limited availability allows the team to draw conclusions from the real life use and make a decision on if the feature will be made widely available, further developed or discontinued.
The biggest risk to consider before going live is how your users will react to and navigate through your application. Before you launch, ask yourself three questions:
Once you’ve answered these questions and decided it’s time to go live, it should be a walk in the park — assuming all your findings during the first steps were positive. In most cases, all you have to do to go live is simply disable the old functionality of the feature you wrote. This can either be done by removing the old code or by disabling it in the configuration.
After you’ve gone live, monitor the behavioral changes of your application and your users to see whether the deployment was a success. If everything is going well, give yourself a pat on the back! Most of the time, though, it’s not quite that simple. You’re never 100 percent positive the application is working correctly, so you’ll want to keep the old code available or running for a few days or weeks to ensure there are no bugs that pop up.
Feature toggles are an enabling practice, which allows for Dark Launches to be implemented in existing products. Dark Launch is similar to A/B Testing in the sense that it is only exposing a part of the population to the new feature, but unlike A/B Testing, the new feature can and is typically a completely new feature and not just a small tweak of an existing one. The purpose is different too as A/B Testing is looking to improve the product performance in terms of getting business outcomes from an existing feature, while the Dark Launch is often exploring the possibility to extend the market by adding new features. Dark Launch is similar to the Canary Release as they both expose only part of the population to a feature. The Dark Launch is focused on understanding the way users will react and use the new feature, while Canary Release is really focused on the technical performance of the changed product or the individual feature (if using it can be isolated in the architecture).
Check out these great links which can help you dive a little deeper into running the Dark Launches practice with your team, customers or stakeholders.