- Workflow Source: https://dzone.com/articles/why-i-never-use-maven-release
- git flow tutorial: https://www.youtube.com/watch?v=BYrt6luynCI
TL;DR
git flow release start 6.0.0
git checkout release/6.0.0
mvn versions:set -DnewVersion=6.0.0
git flow release finish 6.0.0
git push origin --all --follow-tags
Now, if you break down the release plugin into sensible steps, you’ll really save yourself a whole lot of trouble. I use these steps to release something. As a sidenote: I use git and git-flow standards (as described here). Assume the POM’s version’s currently on 1.0-SNAPSHOT.
Announce the release process Very important. As I said, you don’t release on a whim. Make sure everyone on your team knows a release is pending and has all their stuff pushed to the development branch that needs to be included.
Branch the development branch into a release branch. Following git-flow rules, I make a release branch 1.0.
Update the POM version of the development branch. Update the version to the next release version. For example mvn versions:set -DnewVersion=2.0-SNAPSHOT. Commit and push. Now you can put resources developing towards the next release version.
Update the POM version of the release branch. Update the version to the standard CR version. For example mvn versions:set -DnewVersion=1.0.CR-SNAPSHOT. Commit and push.
Run tests on the release branch. Run all the tests. If one or more fail, fix them first.
Create a candidate release from the release branch.
Use the Maven version plugin to update your POM’s versions. For example mvn versions:set -DnewVersion=1.0.CR1. Commit and push.
Make a tag on git.
Use the Maven version plugin to update your POM’s versions back to the standard CR version. For example mvn versions:set -DnewVersion=1.0.CR-SNAPSHOT.
Commit and push.
Checkout the new tag.
Do a deployment build (mvn clean deploy). Since you’ve just run your tests and fixed any failing ones, this shouldn’t fail.
Put deployment on QA environment.
Iterate until QA gives a green light on the candidate release.
Fix bugs. Fix bugs reported on the CR releases on the release branch. Merge into development branch on regular intervals (or even better, continuous). Run tests continuously, making bug reports on failures and fixing them as you go.
Create a candidate release.
Use the Maven version plugin to update your POM’s versions. For example mvn versions:set -DnewVersion=1.0.CRx. Commit and push.
Make a tag on git.
Use the Maven version plugin to update your POM’s versions back to the standard CR version. For example mvn versions:set -DnewVersion=1.0.CR-SNAPSHOT.
Commit and push.
Checkout the new tag.
Do a deployment build (mvn clean deploy). Since you’ve run your tests continuously, this shouldn’t fail.
Put deployment on QA environment.
Once QA has signed off on the release, create a final release.
Check whether there are no new commits since the last release tag (if there are, slap developers as they have done stuff that wasn’t needed or asked for).
Use the Maven version plugin to update your POM’s versions. For example mvn versions:set -DnewVersion=1.0. Commit and push.
Tag the release branch.
Merge into the master branch.
Checkout the master branch.
Do a deployment build (mvn clean deploy).
Start production release and deployment process (in most companies, not a small feat). This can involve building the site and doing other stuff, some not even Maven related.