I like where you are going with this but I don't understand the need to re-build or to have two different build processes. I'm in the Maciej Zawadzki camp of Build lives, that a build is just the beginning and you need to manage it in a way that let you come back and continue to advance it if you want.
In my view of CD, you wouldn't come back, ever. You'd just commit code that triggers a build and if it passes each and every quality gate along the way it would get deployed. If it fails at any point, it dies and a new build is created to address the reason it failed. ________________________________ 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.conno...@gmail.com] Sent: Monday, November 08, 2010 9:54 AM To: Maven Users List Subject: Re: Continuous Delivery and Maven On 8 November 2010 14:50, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: > 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! Just to clarify, the only reason you want roll-back is when there is egg on your face you need to remove it fast... while you could just revert back SCM to "known good" state, it's faster to just re-deploy "known good" binaries which had previously met the delivery criteria, rather than have to run through the fuill regression suite again! -Stephen > > -Stephen > On 8 November 2010 14:27, Thiessen, Todd (Todd) <tthies...@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.conno...@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) >>> <tthies...@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-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
