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

git maven branch git-flow branching-strategy
vikingsteve picture vikingsteve · Aug 12, 2016 · Viewed 7.4k times · Source

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

Noremac picture Noremac · Feb 15, 2017

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.

Related questions

'react-scripts' is not recognized as an internal or external command

I've got a maven project, within which is JavaScript project cloned as a git sub-module. So the directory structure looks something like mavenapp/src/main/javascript/[npm project files] inside my package.json, the test looks like this : "test": "react-scripts …

Read More
Importing a Maven project into Eclipse from Git

How can I get the effect of choosing to import from both Maven and Git and have Eclipse properly generate my project? To get my project into Eclipse I can choose File->import->maven and then I get …

Read More
"Git fatal: ref HEAD is not a symbolic ref" while using maven release plugin

I get the following error output while running the Maven release plugin prepare step i.e. mvn release:prepare --batch-mode -DreleaseVersion=1.1.2 -DdevelopmentVersion=1.2.0-SNAPSHOT -Dtag=v1.1.2 -X from an Atlassian Bamboo plan. However doing the same in the command line works …

Read More