3

I try to understand the right approach for managing hotfixes with TFS /source-control.

Say I have a small project to contains only two file (app.js and util.js). Both files are under source control (Team Foundation Server).

Assuming I applied two weeks ago a label that indicates the "milestone-1" that was deployed to the server. Since then I applied several other modifications (extended app.js and added another files).

Today I found a bug so I get the version with the label "milestone-1" from the server, modify the util.js and deploy this version to the server. The goal is that on the server only the version "milestone-1" including the hotfix-1 is deployed but not the modification I applied the last two weeks.

The question is: How /where do I check-in the hotfix to the TFS? Because I might find another bug tomorrow so I have to get the version "milestone-1" and the hotfix-1 base base for appling the second hotfix.

Is there a way to check-in a version of my code into the TFS that "sits" between label "milestone-1" and my latest version?

thuld
  • 680
  • 3
  • 10
  • 29

2 Answers2

4

With branching and merging!

We have the following development cycle:

  1. The initial project is created, permissions assigned, and imported in to TFS under branch name of "Main".
  2. Because this is the initial iteration of development, we branch "Dev" from main, and that's where the developers work. Note at this point there is no official release.
  3. When development is complete, it is merged back in to Main. No Dev work happens on the Main branch.
  4. We branch "Release" from main, and that is the point at which the code is actually deployed, and version numbers are updated.

Ok, so, further down the line, we have to make some amendments. Once again, "Main" is branched out again and the development work continues down the Dev Branch. All is well. Then a user reports a bug that needs fixing, and it needs fixing fast. But we're half-way through our other development!! What to do?

At this point, we branch from main again. We'll call it "HotFix". The bug is fixed, and then HotFix is merged back in to main. We can then merge it in to our release branch, and the update is sent out. Our current dev work is not interrupted, and none of the work we have been doing up to this point exists on Main).

We finally finish our dev work, and we merge that back in to the main branch, and then in to release. Because our Hotfix branch got merged in to main, our new development work also contains the hotfix we did on the fly earlier.

Moo-Juice
  • 38,257
  • 10
  • 78
  • 128
  • Thank you for your input. I have a few questions regarding your dev-cycle: When you say "...version numbers are updated" you mean you apply a label to the entire solution? Do I understand this right, each release is a dedicated branch from "main"? I think I understood the benefit of you approach: The dev-branch is once merged to the main branch, this might be release 1, you then create another dev-branch where the developer apply the modifications for 2. Once a hotfix is required we branch "main" (which is release-1) and apply the changes required for 1.1. – thuld Dec 03 '13 at 19:52
  • why aren't changes related to the hotfix merged into the dev-branch (before the dev-branch gets merged into main at the end of the development cycle) ? – Bill Anton Sep 28 '16 at 14:25
1

You should use branching. Check out the "Rangers'" guidance.

I have successfully used the Advanced Branch Plan in the past, but you can customize it to your needs. You need to be disciplined with branching, merging, checking in, etc. Also consider shelvesets for code changes that aren't ready to be committed even to the DEV branch.

http://vsarbranchingguide.codeplex.com/

Let me know if you want more information.

Lou
  • 317
  • 1
  • 4