2

We're reviewing the popular Gitflow as our git branching model and I've liked it so far. One case I'm not sure about is the production rollback. Say we've there's a new feature that we're planning to publish in the upcoming release. The feature is tested and finally merged to master. Either automatically or manually the source code in the master is built and deployed. Shortly after deploying we reveal a critical bug and immediately create a hotfix branch. All right, so far so good. But we roll back the production version to the most recent working one. That means the program that's running in production does not match the source in the master branch. And anyone who branches off from master will something different that's really working. How do you cope with this case?

  • 1
    coup should be cope in the body of the question as well (don't have permission to make that small of an edit...) – geocodezip Feb 17 at 11:03
  • How many people would want to branch off from top of master? Can't you just tell them that it contains a bug severe enough that production was rolled back to the previous release and that the team is working on fixing the problem? – Bart van Ingen Schenau Feb 17 at 11:27
4

Shortly after deploying we reveal a critical bug and immediately create a hotfix branch. All right, so far so good. But we roll back the production version to the most recent working one.

There's some misunderstanding. If you apply a hotfix, it will increase the version. For example if the feature was merged and tagged version 1.4, then you apply a hotfix, you also increase the version.

That new version may be 1.4.1 or 1.4.0.1. At the same time you also merge the hotfix into your develop branch. Hence, master both changes are in master and in develop now.

Then you deploy your new version w/o the feature.

That means the program that's running in production does not match the source in the master branch. And anyone who branches off from master will something different that's really working. How do you coup with this case?

You don't roll back anything, you just deploy the fixed 1.4.1 (or 1.4.0.1 if you want to reserve the build version to planed maintenance) version with the feature removed.

| improve this answer | |
  • By rollback I mean the binary. Let's say we compile the source in master branch and deploy it to production. Shortly after it, we discover a critical but and we immediately remove the new binary and replace it with the previous one. But this time master is not in sync with the production binary. Hotfix might take a while. – Mikayil Abdullayev Feb 17 at 10:47
  • I just remembered about git revert command. In this case, I might issue git revert which will reestablish the previous state of the source code and then I can apply the hotfix patch whenever it's ready. – Mikayil Abdullayev Feb 17 at 10:49
  • Yea, you don't do binary rollbacks. You remove the feature in code, then deploy it without the broken feature. The deployed binaries will have a new version number, because of the hotfix. Also it helps when you forbid fast-forward merges when merging features into develop branch, this makes it easier to revert the changes from a specific commit – Tseng Feb 17 at 10:54
  • 1
    The important aspect is that the version of the binary matches the version of the master. But even in the unlike case you do binary rollback, i.e. to 1.3.6 binary, then you still have that one in source since every merge into master should be tagged with a version. There's no rule that master's head has to point to production binaries, just that its tagged to a specific version – Tseng Feb 17 at 10:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.