> "Shipping software and running tests should be fast. Super fast. Minutes, tops." hahah

You mean to tell me not everyone works on some SaaS product outside of critical path?

Charity's been running honeycomb.io, a SaaS startup with millions of dollars of revenue, for 9 years now, after being an early-stage engineer at Parse, a mobile backend-as-a-service startup that powered half a million mobile apps. She's talking about what she's made a reality at her company and its clients.

Deploy to what? Staging on every merged PR (commit to stg), and prod deploy on every commit to main? That sounds reasonable to me, and I've done some variation of it on most projects for the last 10 years or so without issue.

Well people aren't talking about not deploying to staging on Fridays.

And there are hints to what the author actually means, like "Each deploy should be owned by the developer who made the code changes."

That just isn't feasible in a system that's of any reasonable size.

Yeah, what happens when Team A makes a change and Team B makes a different, seemingly unrelated change, and they both get merged and pushed... only to have a dozen customers discover that if someone is using Feature X that Team A just worked on and Feature Y that Team B just worked on while they have Uncommon Option Q enabled, then their backend process server will crash taking down their entire instance.

Who's fault is that?

Asking because I have been the customer with Uncommon Option Q enabled.