Maven and git-flow, version strategy for release candidates

Question

We are trying to apply the git-flow model to maven projects.

We use the develop and feature/XXX branches to work on -SNAPSHOT versioned artifacts, that are deployed in our DEV and TST environments.

When the apps are "ready", we have "Release candidates" : the code is pushed on the release branch, we edit the pom to update the version (replace the -SNAPSHOT by -RC1), this version is built and stored in the repository manager, and then deployed on our UAT env.

If some fixes are needed, we create others -RCx versions in the same release branch, these artifacts are archived in the repository manager, and deployed on the UAT env. So we can precisely track the bug fix in the different versions.

Once a -RCx version is approved, the release branch is pushed to master, the pom updated to remove the -RCx, built, and stored in the repository manager before being deployed in PROD env.

But with this way of doing things, the binaries that are deployed in PROD and in UAT are not strictly the same : the POMs are different in the 2 WARs, because of the <version> tag. And it is not really a good practice.

If I correctly understood the git-flow model, the "final" version number (without a -RCx) should be set at the creation of the release branch, and the same version is "alive" until this branch is pushed to the master, right ? In this case:

• We lose the information of what version of the application is really deployed in UAT (as we lost the -RCx identifier, we may not know if the deployed version contains the last bugfixes or if it is an older version that is deployed...)
• In the repository manager, we cannot know if an artifact has been built from the release branch or from the master, as there is no change of the version number anymore when pushing the feature branch into master.

What is better ? What are the pros/cons of these 2 ways of doing ? (Not the same binaries on the different envs -vs- not having well-identified release candidates.)

How do you (or would you) manage Release Candidates with a Maven project in the git-flow model ?

Answer 1

I recommend adding a revision number to your versioning strategy. The revision number gets set to 0 when you start the release branch, then it is incremented with every fix. When testing completes, then deploy the exact version that verified testing to production. This approach gives traceability for every version, keeps the versions consistent across environments, and avoids the need for a new build that is just formalization around the version number. The exact same binaries that are verified in your test environment can be deployed to production.

I've used this strategy for several production applications and have not had any issues.