On 8 November 2010 15:41, Thiessen, Todd (Todd) <tthies...@avaya.com> wrote: > 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. >
Except you won't know until you go to start up CD that you CD process got broken. The point of CD is that the process is _always_ there, so you know that it's _always_ working If there are critical features that must prevent deploying to the customer, then write CD verification tests for those features and they will block deployment until the features are ready... leave the process in place and let the process prevent the deployment until the features blocking deployment are ready > 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. Only fi you haven't automated your CD properly ;-) > > 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? I'm thinking tha Ci wouldn't be affected at all, CD still requires Ci as a quality metric preventing deployment to the customer. > > 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. CD is deploying to a live customer accesible system, anything short of that is just another level of CI -Stephen BTW, CD is more useful with SaaS than with shipping physical media > >> -----Original Message----- >> From: Stephen Connolly [mailto:stephen.alan.conno...@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) <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 > > > --------------------------------------------------------------------- > 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
