Git, Maven, Jenkins – Workflow for Versioning and Builds

gitJenkinsmavenversioningworkflows

What is the preferred way to do the following with git, maven and jenkins:

I am developping an application, which I would like to maintain "dev" and "release" branches. I would like jenkins to build both. It could be so that the release-artifacts would have versions like 1.5.2 and the dev-builds would just be 0.0.1-SNAPSHOTs. I would like to not have to have 2 different pom.xml files.

I looked into profiles, but they don't seem to be able to change artifact versions. One way I looked at could be adding a 'qualifier' to the test-builds. Of course I could just rename the file, because the real artifact-information on this is not important, because the app is a standalone one.

What would be the preferred way to doing this? Or how would you do this?

Best Answer

I would imagine there should be an inherent relationship between these branches that ought to address the problem of version numbers.

Releasing

I would envision you might do something like merge production-ready code from the dev branch to the release branch, then perform a Maven release (via Jenkins or manually). This automatically rolls the version numbers to the next build. So you merge code 1.4.7-SNAPSHOT to this branch, perform the release and cut version 1.4.7, and Maven automatically rolls your working copy to 1.4.8-SNAPSHOT.

Updating Baseline (optional)

If you're not already using your trunk (or baseline branch, etc) as a place for your releases, you should be updating the trunk as soon as you complete a release. This means your version numbers are getting updated as well. This step might be moot if you just consider the release branch to be the baseline.

Up-merge from Baseline to Dev Branch

It's essential that your development branch stay up to date with the actual production code. You need to merge the code from the baseline (or release branch, depending on implementation) up to your development branch. This is important in your case because it means the pom changes that occurred during the release process, which changed the version to 1.4.8-SNAPSHOT, are brought to this branch.

Based on reading I've done (as well as processes with in my organization), this seems to be a pretty standard and effective use of Maven releases and snapshots, and rather than maintaining completely disconnected version numbers on different branches, it's easy to tell that any 1.4.7-SNAPSHOT build was in fact an immediate predecessor of the 1.4.7 release. They're related. I would go so far as to say if you're not merging back and forth between these branches, you're doing both SCM and Maven versioning wrong, and you're putting yourself at risk for developing against code that doesn't match production, re-introduces bugs to production, etc.

Related Solutions

Is it a good practice to capture build artifacts in Artifactory that Jenkins produces

ArtifactoryPro has features for doing what you're asking, so why the heck not? JFrog's documentation even has an example: see http://wiki.jfrog.org/confluence/display/RTF/Build+Integration

Java – Best Way to Structure a Git Repository for Maven

You have 2 options:

by git way: use submodules. Here is a documentation how git manage submodules [git submodules][1]. I personally didn't use it but it looks to fit your problem.
by maven way: in maven it is not mandatory that your root project (configuration) to be hierarchically the parent directory of all your projects. You can have a structure like that:

configuration
 +-- pom.xml (configuration:XXX)
project1
 +-- pom.xml (project1:1.0-SNAPSHOT)
 !
 +-- module11 
 !     +-- pom.xml (1.0-SNAPSHOT)
 +-- module12
       +-- pom.xml (1.0-SNAPSHOT)
project2
 +-- pom.xml (project2:2.0-SNAPSHOT)
 !
 +-- module21 
 !     +-- pom.xml (2.0-SNAPSHOT)
 +-- module22
       +-- pom.xml (2.0-SNAPSHOT)

configuration, project1 and project2 are on the same directory level and each one could be a git repository. When build project1 or project2 you run the maven command from project1 or project2 level and maven will try to fetch the parent (configuration) from maven repository not from parent directory. You should pay attention to versions. I would recommend in project1 or project2 to keep a reference to a parent (configuration) with a release version.

To make a release you have to do it in 2 steps: release configuration first and release project second. Project1 and project2 can evolve independently and doesn't have to have the same configuration version as a parent.

Just for special cases when you want to have both configuration and projects as SNAPSHOT versions, in project1 or project2 you can use the <relativePath> tag inside <parent> tag to point to your local path of configuration. I don't recommend this because will create problems on development environment (at least for me in Eclipse)

I apologize for my English. [1]: http://git-scm.com/book/en/Git-Tools-Submodules