当前位置: 动力学知识库 > 问答 > 编程问答 >

svn - Maven release process issues (Any alternative to release plugin)

问题描述:

I am working with Maven for the last 2 months. I think I understand it just enough but not yet sure :) I got the Snapshot build compiled, installed and deployed to our team repository.

So the plan is the use Snapshot builds for Dev environments and Once stable tell the QA team to use that for QA and once QA accepts the build, promote the same build to production.

My requirement if a snapshot build is found to be good. I want the exact bits on production.

If I use the release plugin the issue it tags and rebuilds the sources and checks out the tag and deploys it (Removing SNAPSHOT from version string in the process). The problem here is that I cannot guarantee that it has the same bits as the Snapshot build that QA accepted.

Also, I feel it is redundant to tag the build because Jar manifest has the SVN revision. So I can always go back to that SVN revision to retrace the build from a Maven artifact Jar.

So my question, Is there a easy way to promote a snapshot build which is found to be acceptable to QA team as is ?

网友答案:

You can't have 'the same bits' if you use snapshots. You can have bits built from exactly the same source. Use the build-number-plugin to capture the source control revision into the build. WHen QA likes it, tag that rev and make a branch. Then manually set the version number to the desired release version.

Or, stop hitting yourself in the foot with a brick and use the release plugin as intended.

You need to use release staging. Run the release plugin to produce a real release, with a tag, but with the artifacts jailed in a staging area (via Nexus Pro, the next release of Archiva, or the use of altDeploymentUrl). Have QA test the staging area version. if they bless it, promote those bits to the formal release area. If QA dings it, delete the tag and delete the staging area.

Thus you accomplish testing the very bits that you imagine shipping.

网友答案:

I'm researching this issue too. I'm a hard-core Maven user, and I still bang my head against the wall with the release plugin (especially when used with Mercurial).

Here are some additional, relevant links I've run into:

  • Why I Never user the Maven release plugin
  • Maven Releases on Steroids: Adios Release Plugin!
  • Get rid of your tedious and error-prone release process

That last one still relies on maven-release-plugin, but at least it goes into more depth on the pitfalls of using it.

We're thinking of moving to a simpler approach using our own scripts to manage the process, using Maven to update the version numbers (e.g. mvn versions:set -DnewVersion=1.1.0) but implement our own branching/tagging/committing workflow.

网友答案:
  1. You can open a branche just after sending your snapshot to QA.
  2. Lock the main branche/trunk that was sent to QA.
  3. If accepted use the release plugin on the accepted branche/trunk.
  4. Upgrade the pom on the main to next SNAPSHOT and merge with openned branch if anything was added on it.
网友答案:

One approach is to let the CI server together with your binary repository. The you can skip the maven-release-plugin completely.

Here is an example of how it is being performed using TeamCity Artifactory Plugin - Release Management.

I am sure that the same possibilites are there if you use another CI server like Jenkins and also together with another binary repository like Nexus.

网友答案:

There's a brilliant blog here describing a fairly simple alternative to using the maven release plugin. We will be using an adaptation of this strategy on our project, it avoids many of the problems and complexity of the release plugin.

Maven Releases on Steroids

分享给朋友:
您可能感兴趣的文章:
随机阅读: