Continuous development, continuous unit test, continuous integration, continuous system test, continuous QA, continuous release, and continuous deployment are all great concepts, and they work extremely well, as long as everyone remembers that it's no good shoving something out the door if it doesn't work - and that means that you've got to ensure that salesmen, marketeers (and managers in development, integration, QA, or operations chasing a bonus for quick work) can't hijack the process to achieve their personal aims. That's the only difficult part of continuous development, release and deployment - and it's really difficult, unless you can get the CEO onside.

And of course it isn't really continuous: it isn't even high frequency discontinuous: you are not going to be deploying a new system every 5 microseconds; it's incremental - and the people who pioneered it way back when called it incremental integration, validation, and release. And how often increments are deployed will vary - several increments in development and unit testing may turn into one larger increment in integration and QA, and several QA increments may turn into one release (I tended to try to avoid that happening when I was in charge), and not all releases will be deployed for every customer (ok, that could cause issues for customer support if you didn't keep good records of what went where and did let crud get out the door).

I haven't seen it put developers under extra pressure; in fact when properly managed it causes much less developer pressure than outmoded operating models like the waterfall.