e-gineering/gitflow-helper-maven-plugin

More of a question than a "issue" : managing version in pom.xml file

paulbhart opened this issue · 1 comments

Trying to make a recommendation to our team on which plugin's to use for adopting gitflow in maven.

I must admit a bit new to maven, so apologize in advance if I am getting some concepts incorrect.

As I play around with this plugin I am trying to figure what the typical steps would be do a release. In other words, I have branched development to a new release branch and am ready to build/deploy to nexus the artifact. Other plugins have a create-release and finish-release step.

I wasn't sure in using this plugin, are you expected to just use the maven-release steps of prepare/perform? or am I missing something.

First off, I don't use the maven-release-plugin. I avoid it at all costs. Consider it a personal preference, but I have yet to find a workflow that works with that plugin using an SCM that isn't CVS or SVN.

My theory is that I shouldn't have to use maven commands to work with my SCM. My build tool and my version control should be separate concerns. That line gets blurred by this plugin, insomuch as the behavior of the build tool can be aware of and advised by the state of the SCM (git) repo.

I wrote up a two-part blog on this some time back:

https://www.e-gineering.com/2016/02/02/gitflow-maven-and-ci-done-right-part-1-teaching-maven-new-tricks/

https://www.e-gineering.com/2016/02/12/gitflow-maven-and-ci-done-right-part-2-bitbucket-server-jenkins-and-nexus-oss/

Basically, when I'm doing local development, I use my favorite Git front-end to create my branches, commit, etc.

When I get to the point you're mentioning, I do the version-bumping by hand. This process typically looks something like this:

  • Cut a release branch & update the pom.xml version (either by hand, or with the versions-maven-plugin)
git checkout -b release/x.y.z
mvn versions:set -DgenerateBackupPoms=false -DnewVersion=x.y.z
git commit -am "Version Bump for release."
git push -u origin release/x.y.z

At this point, the CI server would build off my release branch, and deploy to my nexus "test-releases" repository.

  • Bump the version on the development branch.
git checkout development
mvn versions:set -DgenerateBackupPoms=false -DnewVersion=x.y.0-SNAPSHOT
git commit -am "Version Bump for next dev version"
git push

At this point, the CI server would build off my development branch, and deploy to my nexus "snapshots" repository.

I have some shell scripts I use boil this down to one command for release / development branches, but I wanted to give you the full tour above, to see that I personally value not crossing the streams when it comes to having maven update / push state to my SCM. It's my build tool. It should stay that way. I use it to manage project versions, dependencies, and to produce / promote artifacts. I don't use maven as a tool for managing my development workflow. I use maven as a tool because of my development workflow.

  • Once I'm done testing my release and finalizing my changes, (ready for a merge to master and deploy to the nexus 'releases' repository), I open a pull request from my feature branch into master. Once the merge into master happens, the CI server promotes the last test-releases artifact to releases.

From there, I normally setup a different build job to grab the artifacts from nexus (using the attach-deploy mojo of this plugin) and then deploy them to an execution environment. It's not uncommon for those builds to also run liquibase for the target environment or other tools to stage databases, etc.

The things this plugin shines at are related to getting maven to work really well with gitflow while doing full-on CI with a single build job definition, and separating deployment to an artifact repository from delivery / deployment into an execution environment.

I think there's a philosophical difference here.

Granted, you could use those other tools to handle creating branches, bumping versions, etc. This plugin isn't meant to handle that, nor should it interfere with plugins that do that. This plugin is meant to solve a different set of issues -- ones you run into when you're automating CI builds, doing deployments, and wanting to be able to track artifact provenance and not rebuild for every environment you're deploying to. I see it as a separate need / problem set from the other git plugins I've seen for Maven. Hope this helps!