Separating releases from deployments with feature flags
In a typical feature release process, a feature is released when you merge the code and push it to production.
If a bug is found after the release, the code needs to be reverted (and any conflicts or issues dealt with) and deployed again.
Also, features can only be merged once they are complete, which may take hours, days or weeks, depending on the size of the feature.
These are some reasons I like to use feature flags (aka feature toggles) and separate the code deployment from releasing the feature. The code is deployed as before, but the feature isn't released, and the code isn't executed until a feature flag is enabled.
If there is a bug, the feature flag can be disabled, and the feature is turned off until a fix can be pushed - without needing another code deployment.
If my feature is incomplete, if it's feature flagged, I can commit and deploy it without users seeing it or affecting the running application, resulting in smaller and more manageable commits and deployments.
If you wanted, you could enable a feature flag for a subset or a certain subsection of your users - allowing them to test it before making it available to everyone.
Another way I use feature flags is within a multi-site Drupal application to enable a different feature set per site and allow me to keep one version of the code for all sites to keep this easy to manage and maintain.
- Oliver
P.S. Are you still using Drupal 7 and don’t know what’s involved to upgrade to Drupal 10? Book a Drupal 7 upgrade consultation call or an upgrade roadmap.
