Can Feature Flags replace Hotfixes in Devops?

Question

When using a git strategy similar to gitflow, can feature flags totally replace the Hotfix Release branch process?

When seeing bugs in production, we first make the change in the develop branch and test it. Then, we also merge fixes into the release branch or create a hotfix branch. Merges and cherrypicking are prone to errors, or people forgetting to place in code properly.

We have a release branch since some modules are not ready and we don't want them showing in production.

We are thinking of trying feature flags to replace the release and hotfix branches, allowing us to deploy daily. Leaving us with only a develop and master branch. Would this strategy make sense?

Answer 1

Feature flags can't fully replace a hotfix process.

You probably won't be putting every single change behind a feature flag. That would greatly increase the complexity of the code as well as the management of the state of all of those flags. In addition, some changes can't easily be put behind feature flags, such as dependency updates and infrastructure changes. You need to balance the complexity of the code, the performance impacts of checking for feature flag status, and the benefit of using and managing the flag.

In some cases, though, feature flags can reduce the need for hotfix branches. Techniques such as feature flags, canary releases, and dark launching can help if you find yourself frequently hotfixing. Dark launching can help find potential performance issues in backend API calls before you display the results of those calls to users in the UI, especially if you have robust monitoring set up on the application and infrastructure. Canary releases roll out changes slowly so that if there is a problem, it affects a small subset of users. You can couple both with feature flags, especially of a more dynamic type that doesn't require a redeployment, to be able to disable functionality quickly if your monitoring or canary users report problems. By turning off the functionality, you ensure that your system is stable and you can take your time with a fix.

I'm sure that canary releases, dark launching, and feature flags are three of the enablers behind deploying many times in a day. Netflix has a microservice architecture, so deploying new services or very small backward-compatible changes to existing services at an API level can also promote rapid deployments. Generally, though, they probably aren't cherry-picking code but rather focusing on moving forward and frequently deploying a branch that passes automated testing