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.

final release build has been created, you can merge the changes from the Release branch<br />

back into your main <strong>Development</strong> and Integration branches.<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<br />

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

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

• For additional descriptions of how to branch and merge in <strong>Visual</strong> <strong>Studio</strong> 2005, see<br />

“Branching and Merging <strong>Team</strong> <strong>Foundation</strong> Source Control” at<br />

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

How do I use branching to maintain my application?<br />

Use Maintenance branches to support previously released builds.<br />

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

moved a release to the Maintenance folder:<br />

• Main – Integration branch<br />

o Source<br />

o Other asset folders<br />

• Releases – Container for Release branches<br />

o Release 1 – Maintenance branch<br />

• Source<br />

Keep the following recommendations in mind when working <strong>with</strong> a Maintenance branch:<br />

• When to branch: After you have released, support the release <strong>with</strong> a branch in<br />

the Maintenance folder.<br />

• When not to branch: If you will never need to maintain the release, you can use<br />

a label to mark the old released build and continue work in the Main branch.<br />

• Permissions on branch:<br />

o Read/write for developers working on hotfixes.<br />

o Read-only for everyone else.<br />

• Build frequency on branch: On-demand builds.<br />

• Testing focus on branch: Sign off on release.<br />

You should use Maintenance branches to support an older version of your application.<br />

You might choose to merge these changes into your main Integration branch, or leave the<br />

changes specific to the Maintenance branch.<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

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

Saved successfully!

Ooh no, something went wrong!