This blog has moved to Medium

Subscribe via email


«
»

How to do a production hotfix

4/8/12, 12:48
1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading ... Loading ...

Situation
It’s Thursday/Friday evening, the daily version / master branch was deemed too risky to install, and you decide to wait for Sunday/Monday with the deploy to production.

There’s a new critical bug found in production.
We do not want to install the bug on top of all the other changes, because of the risk factor.

What do we do?
Develop the fix on top of the production branch, in our local machine, git push, and deploy the fix, without all the other changes.

How can I do this?

My example uses a Play Framework service, but that’s immaterial.

  1. gitk –all – review the situation
  2. Suppose the latest version deployed in prod is 1.2.3, and master has some commits after that.
  3. You checkout this version:

    git checkout 1.2.3

  4. Create a new branch for this hotfix.

    git checkout -b 1.2.3_hotfix1

  5. Fix the bug locally, and commit.
  6. Test it locally.
  7. git push
  8. On the production machine:
    1. git fetch (not pull!)
    2. sudo service play stop
    3. git checkout 1.2.3_hotfix1
    4. sudo service play start
  9. Test on production
  10. Merge the fix back to master:
    1. git checkout master
    2. git merge 1.2.3_hotfix1
    3. git push
  11. Clean up the local branch:

    git branch -d 1.2.3_hotfix1

    (Note: the branch will still be saved on origin, you’re not losing any information by deleting it locally)

Tags: ,

4 Comments

  1. Ken Egozi:

    That’s how I’ve been doing this for year 🙂

    the best part – gitk –all this is the most useful tool in the history of SCM

    I miss this stuff really badly when I work with other SCMs.

    And shame on me for not getting Delver on git when I had the chance.

    4/8/12, 20:23

  2. ripper234:

    Yeah, they still haven’t switched … they’re trying to with git-svn, but at some point you just have to cut the cord.

    5/8/12, 0:40

  3. Avish:

    When you guys are done condescending over us poor folk over at Delver, you might want to notice there’s nothing git-specific about this scenario and you can do exactly the same with SVN or any other SCM that supports branching out of arbitrary commits and merging. Git definitely rules, but here it just makes things slightly smoother, not qualitatively different.

    15/8/12, 20:40

  4. ripper234:

    @Avish – I didn’t say this was git specific.
    It’s cool, you’ll get there when you’ll get there, sorry if my reply sounded condescending.

    15/8/12, 22:19