I would claim the opposite: CD makes each developer responsible for their own mess.
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).
> I would claim the opposite: CD makes each developer responsible for their own mess.
> You make a mistake, it will end blowing up in production.
> Without CD you have a batch of changes, and the responsibility becomes diffused.
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 don't think that's true. It's just that less automated pipelines have less of an expectation that new code releases are going to work in the first place. In fully traditional processes, where the release is manually built from scratch every N weeks, there's often no expectation at all - your customers just insist on a scheduled release day, and plan to spend it running around solving the problems the new release caused.
It's more insidious than that, IMO. We've created a culture where severe bugs impacting your customers are OK, even expected. Developers don't try very hard to preemptively stomp bugs, because there's no pressure for doing so.
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.
> 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.
It's funny that you mention a McDonald's hamburger, since there's actually a lot of standards that their hamburger has to live up to. They have just simplified the creation of a hamburger to the point where teenagers can make them properly with minimal supervision.
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.
The point, however, is that the customer/regulator dictates quality standards, not the person assembling the burger.
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).
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).