CODEWITHSUNDEEP
tfsdevops
sakura-bloom
sakura-bloom

Reputation: 4594

Branching strategy in DevOps

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).

Branching diagram

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

Please advise on this issue.

Upvotes: 2

Views: 3232

Answers (6)

P.Zarzycki
P.Zarzycki

Reputation: 1

How to handle this really depends on the release and maintenance strategy or customer agreements you have.

If your release branch happens also to be a maintenance codeline (it seems like it from your description) then create feature branch from it, implement a hot-fix, test, merge back and release a "patch". Ideally you should have CI set also for the "maintenance" branch. After this you can integrate your hot-fix with main codeline or put the issue on backlog to implement it differently for the future new release.

BTW: Some nice articles here: https://www.cmcrossroads.com/article/agile-perspective-branching-and-merging and http://www.bradapp.com/acme/branching/branch-creation.html

Upvotes: 0

B.T Anand
B.T Anand

Reputation: 617

If you are using Agile, then feature branches can be a good option. The only thing is it has to be combined with a ticketing tool like JIRA or AGM. For handling hotfixes in such scenarios, you can have a user story in AGM or JIRA, which upon completion will be merged onto the mainline trunk.

Upvotes: -1

Mickey Hovel
Mickey Hovel

Reputation: 1070

Generally a hot fix should gets out from the relevant version on the main branch. Then need to create a dedicated branch for the hot fix, merge it with the last stable branch. If it passes the entire QA, unit tests, system tests, etc then merge it back to main branch as the next released version.

you can have a look in the following example when using git the reference is here: git best practice. The source control is not the issue but the main idea. Read carefully the article i believe you'll be able to find what you are looking for.

There are some organization that still working with patches... I'm not a big fun of this solution, but if this is your case than let me know, because in patches there is a little bit different solution.

Upvotes: 4

Paul Michaels
Paul Michaels

Reputation: 16705

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. 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.

Upvotes: 1

Jim Roth
Jim Roth

Reputation: 397

A hotfix is a patch to released software. If you've got a release branch, creating a hotfix branch off of that is appropriate. After that hotfix is promoted up to Prod, you can then reverse integrate back up the chain to Main. Hotfix -> Release -> Main, and even forward integrate that up to the next sprint, if needed.

Upvotes: 1

Cece Dong - MSFT
Cece Dong - MSFT

Reputation: 31093

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.

Upvotes: 1

Related Questions