maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jhumble <>
Subject Re: Continuous Delivery and Maven
Date Mon, 08 Nov 2010 16:58:18 GMT

Todd, I have read all of your posts and I have come to the conclusion that
you're missing the point of CD. I was really hoping to avoid an argument
about process, because I just want to work out what needs to be done to
Maven to make it support CD, and that's already a big enough discussion for
one thread. However since the thread has (perhaps inevitably) been taken
over by a discussion about what continuous delivery is, I will add my 1c. In
any case I think I have what I need from the discussion with Brian.

With CD, the software is *always* production ready, right from the start of
the project. Any work of any kind that doesn't result in a deployable build
is waste.

If you are at the start of a release, your product owner will have a good
> idea of how much content needs to get to the customer to fullfill that
> release. Doing CD through the entire lifecycle is largely a waste IMHO.

Wrong. In fact, it's the opposite - any work that doesn't keep the software
in a deployable, releasable state is waste, because you can't know whether
or not the work you have done is actually useful, or even whether it keeps
the software working. And you can't know whether or not the software is
working - i.e. whether or not the build can be deployed - until it has
passed end-to-end acceptance tests under realistic loads in a
production-like environment.

I am fine with you using the process you describe. If it works for you,
that's great. But please don't call it continuous delivery - it isn't.

Now, assuming we are working in a cd process, the crucial thing is that we
don't waste any cycles creating a build that couldn't be released. We then
take this binary and put it through the rest of the deployment pipeline (or
build life or whatever you want to call it). But crucially, we don't want to
recreate the binary later on. If you want more detail on the mechanics of
how it works, you can read the free chapter from my book here:

*What I want from Maven*

We want the simplicity of snapshots with the traceability of proper
releases. So I think from what Brian said, I'd like the the Maven snapshot
build process to create enough metadata in the pom file such that when you
ran the release plugin, it wouldn't be necessary for it to rebuild the
artifact - it could just do the various bits of tagging and metadata
creation using the information in the pom associated with the snapshot. We
might also want the release plugin to try and recreate the binary using its
process and verify the md5 is the same as the md5 of the snapshot.

If anybody has any feedback on this hypothesis, I'd be very grateful.



On 8 November 2010 08:49, Thiessen, Todd (Todd) [via Maven] <<>
> wrote:

> > I'm thinking tha Ci wouldn't be affected at all, CD still requires Ci
> > as a quality metric preventing deployment to the customer.
> I am curious to see that. Or how it would work. How do you put in fixed
> release numbers into a CD build and then switch back to CI building? And I
> can only imagine it being quite complex.
> The only thing I can think of is something like:
> 1. CI build produces 1.0-SNAPSHOT
> 2. CD build produces 1.0-01
> 3. CD build reverts source back to 1.0-SNAPSHOT
> 4. Repeat
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3255336&i=0>
> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=3255336&i=1>
> ------------------------------
>  View message @
> To unsubscribe from Continuous Delivery and Maven, click here<>.

Jez Humble
Co-author, *Continuous Delivery <>*

View this message in context:
Sent from the Maven - Users mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message