Developers code. Developers review code. Developers write code to test code.
Developers can't touch production.
Automated checks of ANYTHING are golden because you aren't relying on people, and you aren't pitting people vs people.
It is all about consistency when you boil down to the bones of a well-running team.
Start with those rules and actually follow them and you end up with a pretty awesome setup, because Developers will naturally gravitate to defensive, test-driven programming when those are the rules.
1) All code is reviewed before it is merged, this is easily enforcable in bitbucket or github, probably others, but use one of these two anyway. It won't stop all your problems, but it is great triage and it forces lone-wolf mitigation. I don't even care if the reviewer is an expert... this isn't a gate keeper activity as much as it is a sanity check. "hey why did this variable get set, then re-set before you checked it?" or "hey how come you deleted 90 source files?"
2) All your code goes through some kind of code-quality gate like Sonar Qube or some other Linting tool. This can find and highlight common mistakes, and get them fixed before they are even reviewed. Developers hate to modify a pull request, so give them as many free "oh if I fix this nobody will bother me" wins
3) All unit tests must pass before code is merged. This is slightly tricky but you are going to need Jenkins or some other tool that is not as widely used as Jenkins; and integrate it into your bitbucket/github.
4) All deployments are automated. Sure you can have someone push a button, but they shouldn't have to fiddle with anything. And whoever is pushing that button can't be a developer.
5) Since your deployments are automated, your QA system is exactly like your production system (but maybe smaller scale) this way you are actually testing the thing as it will be deployed. "Kinda sorta how it will work in prod" is never a good test. If your QA deployment is automated, and the deploy is broken in QA,
then you have to fix it before it goes to prod. Ideally your developers can't touch QA either, but you can work toward that.
6) Since your developers aren't touching production, they will be forced to do things like: write actual helpful log messages, not make code changes that break the deploy, and reproduce production problems in Unit Tests so they stay fixed forever.