[SpicyLemonZest]

The key insight here is that all code deployments have a risk of going wrong in a way that hurts the company’s bank account, and human beings following instructions to be careful do very little to mitigate that risk. This doesn’t mean CD is the right tradeoff for everyone, but it doesn’t change the problem space in some fundamental way - all of the tools you mention mitigate approximately the same risks regardless of how you develop your code.

[notyourday]

CD makes developers careless because they start blindly relying on "it always works".

[yokaze]

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).

[notyourday]

> 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.

[SpicyLemonZest]

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.

[falcolas]

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.

[crdoconnor]

IME that culture, where it exists, varies from organisation to organisation and is driven from the top.

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.

[falcolas]

> 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.

[crdoconnor]

Correct, it aims for mediocrity. If the customer requested 50 McDonald's hamburger, is it a cultural problem that you're not delivering one steak?

[falcolas]

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.