Split Up Features and Deploys
Let’s say you’re writing a web app and you have the great fortune of having someone actually use that software. Usually there’s only one of two reasons to change it, one you want to add something new to it to either get more people using it or make the existing people happier, or two, someone has complained about the thing not working right.
In the case of number two, you should release the fix for the problem as fast as possible. Branch off of master or deploy or whatever, fix it, merge it back in, push, done. The problem is when you have multiple other long running feature branches that you have to keep in sync with master which depending on your team probably changes every day if not every hour. To solve that problem, you either just deal with the inevitable merge issues or you always just commit to the same branch all the time. Of course committing changes to the same branch all the time sounds crazy, right? It is crazy if you don’t use feature flags.
Feature flags let you turn off that incomplete, long running feature and still let you send that fix out while keeping all of the code in sync. No merging issues, everyone’s database is up to date, customer’s problems are getting solved.
It’s weird that when we deploy code today we think about it as just code and nothing else. It’s actually two different things, features and fixes. There’s no reason to not recognize this and just release fixes all of the time alongside partially complete features, instead of waiting on super long running, out of date feature branches to go along with the fixes.
I’m making checkered, an open source project to help manage feature flags in your app, be sure to star it and watch for the client libraries for your favorite language, coming soon!
