Dark launching is a process that allows you to see how a subset of your users respond to a new feature and then make necessary changes accordingly. You can implement a dark launch in several ways, but the best way to do so depends on the type and complexity of your application.
It's easy to dark launch a new feature on a web application with a simple web app. You can duplicate the page, change the name, and update the page. Then, only the people who know the new page name will be able to see it. When it's time to launch the new product to all of your customers, you need to take it out of dark mode. There's an easy way to do this: delete the old page and rename the new one.
The dark launch is a great idea that has some downsides. For one, if the new page is available with the old page for a long time, any common bugs have to be fixed twice. Furthermore, because the new page has a new URL, any links from other pages in the app will point at the old page, making it difficult to test cross-page flows.
Dark launches and canary releases are different processes that both deal with releasing new features to a subset of users before releasing them to everyone. But despite their similarities, there are some key differences.
Dark launches allow you to react immediately to how your customers respond to features on the front end. On the other hand, canary releases are more commonly used when transitioning slowly to new infrastructure. Dark launches are new features that are released to select users to iron out any errors. They are called "dark" because the user doesn't know that they are being tested on. Beta testing, on the other hand, is when a limited number of users can sign up to beta test a new product.
Reduce cycle time, release complexity, and deployment stress
No salespeople
No credit card required
Cancel anytime
To solve the problems relating to dark launches, think about using feature flags, also known as feature toggles as a best practice. A feature toggle is a way to give an application more information and then change the way it behaves based on that information.
For example, to test a new feature in a web app, you can put both old features and new features on the page. Then, you can switch between the two depending on which variation you want the user to see.
DevCycle is a feature management tool that allows you to leverage feature flags to ship faster, reduce risk and maximize the impact of your canary release. By leveraging feature flags, you can increase your release cadence by minimizing release complexity.
Through continuously deploying and testing in production, you can organize your feature flags in several environments with our APIs without needing to leave your workflow. Developers, product, and marketing teams can toggle a feature on or off in the DevCycle dashboard to control who has access.
Your development team can also predetermine a rollout schedule to specify which users have access to a new feature and at what date. This means you can create a predetermined rollout period for a release and let DevCycle gradually deploy it based on the rollout schedule your team set up.
DevCycle also enables you to maximize the impact of your canary release through zero latency experimentation build for developers. Iterate and optimize features with the ability to dynamically modify content in production without redeployments.
Engineering teams can employ continuous integration and continuous delivery to keep up with the competition. This practice will allow for faster development cycles, as well as the ability to deploy new features without risk of errors. Practices like dark launches can also help mitigate risk.
Want to use feature flags to start using dark launches and improve your software development workflow? Get started with a free trial of DevCycle.
DevCycle started from us wanting to build something we want to use for ourselves. We're documenting every major decision and technology we're choosing to use.
Learn More About What We're Building