git-flow: workflow for making “release candidates” / QA web artifacts
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?
- We don’t want to deploy snapshots to QA
- It’s nice if the same artifact we tested in QA is deployed in PROD
- We can use
git flowscripts and branching model as closely as possible
Looking at the branching model, my own best understanding is:
- Make a release branch (e.g.
- Build artifacts from the release branch and test in
- Make changes in
release/1.1branch and return to step 2 as necessary
- When testing is complete,
finishthe release (merge into master)
- 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
release-candidate1, following by
1.1.RC2, and finally
1.1 (final version).
3 Solutions collect form web for “git-flow: workflow for making “release candidates” / QA web artifacts”
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
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
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.
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:
- List item
- Create the release branch
- Release version 1.0.0, QA tests with this version
- Make some bug fixes, do a maven release 1.0.1 from the release branch (the .1 being the extra qualifier)
- Finish the release when ready, version is something like 1.0.4
- 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.