“A man stretching out his two hands with careless written on them in black and white” by Mitchel Lensink on Unsplash
I have to disagree with the main premise of the article, that developers should be relegated to “safe” roles.
Developers have to be able to access production data, and sometimes, you have to be able to write that data. Let me give an example: we recently had someone pay us in a method other than the in-app Stripe form, and we have to give them brand-as-author credits. How else would we do this besides modifying the production database? It’s not some wild change – just an integer field. It’s not that crazy to make a change to the production DB in this case, and in a lot of other cases.
In short, I don’t believe this is an adequate solution, and you should absolutely have database backups, regularly, lest you invoke the wrath of the chaos gods! It’s a nice thought, to relegate developers to certain roles, in theory, but it just won’t work in practice from anything I’ve seen in my experience.
Austin, thanks for sharing your opinion. You are correct about the need to have backups done regularly. That’s why my article starts by stating, “Unless you can restore the data from a backup, you are in a terrible situation!”.
“Should a developer have access to a production database?” is more of an organization’s best-practice decision. I worked for many companies where “The principle of least privilege” is strictly enforced. However, if you do work in an organization where you wear multiple hats of Developer, DBA, and Operations, then you may need more privileges in such scenarios.
Referring to your example scenario, I understand that manually updating the “integer field” is an ad-hoc request, and someone needs to edit it manually. The main purpose of the article is to suggest measures one could take to prevent the users from accidentally deleting/dropping the data by using custom roles.