Branching strategy in DevOps

#1

I am setting up DevOps process with TFS and wondering about branching strategy. If I have the following sample branching (image from Guidance: A Branching strategy for Scrum Teams | DevOps.

I have Devops process set up (continuous integration and continuous delivery) with continuous integration from MAIN branch (with Jenkins).

How would I handle hotfixes? If developers merge frequently into MAIN branch to verify builds, how do I get the last released code for applying a hot fix? If I were to use Release branches, I would eventually have to integrate hot fix into MAIN branch in order to kick off CI process. However, MAIN branch could contain changes beyond the release.

Please advise on this issue.

#2

Obviously, the answer that you choose depends on your particular requirements; however, typically, you should cut a release from main, and a hot fix from the release branch. Personally, I would say that that code should not go back into the release branch, but be double fixed in a development branch.

The main reason for this is that, once you’ve released code, that code branch should be locked as it was at release. If you follow this, then you can always go back to a previous state of affairs. This can be explained in DevOps Training. As has already been suggested, you may be halfway through changes to a hotfix when the requirement or priorities change; or when the customer reports a bug in the live code. If you maintain a separate branch, you can always access that code.

#3

It’s suggested making all your branches synchronized all the time. When you want to handle hotfixes, you can create a new branch “HotFix” from main. When the hotfixes are completed, you need to merge it from HotFix to Main, and merge from Main to Release.

If you have made any changes in the release you will need to merge back up to Main in order to finalise the changes.

1 Like