12

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?

varesa
  • 223
  • 2
  • 4

2 Answers2

3

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.

RonU
  • 548
  • 2
  • 6
1

Rethink your approach.

It is very common to use e.g. 1.4.2 for a release version and then 1.4.3-SNAPSHOT for the development to the next.

When you need to maintain release 1.4.2 THEN branch it from the commit that originated your 1.4.2 artifact.

Then you tell Jenkins the location of your repository and the branch name, resulting in a file set being checked out, and then you tell Jenkins to use maven on your project to build it.

Note: I've found that it is very beneficial to use a single pom.xml to build the actual artifact and another pom.xml to create the actual bits to go to the customer.