Why shouldn't developers be able to deploy directly to production?

Question

I have always worked in environments where developers had to go through a process of working with Network Operations (server guys) to deploy stuff from development/test to production.

I recently started a job where developers can go directly from their machines to production with no middle man. Are there reasons that developers should not be able to do this?

What I have so far:

• You are more careful about deploying something if it has to go through someone else. As a young programmer it sometimes took me several tries to get a working deployment out. Since the NetOps guys were pissed I learned to make sure it was right the first time.

• There is some accountability if something goes wrong and more than one person knows what's going on. Boss: "The site just went down!", Everyone else in the office: "Abe just did a deploy, it's his fault!"

• When someones sole responsibility is the production server, it's less likely that they will do something stupid.

• There will (hopefully) be more information on the deploy and roll back capabilities. Logs, backups that can be rolled back to, automated features...

Are there any other good reasons? Am I just being a control freak?

Answer 1

A few that come to mind (there may be overlap with yours):

• A developer can tweak something until it works. This shouldn't be done in Production. If that developer is hit by a bus the next day, nobody will know the system. A documented and repeatable-by-someone-else deployment process helps ensure that such business knowledge is captured.
• As a developer, I don't want that kind of access. If something fails, it's far less likely that it's my fault. I'll come in and help, we're all on the same team after all, but I like to know that someone else had to review my work and agree with it. (The same is true of my DB delta scripts. I want a more qualified DBA whose sole responsibility is to the database to review my work. If all they do is run what I tell them when I tell them, then that's essentially no different than giving me direct access. It's just slower.)
• Developers often make quick fixes to simple things. We all know that it's often not as cut and dry as the developer thought, and that quick fix either didn't fix it or broke something else. No matter how small the change/fix, there should still be a QA process. (For some shops where uptime isn't so critical that QA process can actually be Production, but that's a rare exception. It shouldn't be that way, from a purist perspective, but as with anything it's a risk/reward ratio. If the risk is low (as in a Production failure doesn't incur much penalty if any at all) and the cost of QA is comparatively high, then it's fine.)
• Regulatory needs. PCI compliance, etc. often mandates clear separation of tasks between jobs. This is often misconstrued as "developers can't access production" and treated very black and white. But it does mean that developers should be able to access only what they need in order to do their job. If you don't need production data, and that data is sensitive, you shouldn't have it.

Answer 2

Because many developers are congenitally incapable of thinking they make mistakes - the same reason good dev groups have dedicated test teams.

"I'll just make this small config change in Prod, that won't break anything."

OOP developers should understand separation of responsibilities, I would have thought. You break it, you own it. Avoid the problem with a separate Ops team.

In some environments (e.g. finance) large sums of money (and sometimes the law) are also at risk from ill-advised or ill-intentioned changes in an uncontrolled Production environment.

In small teams, I can see a case for developers having production access, but that has to be controlled and auditable so that you ALWAYS know what is in Production. In that sense, it does not matter who pushes the deploy and rollback buttons, but that they exist and are the only way to change the Production environment.

I for one do not want that to be a large part of my job. You may find that your own devs agree once they see how much more time they can spend coding.

Answer 3

The main reason is because allowing a dev to deploy directly to production cuts out the QA process. Which introduces risk. Which management types don't like.

So another bullet point for you is massive increase in RISK.

Answer 4

Security - By having one gatekeeper (with a backup) only one person is accessing production data and servers. This means fewer access points.

Ease of management - You don't need to create as many accounts in your production environment to keep track of - or even worse, share one account among many. (assuming your prod environment is separated from your dev environment.

Practice makes perfect - one person who builds a routine and sticks to it has fewer chance for screw ups.

Answer 5

If there is a way to make a mistake it will eventually happen. Law of big numbers. It is unreasonable to put the burden on developers to be perfect, if you also want them to be productive.

• Change management
• Accountability
• QA
• One button builds / deployment
• Unit tests
• Code stability - suppose you push, right when someone else just checked in code?

Now, the amount of overhead / difficulty to change should be directly related to your up time requirements. Restated: the more costly downtime is, the more you should invest in preventing downtime.

Answer 6

By deploying directly to the production environment, there is a good chance that no QA was involved (i.e. nothing was tested).

Answer 7

Because there needs to be ONE person you can go to who knows what's deployed on the site. If every developer can deploy, you don't know who deployed what when somebody notices something wrong.

Answer 8

SOC-1 compliance may (unnecessarily) suggest or require that the developer be a separate person than the one deploying to production so that controls are in place to prevent malicious intent.