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:
git flow
scripts and branching model as closely as possibleLooking at the branching model, my own best understanding is:
release/1.1
).QA
.release/1.1
branch and return to step 2 as necessaryfinish
the release (merge into master)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).
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:
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With