maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thiessen, Todd (Todd)" <tthies...@avaya.com>
Subject RE: Continuous Delivery and Maven
Date Mon, 08 Nov 2010 15:41:46 GMT
I agree with most of your points here Stephen. Sounds like we may be in "violent" agreement
;-).

The point that I disagree with is trigging a CD off a commit or CI build. You don't need to
ALWAYS be doing CD. 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.

And it isn't just a waste of hard drive or other "mechanical" resources. It just adds complexity
to your lifecycle and processes that just aren't needed. If you know you are not delivering
to a customer for a couple of months, stick with snapshots so you can more easily do CI. If
you are doing CD all the time, it makes CI much more difficult and complicated.

I am all for automating CD. But not at the cost of making CI more complicated.

Or perhaps you are thinking that CI wouldn't be affected at all?

BTW. We deploy our snapshot builds to a live system and do real functional testing of a snapshot
install.  But this is still not a release build and thus wouldn't go to a final customer.
 I think the line here between CI and CD is blurred.

> -----Original Message-----
> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> Sent: Monday, November 08, 2010 9:51 AM
> To: Maven Users List
> Subject: Re: Continuous Delivery and Maven
> 
> CI does not end up on production systems, so CI does not require as
> rigourously reproducible a build as CD.
> 
> With CI, what you want to have happen is the latest code ends up on an
> integration system and integration tests are run against the
> integration system in order to identify integration issues before the
> code goes to QA.
> 
> With CD you have as much of the QA process automated as you are
> comfrtable with, and when you kick off a build, it will automatically
> run though an entirely automated process that ends up with the build
> either failing or being deployed onto the live system... (note that
> you might have one or two manual verifications before deploying to
> production systems, but sooner or later you will have developed enough
> confidence in your CD process that you can feel confident removing the
> manual blocks)
> 
> With CI, I can quite happily work with -SNAPSHOTs because all I need
> to know is that something is broken.
> 
> With CD, I need releases (but perhaps more lightweight than Maven's
> current release process... perhaps I do not need to create tags).
> 
> The question is what triggers the deploy in CD.
> 
> There are a number of possible triggers:
> 
> 1. Manual trigger... where I click a button and the whole process starts
> 2. CI trigger... where a CI build passing triggers the whole process
> 3. Commit trigger... where any commit triggers the whole process.
> 
> The problem with #1 is that you have to remember to trigger
> 
> If you are doing CD correctly, then #2 and #3 are actually the same
> thing with just a re-ordered pipeline.
> 
> #2 goes a little something like this
> 2.1 A commit triggers a build
> 2.2 The build passes and triggers a CI build
> 2.3 The CI build deploys to the integration system and runs the
> integration tests
> 2.4 The CI build passes and triggers the CD build
> 2.5 The CD build runs a release of the software
> 2.6 The CD build deploys the release to the integration system and
> runs the integration tests
> 2.7 The CD build runs the last ditch "no egg on face" tests that could
> take a bit longer than integration tests (e.g. full regression)
> 2.8 All tests have passed and the CD build meets the release to
> customer criteria
> 2.9 The CD build deploys the release to production systems
> 2.10 we are live
> 
> while #3 goes a little something like this
> 3.1 The CD build runs a release of the software
> 3.2 The CD build deploys the release to the integration system and
> runs the integration tests
> 3.3 The CD build runs the last ditch "no egg on face" tests that could
> take a bit longer than integration tests (e.g. full regression)
> 3.4 All tests have passed and the CD build meets the release to
> customer criteria
> 3.5 The CD build deploys the release to production systems
> 3.6 we are live
> 
> #2 saves on the churn of making releases but reduces the response time
> for deployment.
> 
> In any case you also want an automated process that allows you to roll
> the production system back to a previous state just in case the "no
> egg on face" tests let some egg slip through to your face!
> 
> -Stephen
> On 8 November 2010 14:27, Thiessen, Todd (Todd) <tthiessen@avaya.com>
> wrote:
> > True. But how does that change my statement? It still appears we may
> have a different definition of CI.  Because in order to do CD, you would
> no longer be doing CI.
> >
> > Unless of course the original poster is suggesting to abandon CI.
> >
> >> -----Original Message-----
> >> From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
> >> Sent: Monday, November 08, 2010 9:17 AM
> >> To: Maven Users List
> >> Subject: Re: Continuous Delivery and Maven
> >>
> >> On 8 November 2010 13:30, Thiessen, Todd (Todd) <tthiessen@avaya.com>
> >> wrote:
> >> > Interestingly enough, I kind of feel that we have a different
> >> definition of continuous integration.
> >> >
> >>
> >> Interestingly enought, the original poster is talking about Continuous
> >> _D_E_L_I_V_E_R_Y_ as distinct fron Continuous Integrration ;-)
> >>
> >> ---------------------------------------------------------------------
> >> 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


Mime
View raw message