You are exaggerating to make a point, but... what else would you prefer? That your sysadmins approve your frameworks? How detailed would you get? Do you want a formal approval cycle before installing a new npm package?

I'd prefer an ops team that trusts the dev team is competent, and trusts that if the tests pass, the devs probably made acceptable decisions.

> I'd prefer an ops team that trusts the dev team is competent, and trusts that if the tests pass, the devs probably made acceptable decisions.

You don't need anyone to trust you as long as you're responsible for deploying, monitoring and responding to failures regarding the app, meaning: being on-call for the app(s).

Have you worked in a place that has a dedicated DevOps team, but makes the devs be on-call for the apps?

I work (and have worked for nine years) at a company with a dedicated DevOps team. As a developer, I have never been on call, but I do have to be there for deployment of my code to production (which, due to the nature of the code, happens around 2:00 am my time) to ensure everything is working as expected (and only once was a roll back required).

Not OP, but all of the companies I've worked for have done this.

The most basic was two different schedules, Dev & Ops, where if something went wrong then both responded. The most successful, so far was one where there are multiple on-call rotations that are hooked up to different slices of the alerting tree.

Yes.

That's the attitude that gave Docker its popularity: it doesn't matter how much crap it's in the app, as soon as they've wrapped in Docker's greasy paper it magically stinks less and it becomes Ops' problem.

Really, I always looked at it the other way around: Docker makes devs take responsibility for their dependencies, they can't say "well, it works on my machine."

Add one of the many decent Docker analysis tools and you even have the devs worrying about outdated packages and security vulns.