http://mojo.codehaus.org/ship-maven-plugin
Let me know what you think?
-stephen
On 9 November 2010 09:24, Stephen Connolly
<stephen.alan.conno...@gmail.com>wrote:
> 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.poden...@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-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
