Visual Studio Team Foundation Server Branching and Merging Guide

New Post: Basic plan confusion about number of release branches and dev branches?

davidkallen — Fri, 10 May 2013 01:43:05 GMT

There is a way to reparent an existing branch to an integration branch, but to do what you are asking is very tricky. The built-in reparent feature is not intended for this scenario. You may not like this solution much. If you fear this scenario, then make your integration branch at the beginning.

So I tried an experiment. You can experiment too. Here is what I did:

I Created Dev1, Dev2, Dev3 off of Main.

Then I "decided" to create an integration branch off of Main.

I then created Dev1new and Dev3new off of Main.

I then checked out Dev1, Dev3, Dev1new, Dev3new.

I then copied the old Dev1 folder over Dev1new.

I then copied the old Dev3 folder over Dev3new.

I then checked in the Dev1new and Dev3new.

I then undid checkout on Dev1 and Dev3.

I then deleted Dev1 and Dev3 as I no longer needed them.

In summary,

I created the new branching structure I desired.

I checked out every project involved in the reorganization (both old and new

Using windows explorer, I then copied the old project files over the new ones.

I verified it all worked.

I checked in the new projects (that are now off the Integration branch).

I undid checkout on the old projects as they were the source and did not get altered. The only reason I checked them out in the first place was to remove the read-only locks on them so that when they were dropped over checked out files, they would be in the same state as the files they replaced.

As you can see, this is possible. I figured did the whole demo in 15. But it is not pretty. It is so complex that there is a risk you will make a mistake. You can also use baseless merges instead, but I am unfamiliar with them in practice and cannot give any advice on their value.

And lets keep this in perspective. You would do all this just to reduce the risk that your Dev1 and Dev3 teams would not step on each other when they merge their changes in the common code module? The safer thing is to have a single sub-team responsible for changing the common sub-module on behalf of both other teams. Or, you could leave Dev1, Dev2, and Dev3 branches as they are. Then, the first one(let's assume the Dev1 team) who checks in their tested code has it easy. The second team (Dev2) is responsible for getting the latest version, merging from Main to Dev2, then ensuring all tests pass before checking it in.

If the separate projects are so different or mutually dependent on one another that they really NEED an integration branch, this should be obvious from the very beginning. And thus, you can design an integration branch from the start.

Sorry for the complicated answer. But branching cannot magically solve all problems of development. All the pieces are interrelated - the branching approach, the environments available, the way the teams are organized, the way the work is organized, the nature of the changes made, etc...

New Post: Rolling Release as a component of a Periodic Release

petescott — Thu, 09 May 2013 14:37:53 GMT

First, I'd like to thank you for the excellent documentation. It's proved invaluable lately.

We're responsible for deploying a web application that contains customizations (via a single compiled DLL). That is, many of our customers have very unique business rules which they cannot change, but which we do not wish to directly support in our product due to the added complexity and/or the limited marketability.

Our web application is released about every two months (periodic release), but these customizations are developed, tested, deployed, fixed, tested again, redeployed (etc) as often as ten in one day.

The branch structure we're using is (somewhat simplified):
/Main
-/Source
--/BusinessObjectLayer
--/WebApplication
--/Customizations

We're currently using the standard branching plan in this fashion:
Feature Dev (opt) <- Dev <- Main -> Release
(we will likely add the Service Pack strategy soon)

Each of those branches is a branch of the Main/Source, so each branch contains its own copy of the Customizations project. That means Release1 has its own copy of Customizations, Release2 has its own copy, &c.

This structure is causing some issues.

One issue is that, if a customer is on Release1 and discovers an issue with their customization code, developers are modifying that code IN THE RELEASE1 BRANCH. This isn't a huge deal, since we're a small team and they're responsible enough to not modify anything outside of that project, but I feel that it is only a matter of time before somebody slips up. Note that the Customizations project does NOT undergo QA.

Another issue is the merging problems. If a developer adds a new class file (customizations for our clients are stored in a unique namespace, classes separate the customizable bits by feature) to Release1, that results in a change to Customizations.csproj in that release. If another developer adds a new class file to the Customizations project in Release2, we now have multiple .csproj edits... often further confounded by some of the developers leaving the .csproj checked out for too long. When merging these changes (RI to main, then FI to latest release) Visual Studio often wants to delete items that shouldn't be deleted (I'm not at all sure what the root cause of that is). I think that disabling shared checkout on .csproj might alleviate much of this issue.

Finally, we occasionally make edits (signature changes, etc) to the Customizations project and related objects in the other areas. That essentially ties the Customizations to a minimum version of the entire solution (I'm not certain that makes sense, please let me know if additional clarification is needed). This is not a problem currently (since each branch contains its own copy of the Customizations project), but will be important to consider when suggesting different approaches.

Any thoughts on structuring this differently? Or could this be handled more easily with a bit of developer training and TFS configuration?

[edited for spelling/grammar typos]

New Post: Basic plan confusion about number of release branches and dev branches?

tandars — Thu, 09 May 2013 14:31:41 GMT

Ah, it's all starting to make a lot of sense.

So if I have 3 DEV branches, and initially, I thought they would be independent from each other, but as development progresses, I notice that DEV 1 and DEV 3 both had to heavily modify a common part of the code base, and I hadn't anticipated it, is it possible in TFS to create the integration branch afterwards? Or is it really something that I need to anticipate from the get go to be able to use?

Thank you again.

New Post: Basic plan confusion about number of release branches and dev branches?

davidkallen — Thu, 09 May 2013 02:39:55 GMT

1. Yes, the technique to "Branch by feature" can be added on to any of the plans.

2. It sounds like you understand. But there are some tricky spots. It is not merely the presence of multiple dev branches that motivates the use of an integration branch. It is the fact that they must each have their code integrated and tested before you have confidence they are stable. So if you have multiple dev branches but they are completely independent of one another, then there is not need to merge them to an integration branch first. By definition, the risk is low that one will break the other.

I'm not sure an integration branch makes much sense between Main and Release branches. Technically, you can do it. But release branches are used for a different purpose than development branches.

David

New Post: Basic plan confusion about number of release branches and dev branches?

tandars — Wed, 08 May 2013 16:47:39 GMT

Hi,

I read over the Basic Plan again, and I understand it a lot better now. I still have two more questions.

1) Is the Branch by Feature Plan an add-on to the Basic, Standard and Advance plan? It sounds like so too me. Since the basic plan says:

Work in DEV branches can be isolated by feature, organization, or temporary collaboration.

I see this as if you isolate your DEV branches by feature, that is, you create a dev branch for each feature, you are adding the Branch by Feature plan to the basic one, no?

2) From what I understand about the Integration line pattern, it should be used whenever you are going to be RI more than one branch back into Main. So in the case of the Basic plan where I would have more than one DEV branch, I should use the Integration Line pattern right? That means I should branch main into Integration, and Branch Integration into all of my DEV branches, am I still right?

Similarly, if I have many Release Branches, I should have an Integration branch from Main to Integration to All my Release branches?

Thank you very much for taking the time to answer me. I love this project, it is helping me a lot.

New Post: Basic plan confusion about number of release branches and dev branches?

davidkallen — Wed, 08 May 2013 00:19:17 GMT

My comments are based on the Friday, August 24, 2012 version of the Branching and Merging Guide.

I recommend you re-read page 40. Most of your questions are answered there. I pasted the first part below so you can see that it answers most of your questions. Notice that it describes several variants such as :one development area vs multiple development branches; or one release branch (reused) vs one per release. After you re-read this a couple of times. If you still have questions, let us know.

From Page 40
Basic Branch Plan
The basic branch plan with a main, dev, and release branch enables concurrent development for your next release, a stable MAIN branch for testing and a release branch for any ship blocking bug fixes.
Multiple development areas are supported by creating additional development branches from MAIN. These are peers to each other and children of MAIN.
Additional releases are supported by creating additional release branches for each product release. Each release branch is a child of MAIN and a peer to each other (e.g. release 2.0 branch is peer to release 3.0 and both are children of MAIN). If supporting only a single release in production at a time, you may consider a single release branch, and make bug fixes directly on this branch as depicted in the diagram below.
Once the release branch is created MAIN and the development branches can start taking changes approved for the next product release. An even simpler version of this plan for smaller teams might only include a MAIN and RELEASE branch. Consider this if the isolation required only required two branches such as for smaller teams and projects.

New Post: Basic plan confusion about number of release branches and dev branches?

tandars — Tue, 07 May 2013 19:45:54 GMT

I just read through the Guide, and I'm a bit confused about the Basic plan and the role of the integration branch.

Tell me if I understood it correctly:

You have a Main branch that will always contain the latest stable changes from everywhere. So initially, you have a Main branch that you branch out into a Dev branch. At that point, you're development of features happen in the Dev branch until it reaches a stable point, at which point you RI into the Main branch. You keep doing that until you have the features that match release 1. Once it does, you branch the Main, which will contain the stable latest features, into a Release 1 branch.

At that moment, you can continue developing new features in the dev branch, while stabilizing the Release 1 branch, until you feel it is ready to be delivered. All fixes made to the Release 1 branch must be RI into the Main branch, and FI from the Main branch into the Dev branch. Since Release 1 has been stabilized, you change it to read-only, and package your Release 1 from the Release 1 branch. This is your first deliverable.

All the meanwhile, work is being done in the Dev branch, and being RI into the Main branch every time new stable features are made. Similarly, once enough new stable features are RI into the Main branch to meet your Release 2 feature set, you branch out Main into a Release 2 branch, where it will be stabilized, and then made read-only once delivered to the clients.

Here I get a bit confused.

First, the basic plan talk about having 3 branch, Dev, Main and Release, yet it seems to me like basic will have a Dev, a Main and as many release branch as you have releases, am I correct to believe that here?

Second, what if 2 weeks later, we find more bugs inside Release 1. Where do I fix those bugs? Is that asking too much for Basic, to be able to fix bug in an already released branch? Is this where I am supposed to have a Service 1 branch which branches out into a locked Release 1 branch. This way, I can keep maintaining Service 1 branch, and I can keep releasing those fixes with new locked branches from Service 1 into Release 1.1, Release 1.2, etc. ? Or I'm wrong about having one release branch per release in Basic, and it's that the release branch actually never becomes read-only, we just keep fixing bugs over it. And once Release 2 comes out, instead of being branched form Main into Release 2, it's FI from Main into the Release branch?

This is my first confusion.

My second confusion is with the Dev branch and is kind of similar. Do I have only 1 dev branch? What if we are developing one risky feature, while also adding in small and frequent but not as risky features. Do we do it all on the Dev branch given the Basic plan? Or do we branch the Dev branch into a Feature 1 branch, where we can work on our big feature, while using the Dev branch for the smaller feature development. In this case, would the Dev branch be like our Integration branch?

Which lead to my last confusion. Is the Dev branch the Integration branch? If it says we should use an integration branch to integrate on, so that Main remains stable and functional, is that branch our Dev branch? If not, is my Dev supposed to be a child of the integration branch, and the integration branch a child of Main? Or are both the Integration and Dev branch a child of Main? Where does the Integration branch lies in the Basic plan?

I know this is a lot of questions at once, but I feel they all somewhat relates.

Thank you.

New Post: Code Promotion Branch Plan Limitations?

mlhoop — Tue, 30 Apr 2013 16:18:09 GMT

As with most things branching... "it depends"... and there are options. You could make the hotfix to the prod branch and get it out the door, then move it back to Test and Main (if they needed it). You could cut a branch from prod to address the specific "fixes". You have many paths. In general if this is happening all the time (every release) you might introduce a fixes branch from the beginning or choose a different model.

New Post: Code Promotion Branch Plan Limitations?

bdeem — Tue, 30 Apr 2013 16:13:44 GMT

I suppose I can answer my own question.

Looking at "Branching and Merging Guidance - Strategies" it's clear the it does not support a hot fix.

New Post: Code Promotion Branch Plan Limitations?

bdeem — Tue, 30 Apr 2013 16:10:32 GMT

I've been looking at the Code Promotion Branch Plan and I'm not clear as to how to apply a hot fix to a production release.

Main -> Test -> Prod

For example, if we are working on vNext in Main and QA we cannot apply the fix to those branches. If we apply the fix to the Production branch then are we forced to RI into QA and Main? What if we don't want to RI the change? We just entered another problem as we changed Prod branch directly without proper testing. I suppose we could use Shevesets, but that feels like a cruch.

What's the best way to implement this scenario or would hot fixes not be supported?

New Post: Making sure fixes don't get lost from one release to another

Bebo — Fri, 05 Apr 2013 21:56:08 GMT

We have found that we "lost" a fix from one release to another. I need help in determining the best thing to do to help make sure this doesn't happen again.

Picture the "Advanced Branch Plan" scenario. Over time we have released a major version 1 with all the servicing branches under it. Later we release another major version 2 after development is complete. Version 2 gets brought through Main and has its own servicing branches created below it. This happens again with version 3.

So...I have 3 major versions all with servicing branches beneath and each version is still getting serviced.

A fix goes into version 1. It needs to get to version 2 and then version 3.

The only way I see to get that change where it needs to go is to RI it all the way to Main, then cherry-pick it down into the servicing branches for version 2. I have to cherry-pick because version 3 has already moved through Main and I don't want to pick up any of that new development.

Question: how can I make sure that all fixes that have been serviced in version 1 after version 3 was released have been Reverse Integrated and then cherry-picked down to subsequent versions?

Is this a good way to do it? Is there a better solution?

Thank you!

New Post: Branch to share assemblies and other blobs between team projects?

mlhoop — Thu, 21 Mar 2013 19:45:13 GMT

Hey all,

This is a huge topic area, take a look at the guide for pros/cons. However also take a look at NuGet and NuGet package restore as a potential solution for dependency management which can in fact get you away from putting binaries in the tree to begin with.

New Post: Branch to share assemblies and other blobs between team projects?

aalasaad — Wed, 20 Mar 2013 17:58:49 GMT

Hi John,

Take a look at the "Advanced Version Control Guide" document. There is a section titled "Dependency Management Patterns". It goes through different scenarios of sharing source code, binaries, and 3rd party libraries.

Branching vs Not branching comes down to how often the libraries and blob assets change. If they don't change that often, you may just want to create a folder for each version and reference or update them when needed. You need to create a dedicated team project for you shared assets.

Let me know if you need more info.

Cheers,
Ahmed

New Post: Branch to share assemblies and other blobs between team projects?

johnmcalvert — Tue, 19 Mar 2013 19:22:55 GMT

Is branching a good or even the best way to share assemblies, libraries and other blob assets between different team projects?

I don't recall seeing this use case covered in the ranger guide.

There is an option that is not super well documented:

Immediately convert source folder to branch (enabled visualizations)

It is the default but I'm not sure if it is relevant for blob assets.

New Post: Branching Strategy - (dev, qa, uat, stage) to Branch Per Release

mreynolds0925 — Thu, 07 Mar 2013 14:24:18 GMT

Hi Bill-

I do love the simplicity of the strategy but i have a couple of questions I'm hoping you can help me with.

After you deploy from DEV to QA or UAT, where do you start working on your next round of DEV changes? Because, what if there are necessary changes to the UAT code? Since there is no UAT branch, where would you do the changes so that they don't get jumbled with the next round of DEV? Same goes for changes to RELEASE for emergency bug fixes but I assume that in this case you manually write the changes into RELEASE and into DEV.

We have a single release web site for our customers. We do QA/UAT before releasing updates. We do separate DEV while code is in QA/UAT. My plan may involve a service branch but we may just do fixes in the RELEASE branch.

A little bit of guidance here would be a huge help and much appreciated.

New Post: Feature Branch plan and Automated Builds

Spivonious — Thu, 28 Feb 2013 13:35:21 GMT

Yes, we'll need to figure out what "stable" means for us. I'm leaning towards "feature completed and ready for testing". We'd just need to be careful to only merge the changeset from the feature branch into the release branch.

Thanks for the input, everyone.

New Post: Feature Branch plan and Automated Builds

wschaub — Wed, 27 Feb 2013 21:05:38 GMT

It depends what your quality bar is for the main branch. If, as in most cases, it contains the latest stable "version of the truth" you need at worst a gated check-in build, or separate the main and feature branches with an integration branch which has a build, or define a build per branch. Personally I prefer to keep main in a known and stable state, defining builds per dev and/or feature branch.

New Post: Feature Branch plan and Automated Builds

Spivonious — Wed, 27 Feb 2013 19:43:18 GMT

I'm starting to think that having a build definition on a feature branch isn't worth anything. Test builds can happen from Main, and another branch can be added to handle releases. Main builds to test on check-in and Release builds to prod on check-in. Devs can setup build definitions to Dev if they want to, but it wouldn't be required. If we find that we really need that build to Dev, we could always add another branch in between Main and the features.

Anything I'm missing?

New Post: Feature Branch plan and Automated Builds

Spivonious — Wed, 27 Feb 2013 14:06:12 GMT

I was hoping to not have to make two new build definitions for each branch, as these branches can and will be very temporary (sometimes only lasting a few days).

Ideally ,our workflow would go like this:

dev team 1 makes a new branch from main and begins work on their feature.
dev team 2 makes a new branch from main and begins work on their feature.
dev team 2 finishes and is ready for testing. They build their branch to a test environment.
dev team 2 testing passes, changes checked into main, main is built to production.
dev team 1 merges main into their branch to get dev team 2's changes.
dev team 1 ready for testing, build their branch to test enviroment.
dev team 1 testing passes, changes checked into main, main is built to production.

I would absolutely love to have a build definition that both dev team 1 and dev team 2 could use to put their branch into a test environment. Something where the teams could choose the solution to build (from source control, not locally) at the time the build is queued. Is this possible without developing a custom add-in?

Oh, and our entire department is six devs, one designer, and two report writers. We have a couple of large projects that routinely have independent changes going on concurrently.

New Post: Feature Branch plan and Automated Builds

davidkallen — Wed, 27 Feb 2013 03:15:21 GMT

I'm confused. Spivonious, how many people are on your team? And what do you mean by "currently open solution?"