Maven release via Hudson

问题:

I'm setting up Hudson to use the batch-task plugin to do maven releases to our internal repository. I'm doing it via:

mvn --batch-mode release:prepare
mvn --batch-mode release:perform

I'm interested in other methods people have used and the pros and cons of those methods. Also, any gotchas people have come across.

回答1:

I have tended to do the releases always by hand for a few reasons. First if you have to roll back it's easier when you can go back to the original release location and do it. Secondly because you need to resolve all snapshot dependencies as part of the process.

Our development process has us leaving dependencies external to the current build at the previous release version until a fix requires an upgrade. This means that if I'm releasing Nexus, Maven, etc, then I see snapshots and it means I have to go off and release those first. This process isn't really possible to automate since it varies based on what's changed since the last release.

That said, we have a special machine (at Sonatype it's just a vm) setup only for builds. This is done to guarantee no environmental changes occur that could influence a build accidentally (like a jdk change). It also makes it easier for anyone to pick up the release process because it's always ready to go.

回答2:

Recently, a m2release plugin came to my attention. Seemed nice. Althought, I would have liked my release process to be completely «pom-tweaking-free». What I mean by that is that we have to provide 4 input parameter to process a complete release:

1. the release version (ex. 1.0.0)
2. the new development version (ex. 1.0.1-SNAPSHOT)
3. the release tag in SCM (ex. release-1.0.0 or 1.0.0)
4. the tag base path in SCM

The first 2 have acceptable defaults. The version bumping at the bug-fix version digit is perfectly fine for me.

Number 4 can be specified in the pom. It won't change.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-release-plugin</artifactId>
    <configuration>
        <tagBase>https://example.com/svn/myProject/releases</tagBase>
    </configuration>
</plugin>

It's the third one that prevent me from a complete automation of a release at the push of a button. The default release tag label won't do it for us so we have to specify it:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-release-plugin</artifactId>
    <configuration>
        <tag>release-${pom.version}</tag>
        <tagBase>https://example.com/svn/myProject/releases</tagBase>
    </configuration>
</plugin>

Now, while this might be just what I needed, I end up having a svn tag with the -SNAPSHOT at the end. :( So I have to pass the tag parameter in the Hudson job configuration. Furthermore, I have to go change it for each release we make ... which is not exactly what I need.

---

So, in the end, having a maven2 type project in hudson + the m2release hudson plugin + the maven release plugin correctly configured is the Mother of all the release process I've seen so far. While not perfect, it saved me a lot tiedous work.

JS.

回答3:

I've always triggered a release manually with obvious pros and cons :-)

回答4:

We've been experimenting with the Hudson Maven release plugin, though I'm a bit challenged with getting it to properly credit the releases, without evil things like hardcoding passwords into our build files.