Nowadays, in order to remain competitive in the world of modern software development, teams need to figure out a way to continuously deliver new features without delay.
However, there are times when choosing to go for a big bang release is too risky, especially when you have a new feature that you’re not confident how your customers will react to it.
Luckily, modern teams have a number of progressive roll out options to choose from, where they can still go through with their releases but in a gradual and progressive manner to test initial reactions to these releases and gauge customer interest in them.
Dark launch is one such technique to help you to progressively roll out your features.
What is a dark launch?
A dark launch or dark release is a term that refers to releasing your features to a subset of users to gather their feedback and improve your new features accordingly. Hence, it is a way to deploy a feature but limits access to it to obtain useful feedback.
You can think of it as a safe way to release your features to a small set of users to test whether they like this new feature.
Based on the feedback received from these users, you would either release this feature to the rest of your users or you work on optimizing and improving the feature before doing a full release.
How is it implemented?
Dark launches are often combined with feature flags in order to target certain users with features to test them out. Therefore, feature flags would allow teams to enable new releases for particular users while disabling them for everyone else.
You start the dark launch by first wrapping up the new feature in a feature flag, which helps to decouple deployment from release. You would then push this feature into production by toggling it on for your chosen users, starting with a small percentage of users and then gradually rolling it out to more users.
During a dark launch or dark deployment, feedback is gathered and if any issues come up during this launch, especially if you start receiving negative feedback from your users or errors start showing up in your system, you can easily turn off this feature with the help of feature flags.
Benefits of dark release
More experimentation
Dark launches are a great way to gauge customers’ interest in a new feature you’re planning to release.
It gives product teams in particular a way to test out their ideas with less risk as only a select number of users are seeing the feature. Teams can choose to run experiments for both front- and back-end features and then release the winning variation to everyone else.
This will allow them to move forward with new features and discard the ones that performed poorly. This way, these teams are fully confident that their features meet customer needs and ensure their satisfaction.
Higher quality releases and faster time to market
Such a technique allows you to put forward high-quality releases as you are updating your features according to feedback from your most relevant users. It allows developers to see how users respond to and interact with the new features to determine whether any improvements will need to be made.
Thus, a dark launch is a way to test your new feature in a production environment with real-world users. This way, you’ll be able to gather essential metrics to analyze feature performance and closely monitor how your users engage with the feature.
Such feedback will also allow you to find any bugs you may have missed in previous rounds of testing so that they can be fixed before releasing to a wider audience.
The real value of dark launches is that you achieve faster feedback loops with customers for your new features resulting in faster time-to-market to allow you to remain competitive in a fast-paced market.
It also helps to maintain the momentum of continuous delivery especially as it is important now more than ever to quickly roll out new features to your users and get their feedback.
What’s more, once you release your feature to all users, you’re fully confident that you’re only releasing high quality, bug-free features.
Reduced risk
Another major advantage is that you are reducing risks that come with releasing new features and minimizing their impact because you are only allowing a small group out of all your users to access your new features.
In this sense, dark launches are a safe way to test new features in a production environment instead of opting for a separate staging environment which can be costly and use up resources.
With feature flags, you can further mitigate risk and be even more confident that you’re fully in control of who sees and doesn’t see your new features. In case anything goes wrong, you can easily roll back the feature by simply turning the flag off.
However, be careful when implementing dark launches using feature flags which may lead to technical debt, especially if your flags are not managed properly over time. You will need to make sure that you have an efficient feature flag management system such as AB Tasty’s server-side functionality that offers dedicated features to keep your flags under control.
Dark launch vs other methods of progressive delivery
You might be wondering what is the difference between this method and other progressive delivery methods such as canary deployments or ring deployments.
The objectives of such types of releases are the same, which is to gradually and progressively release new features to a small subset of users, letting you test the waters to make sure they work properly before releasing them to everyone else.
One major difference is that canary deployments are usually done on all releases of your app and not just individual features and can be used to, for example, slowly transition to a new infrastructure while dark launches allow you to test features on the front-end before rolling it out to everyone else.
However, when you use feature flags, you will be able to perform a dark launch for infrastructure migrations to upgrade your tech stack as well as test back-end features in production.
Furthermore, a dark launch isn’t usually something users opt-into and the new feature isn’t pointed out to them, hence why we refer to such a launch as ‘dark’.
If you want to give users a choice and allow them to opt-in, you can ask a limited number of users to sign up to test a new product. This is also referred to as beta testing.
Therefore, because dark launches are not necessarily beta tests, you must be careful that you are releasing a good enough feature since these users will be less tolerant of any issues that arise during testing.
However, these two terms are sometimes used interchangeably as canary deployments can be considered as a type of ‘dark launch’ that specifically targets a beta group and is based more on a percentage rollout to users.
You will also need to make sure that you have enough users to pick from since dark launches require a considerable user base to get sufficient feedback so this is not a technique suited for new apps.
To sum up
Dark launches are a good way to ensure the efficacy of your future releases through real-world feedback and to maintain the stability of your app infrastructure, allowing you to deliver faster and higher quality products to your customers.
Using feature flags to perform a dark launch is a way to accelerate the release process while minimizing the blast radius and mitigating the risk of new releases.
