Hey Stephen. I read through your idea a little more closely and I like it. The only thing I think it is missing is the ability to use snapshots as dependencies. That is a very powerful feature of maven that I don't think you'd want to lose if your using CD.
It is almost like you'd want a mode in Maven. Say you had some kind of flag that said "Continuous Delivery" mode. In this mode, you would only use release repositories when deploying artifacts or downloading artifacts. Nothing would ever get built as a snapshot, even if your pom has snapshot versions. In CD mode, you always use the latest release artifact of your dependencies. You could never pull artifacts from a snapshot repository in this mode. So, for example lets my project's version iss 1.0-SNAPSHOT. When I do: mvn deploy it would deploy release 1.0-0001 to the release repo. If my project had any snapshot dependencies, it wouldn't have to checkout and rebuild these. Those dependencies would also have to be in "CD mode" and all artifacts would have to be to the release repo. So if my project has a dependency on some artifact with version: 3.2-SNAPSHOT while in CD mode, maven would query the release repo, find the latest release artifact (say 3.2-0122) and use that. This would of course fill up your release repo but I think you would need to think of a release repo a little differently if your doing CD. > -----Original Message----- > From: Stephen Connolly [mailto:[email protected]] > Sent: Tuesday, November 09, 2010 4:24 AM > To: Maven Users List > Subject: Re: Continuous Delivery and Maven > > 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 <[email protected]> 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
