Let’s define “deployment” as “code moving to where it’s going to run one day.” And then we can define “release” as “code becomes available to users.”
In days of yore, these were the same event. You pushed code, and then it was available to users.
Feature flags let you decouple these two events. You can deploy code but hold off on releasing it. Or you can release it to a subset of your users.
Mechanically, a feature flag amounts to something like this:
if flag_enabled
do_something
else
do_something_else
end
Which means they’re not without complexity. That introduces branching into your code. Each branch should be tested, for example.
But, you’re able to “ship” code without it being presented to customers. This helps with continuous integration (CI), the practice by which you continuously integrate development work with the mainline daily at the least frequently. CI has unfortunately come to mean “automated tests running on some server, but that’s for another time.
One thing that holds people back from practicing CI is not wanting to push code that isn’t ready for production. I’d first like to have a conversation about how big your work items are because if those are taking longer than a day most of the time, you have a batch size problem.
But, suppose you’re completing features but just not ready to release them, put them behind a flag! Don’t let that code sit around drifting away from your other development efforts.
Batching up integration work is, um, not fun.
