Obviously there’s nuance to everything, but I think dev and ops (or devops, whatever you wanna call them nowadays) need to work hand in hand on such issues. The devs will understand their application better. The ops will very likely understand the production system better and weird nuances. Two sets of eyes are better than one.
A lot of it depends on company culture. I’ve worked at places where as a dev we basically hand it off to a devops team who then hands it off to another team and we basically never ever touch production. Maybe UAT environments we could touch.
Other places I worked didn’t even have real QAs and as devs we were expected to wear many hats and had much more freedom. There was still a devops team (just one, not two layers like my previous example) who were super helpful and had more of a wide view of everything. As devs we were on an on-call rotation as well as a product support rotation. During the product support rotation we’d fix problems by manually tweaking things on the back end for very unique edge cases or things we just didn’t implement yet. But we had very specific playbooks to follow. We didn’t just arbitrarily write things to the database (nor did we have that sort of permission).
It just all depends on the team’s skills and expectations. Silly example, but if you’re a solo developer working as a sole proprietor, you’re obviously doing everything yourself. You don’t have the luxury of an ops team to help make sure you don’t shoot yourself in the foot.
And obviously it can go both ways, nobody is perfect. As a dev I’ve found a silly typo mistake in a DBA’s code that shouldn’t have happened. (My best guess is that he pasted into something that auto formatted it and the formatter had a bug and changed the behavior of the query.)
Obviously there’s nuance to everything, but I think dev and ops (or devops, whatever you wanna call them nowadays) need to work hand in hand on such issues. The devs will understand their application better. The ops will very likely understand the production system better and weird nuances. Two sets of eyes are better than one.
A lot of it depends on company culture. I’ve worked at places where as a dev we basically hand it off to a devops team who then hands it off to another team and we basically never ever touch production. Maybe UAT environments we could touch.
Other places I worked didn’t even have real QAs and as devs we were expected to wear many hats and had much more freedom. There was still a devops team (just one, not two layers like my previous example) who were super helpful and had more of a wide view of everything. As devs we were on an on-call rotation as well as a product support rotation. During the product support rotation we’d fix problems by manually tweaking things on the back end for very unique edge cases or things we just didn’t implement yet. But we had very specific playbooks to follow. We didn’t just arbitrarily write things to the database (nor did we have that sort of permission).
It just all depends on the team’s skills and expectations. Silly example, but if you’re a solo developer working as a sole proprietor, you’re obviously doing everything yourself. You don’t have the luxury of an ops team to help make sure you don’t shoot yourself in the foot.
And obviously it can go both ways, nobody is perfect. As a dev I’ve found a silly typo mistake in a DBA’s code that shouldn’t have happened. (My best guess is that he pasted into something that auto formatted it and the formatter had a bug and changed the behavior of the query.)