CODEWITHSUNDEEP
tfsbranching-and-mergingteam-project
Joshy
Joshy

Reputation: 657

TFS Branching Strategy where a release is delayed and development continues.

I have a moral delema, within my company we have our entire product suite in the main branch and projects will branch off the main (trunk) branch. I have a problem in that a sprint (there long 8 weeks) that is to be delivered has been delayed and can not be deployed for 2 weeks but development needs to continue on to the next sprint.

The problem is that if there is bug that needs to be fixed on sprint 1 and development continues on the existing branch the bug fix and parts of the sprint 2 then will be mixed together making it very hard to release sprint 1.

On the other hand if we create a new branch from the existing branch we loose all the tasks and bugs and what not.

Is there a way for code branches to share one team project or is that silly?

How would you handle this situation? Is there something that I am missing?

Upvotes: 0

Views: 346

Answers (1)

Betty
Betty

Reputation: 9189

If you're branching to a new Team Project every sprint then you're doing it wrong. All branches for one product should live in the same Team Project.

Sprints should align with the iterations, not Team Projects, that way you can freely reassign any work item from one sprint to another without an issue.

If the bugs are critical, then fix them in the sprint 1 branch and merge them into sprint 2. That way you can release them without the sprint 2 code. No matter whether this is part of your initial sprint 1 release or one in the future.

If the bugs aren't critical then you can fix it in the sprint 2 branch and release sprint 1 with the bug.

There's no reason that sprints and branches need to line up 1-to-1, if you only do releases every 3 sprints then you could easily get away with only branching every 3 sprints too. Heck if you're good at release management and know exactly what changeset was released you can even branch weeks after the release if you need to modify the result of the sprint.

If you want to take continuous deployment really seriously then you'd need to start looking at having a trunk branch and feature branches, features only get merged back into the trunk when they're complete. You might have several feature branches per sprint. Or look into feature toggles meaning you can deploy new code, but have it turned off so users don't notice anything.

Upvotes: 1

Related Questions