Stress and cherry pick free hot fix deployments

Git is an amazing tool, incredibly flexible and extremely capable. It’s a shame that Linus Torvalds will be remembered mainly by Linux, because in fact git is probably a much more used tool than Linux itself.

Regardless of that, git flexibility also imply that sometimes we can over complicate things, and one of the scariest things is the releasing process and the scariest of all scenarios: the hotfix.

Well, fear no more, I have a better solution for you for those hotfix releases.

The recommendation from git itself is normally to do a cherry pick. However, and in my experience, that results in uncountable headaches and problems with conflicts and what noes, and scare the most senior of the developer, not to even mention to hand this over to a less experienced member just when the senior is on holidays (hey, security releases, I’m looking at you).

A better approach? Well, something native to git itself and closer to the way we are used to work daily: branches.

The approach we’ve been taking since a few projects is to create a release branch, say release-v1.0. Once that branch is created, then you can create a tag from that branch. The advantage? Huge. Whenever you need to do a hotfix, you won’t need to over complicate with cherry picking or what else, you simply open in your preferred tool a PR against the release branch, and simply create another release from that branch.

That approach allows you to continue working on develop, keep a version of your prod safe in that release branch, and if the worst happens, you can simply open a PR against it, cut a new release tag, and the release to prod (of course testing first in stage).

I’ll work on some graphs to make this process more clear… if there is any interest on this :-)

What do you think about this approach? Feel free to leave your opinions.