Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I think <a href="http://blogs.msdn.com/b/billheys/archive/2011/01/14/parallel-feature-teams-working-on-multiple-releases-in-development-monthly-releases-to-production.aspx" rel="nofollow">branching by feature</a> (or by team) would be better than branching by developer. The feature can be tested and previewed before merging through Development (Trunk) and into Staging branch.</p> <p>My team has had a similar "Branch by Quality/Environment" structure that I spent some months researching how to best convert so developers worked together and we could reduce the merge tax. I'd suggest the following:</p> <ul> <li>Development (Trunk / Main / Root branch) <ul> <li>(FeatureName1[Version]) - replaces branch for each Developer.</li> <li>Staging (if you are keeping all releases in a single branch)</li> <li>Production</li> <li>(ReleaseName)(MajorVersion)Staging - My preference to isolate different releases even if released to same environments</li> <li>(ReleaseName)(Version)Production</li> </ul></li> </ul> <p>Staging fixes are made directly in the Staging branch (or short-lived child branch of Staging if QA and/or risk mandate isolation), then merged fix back to Development (Trunk) as soon as fix is accepted. <strong>CAUTION:</strong> Pay close attention to any merges from Development while a Staging fix is in progress.</p> <p>From QA Perspective I strongly prefer the final staged-and-tested build be the identical binaries/files released to production. The only change should be configuration files (with different configuration settings checked in to a repository). This means I typically make final build in "Staging" and the "Production" or ReleaseVersion branch is a read-only archive that nobody builds. (A label or tag may be used instead of this safekeeping branch if said lable is immutable... which is not the case for TFS 2010 :-(.)</p> <p>See the cool diagrams in <a href="http://msdn.microsoft.com/en-us/magazine/gg598921.aspx" rel="nofollow">Visual Studio TFS Branching and Merging Guidance </a> MSDN article from Feb 2011. To scale this out see <a href="http://blogs.msdn.com/b/billheys/archive/2011/01/18/branching-for-scrum.aspx" rel="nofollow">Branching for Scrum</a> and <a href="http://blogs.msdn.com/b/billheys/archive/2011/01/14/parallel-feature-teams-working-on-multiple-releases-in-development-monthly-releases-to-production.aspx" rel="nofollow">Parallel Feature Teams working on multiple releases in development. Monthly releases to production.</a>. Both of these come with some excellent diagrams that apply to any version control system.</p> <p>I'd also suggest looking at the <a href="http://tfsbranchingguideiii.codeplex.com" rel="nofollow">TFS Branching Guide</a> and the discussions forum in this same location for additional good patterns and guidance. (Branching methodology is largely independent of tooling with exception when avoiding tool weaknesses.)</p> <p>I see at least one fundamental flaw in the original branching process:</p> <blockquote> <p>After internal sign off, the changes are then merged to staging. If changes need to be made, they will most often be made in trunk, and then merged to staging.</p> </blockquote> <p>If a change to Staging is made in Development and then merged to Staging again then you've just inherited all other changes made to Development branch since last merge to Staging. OR if you cherry-pick the change (leaving all other changes to be merged later). SCM tools are getting better at handling this scenario, but cherry-pick merges still introduces significant risks.</p> <p>FYI: The pattern originally described is similar to "Branch By Quality" as described by Jeff Levinson. It can work, but you have to look carefully at how to manage hotfix/qfe branching and merging changes back to Trunk.</p>
    singulars
    1. This table or related slice is empty.
    1. POA better way to handle branching and merging?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USZephan Schroeder
    1. USZephan Schroeder
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POA better way to handle branching and merging?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COthank you very much for your thoughtful and thorough answer. I will have a look at the resources you suggested.
      singulars
      1. PO
      1. USToby Hemmerling
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload