That sounds… Kinda dumb, to be honest. A much more sensible thing to do is grant developers read-only access to production systems as necessary, and allow requests for temporary elevated write privileges (with separate accounts) that require justification, communication, and approval so that every one understands what is happening. Developers should have ownership and responsibility for their systems in production. This is what we do at my company.
Someone has to be able to make changes to production environments at times. If it’s not developers, it’s devops or the like. There are plenty of times where the devops folks lack the necessary information or context to do what needs to be done. For example, if there’s somehow corrupt data that made it’s way into a production database and is causing an outage, a developer is likely going to be the person to diagnose that issue and understand the data enough to know what data should be deleted and how. I would absolutely not put that in the hands of devops on their own.
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.)
That sounds… Kinda dumb, to be honest. A much more sensible thing to do is grant developers read-only access to production systems as necessary, and allow requests for temporary elevated write privileges (with separate accounts) that require justification, communication, and approval so that every one understands what is happening. Developers should have ownership and responsibility for their systems in production. This is what we do at my company.
Someone has to be able to make changes to production environments at times. If it’s not developers, it’s devops or the like. There are plenty of times where the devops folks lack the necessary information or context to do what needs to be done. For example, if there’s somehow corrupt data that made it’s way into a production database and is causing an outage, a developer is likely going to be the person to diagnose that issue and understand the data enough to know what data should be deleted and how. I would absolutely not put that in the hands of devops on their own.
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.)