Databases
StackOverflow2013
Postsdbo
POHg workflow with two different release cycles
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POHg workflow with two different release cycles
    primarykey
    data
    text
    <p>We're about to change our workflow for our release management as part of our upgrade from a CVCS (TFS) to DVCS (Hg). Some things have been discussed pretty intense here at office and I would be glad to get some input about it.</p> <p><strong>Some background</strong></p> <p>We're a small/midsized software company (approx. 25 developers) with a long lived product. We try to keep our release cycles low - a release after each sprint (~once a month). In TFS we create a branch for each new release. The two last releases supports bug fixes.</p> <p><em>Our current branch model (TFS)</em></p> <pre><code>--trunk --release200 //and older, not supported anymore --release201 --release202 </code></pre> <p>On top of these branches we have different developer branches (if needed). Some team branches and some feature branches.</p> <p>"Small" bugs are corrected on release202 and merged to trunk. Critical bugs are corrected on release201 and merged to release 202 and trunk.</p> <p>What we don't support is bug fixes on older releases.</p> <p><strong>New workflow</strong></p> <p>Some customers don't care that much about new features, instead they want a more stable version. Therefore we are thinking about offering two tracks - one long lived release with patches, another with more frequent updates of features. We've been thinking about having branches like this...</p> <p>(Hg)</p> <pre><code>--default --RC --Release --StableRelease200 --StableRelease210 </code></pre> <p>These are all named branches inside a central Hg repository. Each of these branches is connected to a CI machine. From a developer perspective, there will be develop branches (hg clones) outside the scope of this question.</p> <p>Some customers will use releases from Release, some from StableReleaseX.</p> <p><strong>Default:</strong> All new development of features is merged into this branch.</p> <p><strong>RC:</strong> When a PBI is done/end of a sprint, default is merged into this branch for internal testing. Bugs found in this branch is also corrected here. When QA thinks it's stable enough, this branch is merged into Release. If some developers need continue to work on new features, they can do it on Default.</p> <p><strong>Release:</strong> Releases here happens sequentially, only the last one will support bug fixes. From a technical perspective, releases are marked with Hg Tags. Critical bugs found at customer site during a sprint will be fixed here and merged back to default.</p> <p><strong>StableReleases:</strong> Every half year or so (decided by management), Release is merged to a new StableRelease branch. During its life time, no new features will be added here. Bugs found here will be fixed here and merged back all the way to default. Probably two StableReleases will be supported at the same time - the current one and the second last. Older branches will be closed.</p> <p><strong>Some questions</strong></p> <ul> <li>General opinions about the workflow? Do you have any experience in supporting two different, concurrent "release tracks"? One with frequent releases and one with long lived releases with bug fixes only?</li> <li>We’ve been thinking having the branches as named branches to make it easier for the developer (one VS, one pull etc). Or... do you think it will be harder? Easier to have seperate clones instead (most of the developers have limited experience using a DVCS)?</li> </ul>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USRoger
    1. USRoger
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POHg workflow with two different release cycles
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

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