Release builds and continuous integration

[David Jackman <Da...@fastsearch.com>]

I've just started to get my hands wet with Maven 2, and I must say I
like what I'm seeing.  Just about every headache we currently have with
Maven 1 is addressed to some extent by Maven 2.
 
One problem we were having around Maven 1 that I'm not too sure about
for the future is the issue of "official" release (non-snapshot) builds
and continuous build tools (like CruiseControl).  When releasing a Maven
project, the goal is to have as much confidence as possible (a
guarantee, hopefully) that the release build in the Maven repository
exactly matches the code that was tagged in source control for that
project.  The following is a list of potential risks we have in our
current Maven 1 process that I'm hoping Maven 2 can mitigate.  Can
anyone respond to these?
 
1. In Maven 1, we use the scm:prepare-release goal to start the release
process.  When it works (see the issues I've logged about it), this goal
changes the currentVersion to the release version, tags the code in
source control for the release, and adds a <version> element indicating
the release version and its corresponding SCM tag.  Sometimes, the
developer doing the release will want to build & deploy the official
release build himself to be sure it matches the tagged code.  When the
release build is complete, he will (should) change the currentVersion to
the next snapshot version.
However, since we use a continuous build tool, there is a risk that
between the time the developer deploys the release build and checks in
the project.xml with the next snapshot version, the automated build will
do its own build using the release version and deploy over the top of
the "official" release build.  There are steps the developer can take to
mitigate this, but it would be better if Maven helped out more.  For
this scenario, the easiest solution would be for Maven to fail the
deploy for a release (non-snapshot) version if there is already an
artifact in the destination repository of the same name.  Is this
possible?
 
2. Ideally, we'd prefer that the build machine (running the continuous
build tool) do the official release builds because it's more of a
controlled build environment.  However, there are two risks here.  First
is that the build tool will do more than one build of the release
version (before the currentVersion is changed to the next snapshot
version).  The solution in the previous paragraph would help here as
well.  The second risk is that someone else will check in a code change
before the build tool does the official release build, so the release
artifact does not match the code tagged for that release in source
control.  Any ideas on how to address this problem?
One approach would be to have some plugin on the continuous build
machine that checks the projects before starting the build (but after
the latest code is obtained from SCM) to see if any projects have a
release (non-snapshot) currentVersion value.  If so, this plugin would
use the <version> element for this version to make sure that the code
that will be built matches the tag for this release.  Then it lets the
build go on.  Would this be hard in Maven 2?  Even better would be to
have a plugin that, once the release build is finished and deployed,
would change the currentVersion to the next snapshot version.
 
What do you think?  Has anyone else had to deal with this risks?  Is
there a better approach to solve these problems that I'm not seeing?
 
Thanks,
..David..

Re: Release builds and continuous integration

[Jeff Jensen <je...@upstairstechnology.com>]

Consider that this is outside of the build tool.

I suggest branching to a "release codeline" for releasing from, when the product
is ready.  Your release process sounds "formal enough" for this (it is usually
easy to be "formal enough").

You can also then take care of #2 by having it monitor the release codeline too.

Each codeline must have only one purpose, and at the time of your release, you
are overloading that codeline with two purposes - ongoing development and
releasing.

Hopefully you will find, as others do, this approach simplifies the release prep
process.


Quoting David Jackman <Da...@fastsearch.com>:

> I've just started to get my hands wet with Maven 2, and I must say I
> like what I'm seeing.  Just about every headache we currently have with
> Maven 1 is addressed to some extent by Maven 2.
>
> One problem we were having around Maven 1 that I'm not too sure about
> for the future is the issue of "official" release (non-snapshot) builds
> and continuous build tools (like CruiseControl).  When releasing a Maven
> project, the goal is to have as much confidence as possible (a
> guarantee, hopefully) that the release build in the Maven repository
> exactly matches the code that was tagged in source control for that
> project.  The following is a list of potential risks we have in our
> current Maven 1 process that I'm hoping Maven 2 can mitigate.  Can
> anyone respond to these?
>
> 1. In Maven 1, we use the scm:prepare-release goal to start the release
> process.  When it works (see the issues I've logged about it), this goal
> changes the currentVersion to the release version, tags the code in
> source control for the release, and adds a <version> element indicating
> the release version and its corresponding SCM tag.  Sometimes, the
> developer doing the release will want to build & deploy the official
> release build himself to be sure it matches the tagged code.  When the
> release build is complete, he will (should) change the currentVersion to
> the next snapshot version.
> However, since we use a continuous build tool, there is a risk that
> between the time the developer deploys the release build and checks in
> the project.xml with the next snapshot version, the automated build will
> do its own build using the release version and deploy over the top of
> the "official" release build.  There are steps the developer can take to
> mitigate this, but it would be better if Maven helped out more.  For
> this scenario, the easiest solution would be for Maven to fail the
> deploy for a release (non-snapshot) version if there is already an
> artifact in the destination repository of the same name.  Is this
> possible?
>
> 2. Ideally, we'd prefer that the build machine (running the continuous
> build tool) do the official release builds because it's more of a
> controlled build environment.  However, there are two risks here.  First
> is that the build tool will do more than one build of the release
> version (before the currentVersion is changed to the next snapshot
> version).  The solution in the previous paragraph would help here as
> well.  The second risk is that someone else will check in a code change
> before the build tool does the official release build, so the release
> artifact does not match the code tagged for that release in source
> control.  Any ideas on how to address this problem?
> One approach would be to have some plugin on the continuous build
> machine that checks the projects before starting the build (but after
> the latest code is obtained from SCM) to see if any projects have a
> release (non-snapshot) currentVersion value.  If so, this plugin would
> use the <version> element for this version to make sure that the code
> that will be built matches the tag for this release.  Then it lets the
> build go on.  Would this be hard in Maven 2?  Even better would be to
> have a plugin that, once the release build is finished and deployed,
> would change the currentVersion to the next snapshot version.
>
> What do you think?  Has anyone else had to deal with this risks?  Is
> there a better approach to solve these problems that I'm not seeing?
>
> Thanks,
> ..David..
>




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org