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 16:04:54 GMT
Why bother... the checkin is automatic and actually a good thing IMHO

On 9 November 2010 15:37, Yanko, Curtis <curt_yanko@uhc.com> wrote:
> What if you just avoid the check in?  Only package the pom and deploy the jar?
>
>
> ________________________________
>
> Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
> Making IT Happen, one build at a time, 600 times a day
>
> -----Original Message-----
> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> Sent: Tuesday, November 09, 2010 9:32 AM
> To: Maven Users List
> Subject: Re: Continuous Delivery and Maven
>
> On 9 November 2010 14:10, Thiessen, Todd (Todd) <tthiessen@avaya.com> wrote:
>> 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.
>
> Well I regard that the project being delivered can only have internal -SNAPSHOT dependencies,
all external (to the reactor) dependencies should be release dependencies.
>
> One of the things I have wanted to do with v-m-p is to hack around version ranges...
for example...
>
> if we develop using
>
> <dependency>
>  <groupId>foo</groupId>
>  <artifactId>bar</artifactId>
>  <version>[1.0,2.0)</version>
> </dependency>
>
> when we run the preparation goals in release:prepare, we have the opertunity to modify
the pom and have that modified pom checked in, so there is nothing stopping us from resolving
the range, e.g.
>
> <dependency>
>  <groupId>foo</groupId>
>  <artifactId>bar</artifactId>
>  <version>1.1.3</version>
> </dependency>
>
> and now the tag is a locked down reproducible build.... but the developer is stuck with
the locked down version...
>
> so, if somehow we can tweak things... stick in a comment... or better yet an XML PI
>
> <dependency>
>  <groupId>foo</groupId>
>  <artifactId>bar</artifactId>
>  <version>1.1.3</version>
>  <?org.codehaus.mojo:versions-maven-plugin range="[1.0,2.0)"?> </dependency>
>
> then all we need is a postReleaseGoals added to release:prepare and we can have v-m-p
put the version ranges back in...
>
> Which would give you repeatable releases and bleeding edge dependencies... but only released
dependencies.
>
> The problem with -SNAPSHOTs is that they can be deployed without having passed testing.
>
> MRM staging support is really about having atomic releases of multi-module artifacts,
e.g. make sure they either all get deployed or none get deployed.
>
> -Stephen
>
>>
>> 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:stephen.alan.connolly@gmail.com]
>>> 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 <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
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.
>
>
> ---------------------------------------------------------------------
> 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