maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yanko, Curtis" <curt_ya...@uhc.com>
Subject RE: Continuous Delivery and Maven
Date Mon, 08 Nov 2010 14:33:23 GMT
Jez,

Again, you have carefully crafted a loosing scenario, which are easy to
do, just lay out a bunch of bad practices a your in . You seem to be
interested in A but ignore B and C. If you can rebuild A, why not B and
C? In this scenario you have crippled Maven and would need to rely on a
Build Management system to have mapped the relationships and have
captured the meta-data. If the relationships are mapped between A,B & C
then you would have some record of which ones were used. But, lets play
devils advocate and say we weren't following our process and people were
skipping steps. Your scenario is the *we didn't know* one and *can we go
back*?

In your case you are treating B and C as *external* dependencies and you
seem to assume they aren't hitting any milestones and *releasing*. As
external deps (separate SVN roots) we would never rely on a SNAPSHOT
version of them. In a CD world we would live with the most recent
*release* they have until they delivered new value. So, if we really
wanted their latest SNAPSHOT we would get it released so we can consume
it.

If it were in our repo root, we can go back and recreate the whole repo
and rebuild everything. Only *our* stuff can be SNAPSHOT (again, we're
doing the work).

If we take your logic to it's extreme are we saying the CD can not
tolerate a broken build? It can't possible be delivered! You've
abandoned Tags and Branches so I assume you have a fall forward
mentality (or roll back). In the case of a broken build in a CI system
using a Build Management System we should be able to very quickly get
back to a good build which could then be delivered.

What's more is I feel you are taking a narrow look at things. A world of
only SCC and Maven with no Build Management System. In this world you
would need to enable uniquely ID's snapshots in your Binary Repository
and at the very least retain your build logs, then you could go back to
that build of A and look at the log to see exactly which SNAPSHOTs were
used. Now you can have big continuous *jello* view of the world and
still have a detailed bill-of-materials. Not that you'd need it mind you
since your artifact would have been uniquely ID'd and stored (presumably
as a complete package somewhere) and now you don't even have to rebuild,
just go back and grab it and go from there.

While this is not how I'd use Maven, if you are willing to throw disk
space at the problem, so you can just keep everything and you're all
set.

________________________________

Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
Making IT Happen, one build at a time, 600 times a day

-----Original Message-----
From: jhumble [mailto:jez@jezhumble.net] 
Sent: Sunday, November 07, 2010 11:41 PM
To: users@maven.apache.org
Subject: Re: Continuous Delivery and Maven


Hi Curtis

I'm the first to admit I'm no Maven expert.

So please let me just confirm. Let's assume I am working on project A
which depends on projects B and C. For the sake of argument, let's say
that the source code for A, B and C have separate roots in SVN, and are
usually checked out independently. The CI system builds A at version 50
using snapshot dependencies on B and C, which are fetched from a central
snapshot repository.

Later, there are multiple updates to projects B and C which result in
new versions of them becoming available.

Say I now check out the source code to project A to version 50, because
I want to try and debug some issue that cropped up in a performance
testing environment, and I run a maven build. Will that use the latest
versions of the snapshots from the repo, or the versions that were
originally fetched when it was run on the CI system?

Can I even find out exactly which versions from svn the snapshots of B
and C came from that were used by the CI system to generate the original
build of A?

Thanks,

Jez.

On 7 November 2010 20:10, Yanko, Curtis [via Maven] <
ml-node+3254520-1036569885-143561@n5.nabble.com<ml-node%2B3254520-103656
ml-node+9885-143561@n5.nabble.com>
> wrote:

> Very interesting discussion. With all due respect to Mr. Humble, and I

> am a big fan of CD, I am going to venture to say that you don't 
> understand Maven very well. As a thought experiment, you are correct 
> in saying that a build based on snapshots is not reproducible. As a 
> more practical matter however, I feel it is.
>
> Dependencies come in two flavors, our and theirs (internal and 3rd 
> party). If, all of *our* dependencies are SNAPSHOT (we're doing the
> developing) and all of *theirs* are 'versioned' then the build is in 
> fact reproducible assuming you build everything from a particular repo

> version even with the default auto-update setting (in fact, it's 
> required).
> ________________________________
>
> Curt Yanko | Continuous Integration Services | UnitedHealth Group IT 
> Making IT Happen, one build at a time, 600 times a day
>
> -----Original Message-----
> From: jhumble [mailto:[hidden 
> email]<http://user/SendEmail.jtp?type=node&node=3254520&i=0>]
>
> Sent: Sunday, November 07, 2010 11:15 AM
> To: [hidden email] 
> <http://user/SendEmail.jtp?type=node&node=3254520&i=1>
> Subject: RE: Continuous Delivery and Maven
>
>
> Hey Todd
>
> The whole point of continuous delivery is that every check-in creates 
> a potential release candidate.
>
> When you're doing continuous deployment, you could be releasing 
> multiple times a day, so you don't bother cutting branches or tagging 
> or any of that stuff because of the overhead. I'd rather not get into 
> the justification for this process on this thread - but I wrote a book

> on it if you're interested:
> http://www.amazon.com/gp/product/0321601912 and many other people have

> blogged about it.
>
> You're right that creating a concrete release for each commit could 
> potentially use up a lot of space - but that's fine, you can just 
> delete the older ones. What this *does* mean in turn though is that it

> is essential to be able to recreate any given build given the version 
> in source control it came from, and this is where Maven falls down.
> Snapshots just aren't suitable because they aren't reproducible: what 
> the snapshot looks like depends not only on what versions of the 
> dependencies are available at the time the snapshot is created, but 
> also what Maven's configuration and plug-ins happen to be at the time 
> you run it (assuming Maven is configured to auto-update - the 
> default). I can't revert back to a particular revision in version 
> control, run maven, and be sure that the artifact it generates is 
> identical to the one it created when the commit was initially
triggered.
>
> Ideally what I'd like is for Maven to explicitly support the 
> continuous delivery model and provide snapshots that are reproducible.

> Failing that, a guide to configuring Maven so that its binaries are 
> reproducible (for example by switching off auto-update, and having 
> sufficient metadata stored in pom files and Maven's artifacts 
> repository to know what the state of each of the dependencies was at
any given time.
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453
> 70<http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32
> 45370?by-user=t>
> p3254090.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden 
> email]<http://user/SendEmail.jtp?type=node&node=3254520&i=2>
> For additional commands, e-mail: [hidden 
> email]<http://user/SendEmail.jtp?type=node&node=3254520&i=3>
>
>
> 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: [hidden 
> email]<http://user/SendEmail.jtp?type=node&node=3254520&i=4>
> For additional commands, e-mail: [hidden 
> email]<http://user/SendEmail.jtp?type=node&node=3254520&i=5>
>
>
>
> ------------------------------
>  View message @
> http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp32453
> 70p3254520.html To unsubscribe from Continuous Delivery and Maven, 
> click
here<http://maven.40175.n5.nabble.com/template/TplServlet.jtp?tpl=unsubs
cribe_by_code&node=3245370&code=amV6QGplemh1bWJsZS5uZXR8MzI0NTM3MHwtMTg4
MjM1NzMyNA==>.
>
>
>


--
Jez Humble
Co-author, *Continuous Delivery <http://continuousdelivery.com/>*
http://continuousdelivery.com/ http://jezhumble.net/

--
View this message in context:
http://maven.40175.n5.nabble.com/Continuous-Delivery-and-Maven-tp3245370
p3254534.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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


Mime
View raw message