git-flow: workflow for making "release candidates" / QA web artifacts

Question

We are developing several projects that consist of web artifacts, using the git-flow branching model.

Refer to: Vincent Driessen's git flow branching model

We are using develop branch and jenkins to auto build and deploy SNAPSHOT web artifacts to test environment.

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

(How to run git flow xxx commands? Here's a cheatsheet)

My question: How should the workflow for QA work?

Given that:

1. We don't want to deploy snapshots to QA
2. It's nice if the same artifact we tested in QA is deployed in PROD
3. We can use git flow scripts and branching model as closely as possible

Looking at the branching model, my own best understanding is:

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

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

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

Answer 1

Great question, we want to do the same thing. Here's what we came up with. Similar to @crea1, a new qualifier is added (a patch number). This can now be a separately released artifact from the release branch.

In practice, it isn't much different than what you proposed:

1. List item
2. Create the release branch
3. Release version 1.0.0, QA tests with this version
4. Make some bug fixes, do a maven release 1.0.1 from the release branch (the .1 being the extra qualifier)
5. Finish the release when ready, version is something like 1.0.4
6. Deploy to prod

We have a number of internal dependencies that may change due to testing. This proved to be an effective approach for those. For the application itself, it's not as important for it to be a release, but would be nice to not have to rebuild after QA is finished. This can be applied to that as well.

The key is having an extra throw away number in the versions when releasing. I suggest not doing something like RC1. Even though it makes it much more descriptive, I will then feel the need to re-release/build the RC if it's the final version so that RC isn't in the final version. I want to be able to take the same artifact that was tested directly into prod and at the same time not have "RC" versions in my pom for the prod release.

This is something that in my opinion should be included in the gitflow model, a release candidate option.

Answer 2

I think it makes sense to use a qualifier, as maven will always consider a version with a qualifier 1.1.RC-1 older than a version without a qualifier 1.1.

Note that the SNAPSHOT qualifier is special, so maven (and probably Artifactory) treats it different than other qualifiers. Maven treats it as a incremental build, while other qualifers are not. This means you might have to set a new version for each commit in your release branch if you don't want to use the SNAPSHOT qualifier.

Answer 3

I faced the same issue and extended Vincent Driessen's git flow branching model to include branches which represent the environments TEST, QA and PRD.

Instead of letting MASTER contain the last code in production , I choose to let MASTER by default point to the last version in QA. Then deploying to PRD is just a promotion of a release candidate already on QA to PRD.

You can now do hotfixes on the version on QA, which will probably occur more then doing hotfixes for the production version. Doing a hotfix for production is still possible by resetting the master branch to the version on production you want to fix.

Answer 4

Yes, using an indicator in the tag is a standard practice, see here