7

My group at work has been trying to come up with a good process that we can use with TFS. I'm just wondering if some of you guys had some successful strategies with using TFS across multiple sites using multiple branches.

One specific issue that we have is probably our release engine. On the simple side, a developer should be able to check in his/her changes into the DEV Branch, and then ok certain date (say a freeze date) the DEV Branch will be "reverse integrated" into the Main Trunk (QA) in which then the changes will be pushed to the Production branch. The issue arose when a user check into the DEV Branch, but he doesn't want those changes to be moved into QA (because maybe other portion of the code is not done yet) ... any thoughts on that?

|improve this question
2

I've been using it for about 4 years on a couple different teams. What I've found to work best for our group is managing branches by release/iteration. So all changes for the iteration are made on a development branch and when all of those are ready to go to QA then we merge.

This does become a little bit of a problem if you have something on the branch that isn't really ready to merge but then you can choose not to merge those change sets. That gets messy if the code that you aren't including changes some key piece or something but that has been rare in my experience. What we have done is manage the iterations so that everything really is complete by the end. If there is a piece that is risky you can do a branch off your DEV branch just for that so that you can manage it seperately.

I would keep to as few branches as possible so that you don't spend to much time merging.

|improve this answer
  • hmm, interesting i think this idea was somewhat brought up. Do you have multiple release branch available? (say the current release and the next release?) – aggietech Oct 15 '10 at 13:09
  • 1
    Sometimes yes. If we are in testing for a new release but want to make a change to what is currently in production we can do that. You can create a branch based on a changeset number so you don't have to plan for this up front, you can do it as needed. – Beth Whitezel Oct 15 '10 at 16:23
  • 6 year old advise... I added a new answer for what we do now. This one is still valid depending on your process. – Beth Whitezel Apr 13 '16 at 2:57
2

My old answer on this question works. But since that time our process has improved significantly and we have incorporated automated deployments so now I would say....

We now have two week iterations but deploy new functionality as fast as we get changes made, reviewed, and tested instead of waiting for everything in the iteration. To facilitate this we reorganized to a main branch (trunk) and then a development branch off of the main. Any change passing review is merged to main and deployments happen semi-automatically off of main. This strategy has really worked well for us, there are very few times where merges are difficult because we get changes moved up to main in smaller chunks.

|improve this answer
2

MS issued a white paper that covers one approach with detail on why.

http://tfsbranchingguideiii.codeplex.com/ (this is the 2008/2010 version, there is also a 2005 version).

That link is now outdated, and the advice has been updated. Please see https://blogs.msdn.microsoft.com/visualstudioalmrangers/2016/07/18/the-new-branching-guidance-for-team-foundation-server-team-services-and-others/

|improve this answer

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.