Slashdot Mirror
Should Developers Have Access To Production?
WHiTe VaMPiRe writes "Kyle Brandt recently wrote an editorial exploring the implications of providing developers access to the production servers of a Web site. He explores the risk introduced by providing higher level access as well as potential compromise solutions."
Whenever an error occurs that I can't replicate in a dev environment, I'm always SO tempted to hop into prod and start adding in some output statements.
Yeah, it's probably a good thing I don't have access to prod.
LOL! No.
Everyone agrees that developers should never have access to production...Unless they're the developer, in which case it's different.
Its a good practice to keep them separated, but in the end its just a pissing contest. The server admins don't want some filthy dev messing with their stuff, and I can appreciate that.
However, admins often lack appreciation of some dev-specific issues, and their ignorance can lead to problems down the line.
In the end, its the best practice to have everyone work together sensibly, than throw down inflexible rules that cause more trouble than they prevent.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
This is why there is a change control process, and a testing environment.
If you're doing it wrong, you're asking for trouble.
The price is always right if someone else is paying.
On the other hand, I wouldn't want the surgeon to have to give instructions to a trained monkey on how to do the the surgery because the surgeon does not have access to the production patient.
So why would we want developers to work with the expectation that they get to intervene at the last instant to resolve their failures?
Because if there's a problem, there will be an expectation that they need to intervene to resolve their failures.
To play Devil's Advocate here, there are some semi-legit reasons why developers might get production access:
Now, none of this should be done willy-nilly. The basic rule at my workplace is that a developer can do nothing that could potentially alter behavior without managerial approval and admin approval where appropriate. At the same time, the primary enforcement of that rule is trusting our devs, so very little of that is actually enforced technologically.
I am officially gone from
I work for a big company where every significant business unit has it's own devs and own processes. And while I'm primarily an admin, I still deploy some dev-level stuff a few times a year.
And nothing, nothing annoys me more than going to a shop where the admin doesn't understand the tech, doesn't read the project requirements, and will not, under any circumstances, let me see his production hardware before he tries to deploy.
Because inevitably it fails and then he tries to throw me under a bus, and I have to get on a conference call and try to use my magic mind powers to debug a system I'm still not allowed to see.
Back when I was primarily a java dev, I used to have to configure Tomcat all the time, and it was the sort of thing were you needed to have some experience. And time after time I'd end up dealing with some windows admin who knew absolutely nothing, but was utterly convinced that I could never know more than him about a server technology.
In short, common sense and a reasonable respect for experience beats a hard and fast rule any day.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
Comment removed based on user account deletion