CD makes developers careless because they start blindly relying on "it always works".
You make a mistake, it will end blowing up in production. Without CD you have a batch of changes, and the responsibility becomes diffused.
The main gain I see from not doing continuous deployment is to manage the expectations of customers on reliability during a deployment. (We are deploying every X, at Y, expect some turbulence).
If that's the case, then the project is too small and CD is a overhead.
If the teams are large and CD is used for deploys then you need to have the supporting infrastructure on every step i.e. end-to-end integration tests, instrumentation, monitoring and automatic actions based on the instrumentation and monitoring. That's the unsexy part that's missing.
> The main gain I see from not doing continuous deployment is to manage the expectations of customers on reliability during a deployment. (We are deploying every X, at Y, expect some turbulence).
Making deploys hitless should be a step taken before going into CD.
I'm a bit old fashioned in this regard, but I'd prefer that we didn't accept that "bugs in production happen" as normal and instead treat the bugs as a failure of process.
I think a lot of companies don't care about bugs as much as their developers do though, and that isn't necessarily irrational behaviour.
Some kinds of customer facing bugs really are ok to just let happen.
That's the exact mindset of the culture I mentioned. You can justify any kind of bug hitting production with it. It does the exact opposite of pushing things towards a better state; it aims for mediocrity.
Even if striving for zero bugs in production is functionally impossible, it encourages developers (and the entire company) to move towards quality, not away from it. Striving for 100% is what drives change.
Software development is not at that point. Sometimes we put three pickles on instead of two. Sometimes we forget the pickles. Sometimes we spread ketchup all over the outside of the bun. Sometimes we forget to cook the meat. And we don't aim for a good hamburger, we just aim to get something remotely hamburger shaped out the door to the customer.
Whereas apparently many software engineers do not take their cue from customers since they strive for some impossible "no bug policy" (or some other such rubbish).