git-flow: workflow for making "release candidates" / QA web artifacts
<p>We are developing several projects that consist of web artifacts, using the <code>git-flow</code> branching model.</p>

<p>Refer to: <a href="http://nvie.com/posts/a-successful-git-branching-model/" rel="noreferrer">Vincent Driessen's git flow branching model</a></p>

<p>We are using <code>develop</code> branch and <code>jenkins</code> to auto build and deploy <code>SNAPSHOT</code> web artifacts to test environment.</p>

<p>We manually run <code>git flow release start</code> and <code>git flow release finish</code> to build non-snapshot artifacts which are deployed to our artifactory and deployed eventually in prod.</p>

<p>(How to run <code>git flow xxx</code> commands? Here's a <a href="http://danielkummer.github.io/git-flow-cheatsheet/" rel="noreferrer">cheatsheet</a>)</p>

<p>My question: How should the workflow for QA work?</p>

<p><em>Given that:</em></p>

<ol>
<li>We don't want to deploy snapshots to QA</li>
<li>It's nice if the same artifact we tested in QA is deployed in PROD</li>
<li>We can use <code>git flow</code> scripts and branching model as closely as possible</li>
</ol>

<p>Looking at the branching model, my own best understanding is:</p>

<ol>
<li>Make a release branch (e.g. <code>release/1.1</code>).</li>
<li>Build artifacts from the release branch and test in <code>QA</code>.</li>
<li>Make changes in <code>release/1.1</code> branch and return to step 2 as necessary</li>
<li>When testing is complete, <code>finish</code> the release (merge into master)</li>
<li>Deploy artifact in prod.</li>
</ol>

<p>Does anyone have any experience with this, especially step <code>2</code> ? How should artifacts from the release branch be uniquely identified?</p>

<p>We are considering using a <em>release candidate</em> versioning, where maven version <code>1.1.RC1</code> indicates <code>release-candidate1</code>, following by <code>1.1.RC2</code>, and finally <code>1.1</code> (final version).</p>