Search code examples
deploymentdvcs

What's wrong with running a live site from a DVCS clone?

I see insinuations here and there that it's bad to run a live deployment directly off a DVCS clone, and better to export a clean tree or tarball and deploy that. It seems to me that running directly from a DVCS clone has several advantages:

  1. No need to transport the entire codebase on every deployment.
  2. Trivial to update code to any desired version.
  3. Trivial to rollback to previous version if deployment goes badly.

And I can't really see any disadvantages. The presence of the repo files (in my case, a single .hg/ directory) causes no problems.

Is there really any good reason not to run a live deployment off a DVCS clone?

Solution

  • This is what I do. The only "disadvantage" is you can't really version-control the databases or site-generated content (user uploads). It's not a disadvantage at all though because there's no alternative. Just as usual, you need a backup script to copy all that content out.

    This isn't an answer but rather an explanation of modern webapp directory layouts. A very simple Python webapp might look something like this:

    webapp/
  .hg/
  webroot/
  handler.py

    You would set it up so that the webserver only serves static content from webroot/ and if the path doesn't exist in there it asks python (in this case) for that page.

    Since none of the server-side source-code is within webroot/, it cannot be served (unless you have a python directive ordering it to serve source code). The same applies to the .hg/ directory.

    Note: SVN (< 1.7) and CVS are exceptions as they spray their .svn directories over every subdirectory. In this case that would include webroot/ so, yes, you'd need to make sure you weren't serving hidden files but this is commonly the case anyway.