You’ve likely seen the term “kill switch” getting tossed around quite a bit in the development world at this point. Since it’s not a wholly unique DevOps term though, it’s probably best to clarify what it means when it comes to feature management.
Thankfully, it’s more of a misnomer in this case. Well, kind of. Let’s talk about why.
What is a kill switch?
The concept of a kill switch is not confined to just apps and software development. In fact, the term predates anything having to do with a computer or code. The original meaning of a kill switch typically referred to a real-world safety mechanism (like a big red button) or some sort of fail-safe way to automatically shut something like an assembly line or heavy machinery off in the event of an emergency.
In today’s tech terms, you may see kill switches discussed regarding things like VPN services, which often use kill switches as a cybersecurity feature that instantly turns off a user’s internet connection if the VPN server fails, protecting the security and anonymity of the IP address from hackers and other entities.
However, in the realm of software development, a kill switch is a button that can turn a specific feature off when needed. This allows anyone who has been granted access the ability to disable a feature with the push (or click) of a button. And thanks to the simplicity, it doesn’t necessarily have to be an engineer or developer or programmer who triggers the kill switch—something that can come in handy if the feature needs to be disabled as soon as possible.
Using feature flags as kill switches
Feature flags can easily act as kill switches, regardless of whether it’s a permanent flag or one that is meant to only exist for a short period of time. If you wrap a specific feature in a feature flag, and that feature is causing an issue or not performing correctly, you can use the flag as a kill switch for that feature and instantly turn it off so you can fix the issue, test it in production, and re-release it to your user base.
Put simply, using a feature flag as a kill switch enables you to separate deployments from releases.
There are many advantages to using kill switches in feature release management. The main benefit is that the feature flag enables you to isolate a certain feature and make changes to it without the need to perform a total rollback of the release, which can be incredibly time-consuming and complicated. Plus, once you’ve fixed the issue, you can instantly redeploy the feature that was “killed” by the feature flag. This approach allows you to safely test in production and address broken features efficiently.
Supporting continuous integration and continuous delivery (CI/CD) with kill switches
Utilizing feature flags as kill switches is crucial for maintaining continuous integration and continuous delivery (CI/CD) in the development process, especially when it comes to addressing the perpetual challenge of dealing with incomplete features. We’re sure you’re familiar with the scenario of having one developer who has merged their changes into the shared mainline and is ready to be released, while a different developer has not yet finished their changes.
Fortunately, a feature flag in the form of a kill switch provides a way to switch off specific parts of the code (i.e., unfinished changes) while proceeding with the release, preventing users from seeing any unfinished changes while allowing new features to be turned on.
The benefits go beyond user experience, however. Since kill switches can turn off unfinished features and changes, scheduled releases can avoid delays and reduce pressure on developers who may otherwise release the changes to the code too soon and cause issues with the rushed features. The result? CI/CD is maintained, along with the overall quality of the release. That’s a pretty solid win-win, right?
More advantages of feature flags as kill switches
Let’s look at some particular use cases where kill switches can aid in feature management and development.
Testing in production
Back to the topic of testing in production for a moment, as it’s now a widespread practice. If you’re testing on a small subset of users, you’re probably doing so because the feature is not yet completely ready for a full release. In the event of an issue with the feature, you can just use the kill switch to shut it off and prevent those users from seeing the feature without creating any problems with other facets of your code or performing a complicated rollback.
Once you’ve fixed the feature, you can release it right back into production.
Application load management
Kill switches are not just for working around issues with new features; they can also manage network system loads. One example of this would be to turn off certain features to reduce the stress and load on a database during periods of extremely high traffic or usage, such as Black Friday.
If you have an e-commerce site or mobile app, the last thing you want is an unexpected crash during peak buying hours. If the excessive load is threatening the functionality of your site or app, developers can choose to turn off non-essential features for the entire app or a subset of users, essentially freeing up server resources and ensuring that everything remains up and running.
(Note: LaunchDarkly allows you to set automatic flag triggers for scenarios like this. These triggers can turn features on and off when user-defined performance thresholds are crossed. Learn more about them here.)
Mobile apps
Now here’s a handy one. Has something gone wrong what your mobile app release? Feature flag kill switches can automatically revert your app to the latest working version. This ensures that your app remains fully functional while you work on the issues with the new features. And, once again, you can test out each feature as you fix it before doing the full release.
A/B testing and canary releases
As you probably know, A/B testing is a valuable method that lets developers observe how two different versions of a release perform with two different subsets of users. By using a feature flag as a kill switch, you can easily switch between the two versions during testing or isolate certain features as needed.
The same goes with canary releases, which allow you to deploy a feature to a small user base and monitor those users for any issues that may pop up. Should any problems arise, you can use a kill switch to halt the rollout to the larger user base, limiting the feature issues to that small subset of users instead while you make the needed changes.
Compliance and regulation
This is a big one these days. Data privacy laws like the GDPR and California Privacy Act dictate numerous rules and regulations surrounding what user data companies can retain. Sure, you can attempt to go the configuration file route, but that can become a gigantic, complicated mess. Fortunately, using permanent feature flags as a kill switch gives you the ability to turn data retention on and off for certain users, whether that’s location-based or for those who opt out.
Compliance with data privacy laws is non-negotiable, so having a fail-safe method in place to automatically ensure compliance sure seems like an ideal solution. And you can do it with feature flags and kill switches.
Easily create and manage kill switches with LaunchDarkly
With LaunchDarky, software teams can quickly create and manage feature flags and implement Continuous Integration while maintaining an Agile software development process. Request a demo today and see for yourself how the #1 platform for managing feature flags enables Progressive Delivery with DevOps—all while taking the stress out of releases.
.webp)
