Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

When deploying a Python web application what are the pros and cons of using the following methods to deploy the application:

  1. Use the VCS to make a checkout on the server
  2. Use FTP/SSH/rsync to transfer a copy of a local checkout
  3. Create a proper package and transfer that to the server

(Note 1 - I currently use method 1. However my repository may contain many other project related artefacts as well as the actual application, so this seems to work best with SVN where I can check out only the relevant folder - with the DVCS all or nothing approach this looks like not such a good idea). (Note 2 - I am currently switching to DVCS)

share|improve this question

I go with 4: Have a clone on the server, and then make an archive of that and deploy that (as demonstrated in my git push deployment tool, Giddyup).

The problems with the other methods, in my experience, are:

  1. VCS checkout: Your checkout includes version control metadata, which (if you neglect to properly protect it with webserver configuration) can expose your source code to attackers or the terminally curious.
  2. FTP/rsync: Nothing particularly wrong with this method, although a naive implementation (FTP, or rsync to an empty directory) takes a lot more time and bandwidth to transfer everything. Also has an unpleasant habit of deploying stuff that wasn't checked in (always an adventure to diagnose that one), because it was just lying around your local working copy. (You can work around this, but they mostly boil down to "make a local checkout", which devolves into (1).
  3. Whilst I am a packaging nut, I've found that packaging most(TM) webapps is overkill -- they're data, rather than program (from the point of view of the server), so wrapping it in a package ends up being unnecessary (assuming you've got a good deployment mechanism involving logging your deployments, exhaustively revision controlling them, and so on).
share|improve this answer
Re 1. Yes of course you need to hide .git/.svn in your web server, this is fairly trivial in most setups although can be forgotten (geek game => add '.svn' to any url). – RobinP Aug 1 '11 at 13:53
Re 2. If using rsync you wouldn't normally go to an empty folder all the time, that's the point, but you're right that you would need to export to a clean folder first; however this would be locally, so is not quite the same as 1. – RobinP Aug 1 '11 at 13:55
Re 3. Agree with you on that one – RobinP Aug 1 '11 at 13:56
Re 4. Giddyup sounds interesting, but sounds rather similar to Fabric, of which I am already a fan. But having a clone on the server still doesn't really answer Note 1, i.e. you still have stuff on the server that really has no business being there. – RobinP Aug 1 '11 at 13:58
"can be forgotten" leads to "has been forgotten" leads to pwned. So don't do that. "You wouldn't normally" of course, but "a naive implementation" isn't "normal", just "all too common". Why doesn't a clone have any place on a server? It seems like a perfect place for it -- just not in your webroot. And if you think Giddyup is like Fabric, then you're deeply confused about how one or the other of them works. – womble Aug 1 '11 at 20:06

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.