StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>I'm in the process of re-designing our workflow for release. So I've found this question. I've decided to wrote my experience. For what it's worth ...</p> <hr> <p>For development, we are using something that seems to be variation of what you call the <em>stable/default</em> workflow (of course everything goes through commands that enforce the workflow, I call them <code>myw</code> thereafter) :</p> <ul> <li>we have a central server which holds all of our repositories</li> <li>we have a central <em>stable</em> clone per project on this server</li> <li>we have a central <em>dev</em> clone per project which is a clone of <em>stable</em> on this server</li> <li>initially, one can <code>myw create theproject</code> which create the <em>stable/dev</em> clones for theproject on the server and that locally (on the developer computer)</li> <li>when someone has to develop a new feature he can <code>myw clone theproject dev mygreatfeature</code> that : <ul> <li>clones the project <em>dev</em> repo on the server as <em>mygreatfeature</em></li> <li>clones locally the cloned repo <em>mygreatfeature</em></li> <li>makes lot of useful things like updating hgserver / hudson ci ...</li> </ul></li> <li>he can <code>myw fetch dev</code> and <code>myw fetch stable</code> anytime</li> <li>when the feature is done he merges it back to his local dev clone, push the merged result on the central <em>dev</em> clone and close the central clone which is archived for a while : <code>myw close theproject mygreatfeature</code></li> </ul> <p>All of that works great and is pretty smooth. We have preferred clones to named branches as it was simple to really close a feature branch, and at the time the mercurial "named branch" part seemed like "work in progress".</p> <hr> <p>The release part of the workflow is presently done basically like that :</p> <ul> <li>the "release master" fetches from the central <em>dev</em> clone to his local <em>dev</em> clone.</li> <li>he fetches from the central <em>stable</em> clone to his local <em>stable</em> clone.</li> <li>he fetch from his local <em>stable</em> clone the changes that are in his local <em>dev</em> clone.</li> <li>he checks everything, if it is ok, do <code>myw release 1.2.3_RC2</code> that : <ul> <li>tag with 1.2.3_RC2</li> <li>push to the centralized project stable clone. </li> <li>this is in fact a <em>release candidate</em>, that will be tested for a while by our CI server and by our hardcore testers.</li> </ul></li> <li>Bug fixes discovered by those tests are fixed on the local <em>stable</em> clone and pushed on the centralized <em>stable</em> clone.</li> <li>when its ok, the "release master" do a formal release : <code>myw release 1.2.3</code></li> </ul> <p>That works pretty well, even if we needs to improve some commands to smooth the process. One of the main drawback it's that's a lot of clones :)</p> <p>For the management of old releases, we have currently a clone of <em>stable</em> done for each major release. As there is no big need to backport many features, we just have to cherry-pick some really bad bugs with <code>hg transplant</code> (great extension by the way).</p> <hr> <p>We have used that for about a year, and we certainly need to improve our homemade commands, especially for the release part :) </p> <p>The main drawback is that you have to give you/your team some tools to handle it because without them it could be unmanageable, hence our <code>myw</code> homemade set of commands. As usual, the feature branch should not last for too long, or merging can be hard to do. Things like refactoring/renaming has to be done at chosen points, or it will give your team a lot of merging work.</p> <p>As we are going to have more and more versions to maintain, I'm trying to improve the 'old release but have to support' management part. Reading <em>Bert F</em> comment, I've read this great <a href="https://bitbucket.org/yinwm/hgflow/wiki/Home" rel="noreferrer">article</a>. There is good ideas and it is well explained with a really good scheme ! It seems someone has implemented the hg version of his tool git-flow as <a href="https://bitbucket.org/yinwm/hgflow/wiki/Home" rel="noreferrer">hg-flow</a>. Something to consider. I like the release and hotfixes branches. And I think that enforcing such workflow with a tool is pretty well mandatory !</p> <p>my2c</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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