Risk Mitigation

Continuous integration and continuous delivery help development teams deploy faster. Release maturity models dictate the level of automation. However, automation always has an associated risk factor. No automation is fool-proof against catastrophic failure. Feature flags can provide a safety net. The flags can be used to turn off harmful code until a solution is found. It can be even used to regulate experiences based on criteria like user preference or location. It gives a development team more power to control the software experience in the real-world. The following are a few examples of how.

Turning off Functionality With a Kill Switch

In the same way that organizations can increase the number of users who see a feature, they can also decrease that number to zero, creating a kill switch. This capability comes in handy when a feature doesn’t behave as planned. Developers can roll back the change and let life go back to normal for users without redeploying and emergency patching. It’s also useful for sunsetting and then decommissioning legacy features. Kill switches absorb much of the risk, stress, and overhead from a release for developers as it’s simple to roll back a feature. This in turn gives them more confidence to experiment and work faster to create features!


Shift Testing to Production

Feature flags provide a safe method for shifting a level of testing to production, from infrastructure testing to user acceptance testing (UAT). Even the best pre-production test environment cannot perfectly mirror the dynamics of production, and pushing code straight to production in a safe, partitioned way that does not impact the rest of users allows QA teams to get a realistic view of how a feature will perform in production without worrying about creating every possible scenario in a pre-production test environment. This greatly reduces the risk of a release once all users have the feature.

Removing Risk From Migrations

Feature flags provide a low-risk alternative to the forklift upgrade of years past that often ended in fire drills. Rather than rewriting large swaths of code for a one-time migration that causes issues, developers can use feature flags to start building calls to the new service or database directly into the existing application. Then they can discreetly test out the new connection at a more secure time to see if it’s working. When it is time to completely migrate, the code will have been in production for a long time and flipping the switch will be a non-event.

Learn more about how CloudBees Feature Flags can take your software delivery to the next level