Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have a development model where every developer is responsible for deploying the program he/she is responsible for.

What we want to achieve is the following:

  1. for all developers to be able to deploy their applications to our production environment.
  2. have a good level of security
  3. have accountability on who did what.
  4. keep track of which application use what resources.

Currently we have written all our deployment scripts in fabric.

We have setup one account for each application. SSH-keys for that account are handed out to the developers responsible for deploying that application. This account is also used for running the application.

This achieves point 1, 4 and somewhat 2, but not 3. It also has the disadvantage that the server environment must be prepared since we don't want to provide root access to the application accounts (dependencies be installed by someone who is root, directories created).

How should we set up our deployment strategy in order to solve the above points, and have we missed some important goal for the strategy?

share|improve this question
up vote 1 down vote accepted

We have a similar strategy right now, and we are moving away from it, exactly because of your point 3) above.

Situation where a programmer is also responsible for releases looks really nice and simple, convenient and fast, but if you care about the stability of the system and the accountability, it quickly turns into a nightmare as it encourages quick hacks ("noone has to know, here, we fixed it quickly, like it never happened") and discourages proper documentation ("but everyone knows that"). Peer review? Fuhghehtaboutit ;)

All you will get with such a system is a perpetual fight between sysadmins and programmers, trust me, I was there not so long ago.

The only way to a stable and well documented system is that all the steps required for a release are properly documented, scripted and tested as often as possible, ideally the test systems should be automatically rebuilt every day. Once you are at that stage, anyone can run the scripts and do the release, and it should not be the one who wrote them, as he has no interest in reporting his own omissions.

share|improve this answer
Testify, brutha! Just make sure that there is a good, close working relationship between the developers the deployers; nothing's worse than an adversarial "us vs them" attitude in your deployment team. – womble Dec 8 '09 at 20:57
Admin has to understand that the programmer needs to ship, and the programmer has to understand that the admin is the first to blame when something doesn't work. If you don't have that understanding, it will always be "us vs them", no matter where you draw the line. Actually, a healthy dose of "us vs them" is unavoidable, like with any groups with conflicted interest. Splitting tasks actually stops it from getting out of hand, since it is more difficult to cover something up, look at it as something like the split between legislative and executive power ;) – Aleksandar Ivanisevic Dec 9 '09 at 9:53

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.