26.04.2015 Views

Team Development with Visual Studio Team Foundation Server

Team Development with Visual Studio Team Foundation Server

Team Development with Visual Studio Team Foundation Server

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

You should use a label-naming convention that makes it easy to locate the build later and<br />

know what it represents. Use labels that are clear about what they represent. For example,<br />

use a convention such as “AlphaBuild_20070112” composed of “LabelName_Date”.<br />

When you release a build to a customer for whom you will need to provide maintenance,<br />

use a branch instead of a label to isolate future maintenance work on the release. You can<br />

subsequently merge the branch, <strong>with</strong> any fixes it might contain, back into to your main<br />

source tree.<br />

To locate an existing label, on the File menu, point to Source Control, Label and then<br />

click Find Label. Once you have found the label, you can modify it or delete it from<br />

<strong>with</strong>in the Find Label dialog box.<br />

Additional Resources<br />

• For more information, see “Working <strong>with</strong> labels” at http://msdn2.microsoft.com/enus/library/ms181439(VS.80).aspx<br />

• For more information about labels, see “How to: Apply Labels” at<br />

http://msdn2.microsoft.com/en-us/library/ms181440(VS.80).aspx<br />

Use Branches to Isolate Supported Releases<br />

Create a branch containing the source code used to generate a supported release build.<br />

This allows you to apply fixes and updates to the supported release version of your<br />

software <strong>with</strong>out impacting the continued development of your source code base, which<br />

continues along the main branch.<br />

You continue to develop the next version of your application along your main branch in<br />

parallel <strong>with</strong> the supported release branch. You can merge any stabilization changes you<br />

made to the supported release branch into the main branch prior to releasing the next<br />

version of your product.<br />

The following is an example of what your branch structure might look like after you have<br />

created a Maintenance branch used to support released versions of your software:<br />

• Main – Integration Branch<br />

o Source<br />

o Other Asset Folders<br />

• Releases – Container for maintenance branches<br />

o Release 1 – Maintenance Branch<br />

• Source<br />

Additional Resources<br />

• For an introduction to branching and merging, see “Branching and Merging Primer”<br />

at http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx<br />

• For more information about branching, see “How to: Branch Files and Folders” at<br />

http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!