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) <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
