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 themaster
, as there is no change of the version number anymore when pushing thefeature
branch intomaster
.
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 ?
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.