what should developers have access to?

Question

i work at a place where we build applications that process and store sensitive data. we have 3 environments. Dev, UAT / QA (user acceptant testing) and Production

the developers at my work have no access to UAT or Production and have limited access to Dev. All we can do in dev is connect to a dev DB server . we have no access to the dev server itself. so we arent allowed to play with things like the web server (iis) on dev. if we want changes we must go though a formal process of submitting work requests to our network administrators (which could takes days to complete). the same goes if a developer were to request for something to be checked in a UAT or PRod database. this strict access restriction is really frustrating when trying to support our applications.

i can understand why we have these policies, as it reduces the risk of things getting screwed up. but this makes solving issues really time consuming and painful. something that could take 5 mins to fix (if a developer had access) could take days to resolve.

is this sort of strict access rights normal?

Answer 1

It's about change management; making sure all changes to the system are tracked and make it into release notes, and also that a change in one part of the system doesn't cause problems in another part.

If it was up to me, I'd give each developer a PC powerful enough to run as many virtual machines as needed to emulate the production environment, with total control over those machines. And then make sure every change to the official dev environment is documented so that full release notes can be produced.

Answer 2

Check out Stackify. We just released a new service that gives developers more visibility to their applications and the production servers. We can give them simple read only access to things like log files, config files, windows event viewer, etc. We can solve the problem you describe. We have basically invented DevOps support: http://www.stackify.com

Answer 3

Difficult to say if it's normal. For example, I've worked for investment banks where they have even more draconian procedures than the ones you describe. I've also worked for one IB that had no procedures at all. However, it's noticeable that the former are still in business, whereas the latter went bust famously just recently!

Answer 4

It's a question of what you want

There are 2 competing requirements at work:

• Fast turnaround for fixing problems / developing new code.
• Ensuring that no sensitive data get leaked.

Your company has decided (consciously or unconsciously) that it is better to reduce the risk of leaking sensitive data than to have the ability to fix problems and develop new code quickly. My company leans in the same direction, but is not really clued-up enough to take it to the extremes you are describing.

This is a business decision.

It is made because (probably unconsciously) your company puts a higher value on the downside risk (leaking data) than on the upside risk (making the software work). This is a common bias - it's known as being risk-averse (I'm sure there's a better term than that - anybody?), and it is very annoying for those of us who, trying to get our jobs done, have to overcome a bunch of obstacles put there by people who don't have a good understanding of the impact of those obstacles.

To Summarise

• This is a business decision.
• It's a question of how different risks are perceived.
• It reflects a risk averse position.
• This position has probably been arrived at by the company entirely unconsciously.

Answer 5

Even in a small company, engineers shouldn't need much access to the dev environment beyond code. The core environment should remain fairly static. What types of things on the web server would you like to change at a rapid pace?

Answer 6

Sounds a bit tight to me. Normallly I would expect full control over the Dev server, I'd be happy to see readonly access onthe test server and to be perfectly honest, I'm not interested in looking at the production server (from a development point of view).

Of course, the following assumtpions are made here;

• the 3 environments started off exactly the same
• Changes made to prod are cascaded back to dev via test
• Any configuration changes in Dev are made by the deployer to test and in prod

In our procedure here we don't allow the developer to deploy to test - this is up to the tester before we hand over to a 3rd party who deploys to prod.

This validates our release procedure as much as anything else.

So; as long as everythiong is documented for the release, you shouldn't need access to anything other than Dev, but it would be nice to have a decent level of control over the dev environment.