When planning a deployment of a new application or feature, it’s a good idea to test it first to gauge its potential and, more importantly, ensure it works in production.
To do this, you can predeploy it in production and either have your team test it, or have a select group of users try it for a while. This can help you find out whether the feature is worth the development time or whether you want to change your strategy.
This process is called “dark launching,” and it helps your team members test changes and see whether the code they developed is working in production. These test users may provide feedback on the changes you make, and you can monitor how the application is behaving when utilized by end users.
Dark launching is a popular testing method in the tech world, and tech giants such as Facebook and Google regularly use dark launches to test new features gradually by releasing them to a small group of users at a time. This way, the teams can see whether users love the applications, hate them, or want adjustments made.
They’re called “dark launches” because companies typically don’t publicly announce they’re rolling out new features, and the applications are released very gradually — typically 1 percent of users see it at first, and then it’s rolled out to 5 percent, then 20 percent, and so on. And if it doesn’t go well — for example, if something goes wrong during a deployment and the old infrastructure or code is still in place — 99 percent of the time, it’s easy to roll back the changes and fix the problem.
Implementing Your New Features
By deploying changes next to the already-working code, it enables you to provide your new features to a set of users to measure whether they like the new feature and whether it works as expected.
If you can’t release your new features alongside an already working code due to the number of changes you had to make to the application, there is an alternative. To prevent a big-bang deployment, you can set up all the changes and infrastructure you have before the actual release. This way, you only have to make one or two changes to get the application to the live state. Beforehand, you or your team will be able to reach the application in order to test it on the new production systems.
Feature flags or feature toggles can also be useful to separate your rollout from code development, though they’ll need to be managed properly to avoid technical debt. But by utilizing feature flags, it’s easier to implement dark launching as part of the delivery process. Every new feature will be able to be dark launched because its rollout is separated from code development by feature flags or toggles.
Taking Your Application Live
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: Are your users able to find the new feature? Are they aware of the change? Do they even need to know about it?
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.
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.