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