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."

Read-only, if that, and nothing more.

[Junior J. Junior III]

If you want to have control over your production code, you need to have assurance that it is not changing in an uncontrolled fashion. Allowing developers to have access to production locations makes it all too easy for this to happen. Read-only access allows developers to see the running code and perform file comparisons which can be useful in troubleshooting. They should never need more than this.

And in some cases, even read access can be risky -- I've seen production web sites with resources linking back to development server URIs. It's a good idea to firewall your production servers in such a way that it is not possible for them to reach resources on development servers. This shouldn't prevent developers from being able to read the files on the production server, though.

Jesus no

[BigJClark]

The day developers can write code that compiles the first time, then yes, otherwise, jesus, no.

I work as an Oracle DBA for a mid-size company, and I provide a day-old cleaned copy of production in a different environment/box, and it does the trick.

Install Good Logging Practices

[FatSean]

With some fore-thought and some discipline an application can be developed with very robust logging techniques. It takes development time, but there is nothing cooler than asking the production guys to turn the logging detail up for a few packages and seeing tons of data in the logs. It's not perfect as you can't log every variable at every moment but it certainly does help.

I understand some shops can't or won't modify the logging levels on production servers.

Re:For me

[TheRaven64]

Depends on how your deployment system is designed. Mainline Xen now has support for brining up complete live duplicates of a running VM and keeping them in sync (or letting them diverge), and this support has been in high-availability hypervisors for decades. If you're using a system like this, it's just a couple of commands to clone the production VM and get something that you can break without impacting users.

Re:Install Good Logging Practices

[GuidoJ]

That's why you should always try to log all inputs and outputs (which includes configuration data, etc.) along with a timestamp. Afterward you can replay the situation in a test environment. If you properly set this up during development phase, this will already pay back during test phase. The developer can analyse the problem offline and proof that the fix actually solves the issue before it is shipped to production. It could even be part of an automatic testing environment.

Re:For me

[Americano]

I can't disagree with that, but the stuff you're listing is more or less a one-time setup cost: The point made by GGP was that deploying to a prod-clone system ('keeping it matching production') takes time - and that should not take any more time or effort than deploying to your existing prod or qa or uat systems.

If it takes great, ongoing manual effort to install your software on a single extra system, you're doing it wrong.

Re:For me

[mwvdlee]

How do you get shadow to have the same load as production? That's the really important part that often makes the production-clone quite different: much lower load.

The idea of shadow was to test real-life production. It was basically identical to production in every way (including that developers had no access to the data; AFAIK it was anonymized anyway), except the data wasn't used for anything. Software had to run uninterrupted for a number of weeks before it would be allowed to go to production.

Sometimes all those stages are a pain, but in the end it results in a much more stable production.