I'm currently on a two-week deployment cycle. It's not only annoying to wait but it's also dangerous. There have been several incidents where the code that broke something was committed a whole week or two weeks before! Worse still is that we're deploying two systems at once and usually we're patching the systems at the same time. So you have a perfect storm of bad things that can happen with multiple causes. Faster means you see the problems sooner.
I see what you're saying, but maybe if you didn't go so fast you could have had properly tested code that didn't break something in the first place. I'd argue that not breaking it in the first place is better than speeding up to find the break.
Yeah I see what you're saying as well and I agree with that. It's hard not to break something when our release cycle depends on a QA person and on customers to break things that we can't always test for (and we're actively discouraged from writing unit tests and other automated tests).
I'm currently on a two-week deployment cycle. It's not only annoying to wait but it's also dangerous. There have been several incidents where the code that broke something was committed a whole week or two weeks before! Worse still is that we're deploying two systems at once and usually we're patching the systems at the same time. So you have a perfect storm of bad things that can happen with multiple causes. Faster means you see the problems sooner.