Description

Dark Launching (DL) is a pattern for delivery [Cartwright 2022] and consists in deploying the code “invisible to everyone except internal employees and small cohorts of real users, allowing us to test and evolve the feature until it achieves the desired business goal” [Kim 2016]. The term was coined in 2008 when Facebook revealed the technique they used to launch Facebook Chat [Limoncelli 2014]. 

To enable DL, “Feature Toggles” (FT) must be introduced to disable user feedback and let the transaction behave differently [Limoncelli 2014] to help debugging. A FT is implemented with a key/value mechanism (say an XML file); the code checks the value of a key which can be the feature identifier, the value tells if the new code should be run or not. Since the code is protected by a FT, it mainly avoids waiting until a big bang release [Kim 2016]. It enables trunk-based development [Hammant 2021] with a “everyone commits to trunk at least once a day” state of mind [Ford 2016].

Dark Launches differs from Canary Releasing because it does not require you to run multiple versions of an application in an environment simultaneously, which you must do for a canary release.

Impact on the testing maturity

Based on the Facebook example, Martin Fowler proposes as an example, a feature implementation roadmap that could be [Fowler 2020]: develop all back-end features and the UI will be held back and would then be a keystone in the new feature delivery process. DL is a mean to facilitate End-to-end (E2E) testing [Kim 2016]. Having a UI enables E2E Testing by Business Owners and internal testing, thus, “helding” doesn’t mean “develop at the end” because it will result in poor User experience. DL should be seen as a “Strangler pattern” [Fowler 2004] which consists in making something new that deprecates a small part of something old; then, after a few iterations, the whole new feature is delivered and replaces any old functionality [Harmmant 2013].

DL also enables simulating load testing-like across the whole product. This is a User-participative load testing and gives confidence that the system will be able to cope with realistic loads. It also provides some information for capacity planning [Limoncelli 2014].

Since DL is strongly linked with design, DL is a Built-in Quality pattern that requires to be introduced soon in the ideation process. It also requires people from Ops who should also take part of this design decision so that they will be aware of deployment constraints (e.g. a new configuration in a new XML file that needs to be deployed to make things run).

Agilitest’s standpoint on this practice

DL is a very useful pattern to enable test scripting ASAP. It clearly avoids waiting for the final delivery to code test scenarios. Although the #nocode technology involved in agilitest enables fast and stable scripting (no tricky algorithm to code and test along with the business), it eases the delivery flow and prevents Testers to generate yet another wall of confusion [Kawaguchi 2020] that will create quality issues.

‍

To discover the whole set of practices, click here.

‍