I was recently working on a feature over a few mob programming sessions.
After the session, we implemented part of the feature but couldn't merge it as it wasn't complete.
After working on other things that day, I'd need to rebase my local commits and push the last-but-one commit to the remote repository to keep the incomplete feature only in my local repository (I forgot a few times and almost pushed it accidentally).
The commit prevented me from following continuous integration - where everyone commits and pushes their code a minimum of once daily.
What if someone else wanted to look at that code between mob sessions? They couldn't, as it was only on my laptop.
If I'd made a temporary branch, it would be outdated and behind other changes to our mainline branch.
Feature flags to the rescue
As this commit was part of a larger change, it couldn't be merged, so we added a feature flag around it.
The values were set to null and hidden by default, and populated by the new changes and displayed if the flag was enabled.
Here's the thing
This meant we could safely push the commit, make the changes available to everyone and enable the feature on the environments we wanted - preventing it from showing on production.
This allowed us to get back to our usual working practices, and I didn't need to worry about accidentally pushing the commit and prematurely showing our changes in production.
- Oliver
Was this interesting?
About me
I'm an Acquia-certified Drupal Triple Expert with 17 years of experience, an open-source software maintainer and Drupal core contributor, public speaker, live streamer, and host of the Beyond Blocks podcast.