We all know the situation: the customer finds a critical bug in the latest release and he wants us to release a new version of our application with a fix. How do we handle this situation without breaking our team policies? How to release a specific fix to avoid regression problems?
First we need to fix that bug with the classical approach of feature-branches. We create a branch, fix the bug, create a pull-request and the team approves. These activities are set at the highest priority because a customer is in trouble and we must help.
Now we are in a situation where we have a specific commit that solves a specific problem with only the necessary lines of code modified.
Our target is to ship that specific commit that fixes that specific bug with a standard pull-request, without all the other work done in the development branch since the latest release. So we write down (in our clipboard for example) the id of the commit.
What can we do now to release?
1. New branch
We create a new branch.
git checkout -b my-hotifx
Now we fetch the latest updates from the remote repo.
git fetch origin
Then we set our branch my-hotfix to point to the latest commit of the remote release branch.
git reset --hard origin/release
Now we cherry-pick the specific commit we want to apply to the release branch without commiting (–no-commit option). We choose the no-commit option to carefully inspect what is going on in our files. It’s here where we use the commit id we saved early.
git cherry-pick <commit-hash> --no-commit
We verify that everything is fine (where fine depends on your specific project). Now we can commit and push to VSTS.
git add . git commit -m "Hotfix" git push origin mybranch:mybranch
3. Open pull-request
Our branch is now on the remote repo and we can open the pull-request with VSTS.
From here the team can approve the PR and fire up our automated release process that activates our automated test and if everything is fine we deploy safely.
With this blog post we explored the critical situation to release a hotfix without breaking the rules or taking shortcuts to avoid our release pipeline. As engineers we must maintain a cold approach even in hot situation and rely on our best practices. Human errors are always possible in particular when we’re stressed and a customer is making our phones hot.