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.

Additional Resources<br />

• For more information, see “Chapter 8 – Setting Up a Continuous Integration Build<br />

<strong>with</strong> <strong>Team</strong> Build” in this guide.<br />

Use Branching to Reduce Build Breaks<br />

To help avoid build breaks, you should use a <strong>Development</strong> branch for active<br />

development and a Main branch for your integration build.<br />

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

created a <strong>Development</strong> branch:<br />

• <strong>Development</strong> – <strong>Development</strong> Branch<br />

o Source<br />

• Main – Integration Branch<br />

o Source<br />

o Other Assets folders<br />

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

• When to branch. If you are creating daily builds and are having problems <strong>with</strong> build<br />

stabilization and integration, you should create both a main and a development branch<br />

to ensure greater predictability of your daily builds. You may also want to consider<br />

more stringent check-in policies to improve check-in quality.<br />

• When not to branch. If you are only creating CI builds, or your daily builds are<br />

already predictably stable, you might not need the extra overhead of an integration<br />

branch.<br />

• Permissions on branch:<br />

o The Main branch permissions should be read/write for developers responsible<br />

for merging and integration, but read-only for everyone else.<br />

o The Dev branch permissions should be read/write for everyone.<br />

• Build frequency in branch:<br />

o Daily builds on the Main branch.<br />

o CI builds on the Dev branch.<br />

• Testing focus on branch:<br />

o Perform integration, performance, and security testing on the Main branch.<br />

o Perform feature and quick feedback testing on the Dev branch.<br />

Use the Main branch as a staging area for integrating changes that have been checked<br />

into the development branch. Perform all active development in the Dev branch, and<br />

integrate non-breaking changes into the Main branch.<br />

Additional Resources<br />

• For more information on defining a branching and merging strategy, see “Chapter 5 –<br />

Defining Your Branching and Merging Strategy” in this guide.<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!