maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Continuous Delivery and Maven
Date Tue, 09 Nov 2010 09:24:00 GMT
I think some of the issues are around missuse of Maven.

Maven is a build tool, use it to do your build.

CD needs a separate layer above Maven to do the deployment... now one
could use maven plugins to provide that layer, but there are two
issues I see:

1. the maven lifecycle does not include the phases you require

2. inbetween invokations of maven, we have no means to share state

so lets say for #1 we add a phase of "ship"... we'd have the standard
lifecycle something like

validate -> ... -> compile -> ... -> test -> ... -> package -> ... ->
verify -> install -> deploy -> ship

that would allow us to bind our CD steps to the "ship" phase... ok, so
people would have to get used to the fact that Maven uses "deploy" to
mean "copy artifact to remote maven repo" and not the CD meaning of
deploy... but people can "Just Get Over It(TM)"

that allows any build to just go

mvn clean ship

and away we go... except that we would be dealing with -SNAPSHOTs...

so to correct for that we would change the release goals using the
release plugin to be "ship" in place of deploy... to gain speed (at
the expense of better tested releases), we could even modify the
preparation goals using the release plugin to be just "clean validate"
and not "clean verify"

then

mvn release:prepare

would be quick

mvn release:perform

would do the CD

Hmmmm... most of this is actually fine for CD, and we don't even
really need the "ship" phase as we could just bind to the deploy phase
using the release profile to ensure that it only takes place during a
release...

The down side is we have no way to roll-back easily....

e.g. we've just released 2.1.5652 but we have egg on our face due to
an automated QA test that is giving a false pass... we have no way to
revert back to 2.1.5651 except:
 A. to revert the commits and roll a new release
 B. put in the 2.1.5651 artifact by hand

we can check-out the tag for 2.1.5651 and run "mvn ship -DskipTests"
or "mvn deploy -Prelease -DskipTests" depending on whether we actually
got the "ship" phase into the standard lifecycle or whether we just
used the release profile to bind to the deploy phase.... but at the
end of the day, that would be rebuilding the binaries... which (with a
strict QA hat on) invalidates testing...

I think what you need to do is have a maven-ship-plugin or a
ship-maven-plugin that works a little like this:

it takes a parameter shipVersion which by default evaluates the
property shipVersion, but if that property is not defines then
defaults to ${project.version}

The m-s-p then resolves the shipVersion of the project artifact and
passes that file onto a ship script...

so if I have a war project foo:bar:1.0-SNAPSHOT:war

mvn ship:ship -DshipVersion=1.0.56

will redeploy the old version 1.0.56

mvn package ship:ship

will build the current source code and ship that

mvn ship:ship

will resolve the latest 1.0-SNAPSHOT from the local/remote repos and ship that

we could add a parameter allowSnapshots that will default to false in
order to prevent accidental deployment of non-releases

and if you are doing CD you can bind ship:ship to the deploy phase in
your release profile.

I think I'll knock something together @mojo to help with this

On 8 November 2010 19:20, stug23 <pat.podenski@gmail.com> wrote:
>
> We need to figure out how to best leverage Maven (keeping in mind its process
> and practices) in a Continuous Delivery solution. I like the conversation
> around this topic and also see that there is this other discussion about the
> meaning of CD versus CI.
>
> From the comments so far, there has been a fair amount of discussion about
> how to use SNAPSHOTs as if they were something that they aren't. Namely
> retaining SNAPSHOTs all the way through release, possibly mutating the
> metadata to make the builds products look like released artifacts instead of
> SNAPSHOTs without having to rebuild the binaries. Since a SNAPSHOT works
> well for a "work in progress" and not for a "thing I want to keep", maybe a
> different approach would work better.
>
> Maybe it would make more sense to just burn lots of version numbers (e.g,
> 3.5.1099) and always release with a new yet-to-be-defined Maven release
> plugin that reflects the processes involved with CD. If the concern is disk
> usage or inefficiency, perhaps some automation can make this more
> manageable?
>
> I would be interested in inputs on this topic from the Maven founders if
> they are following this thread.
> --
> View this message in context: http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370p3255592.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

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


Mime
View raw message