Deploying a website should be an automated process.

A successful deploy script should:

  • Be a one command process
  • Have a fallback, or two, or three

A successful deploy script should never:

  • Allow simultaneous deploys
  • Leave your website in an unknown state after a failed deploy
  • Screw with your active users during an ongoing deploy

I looked at several options that made these promises but found them lacking for various reasons.

  • Tools like Capistrano and Mina require maintaining a separate development environment server-side1, which is not what I want to devote my time to (especially for a one-man team pushing a static site).
  • Git hooks are a much simpler, commonly used means of deploying sites. However, they require either committing post-build files (which I cannot recommend) or building the site server-side, which again requires a separate dev environment to maintain.2

Both of the above are relatively complex for what I wanted.

Enter rsync.

Out of the box, rsync is a great tool for efficiently sending files. As a deploy tool, however, I find it severely lacking. rsync cannot:

  • Provide a fallback to rollback to a different state server-side
  • Disallow simultaneous deploys
  • Prevent a broken site if there are interruptions in the deploy
  • Keep a partially built site unaccessible during deploy

Still, the usefulness and ubiquity of rsync cannot be ignored. Out of a growing need for something simple, quick, and efficient, I built rsync-deploy, which overcomes the aforementioned issues and meets the criteria set above.

rsync-deploy provides for an unlimited3 number of releases, while simultaneously limiting downtime due to failed or simultaneous deploys by providing a rollback feature.

Interested? To get started and for more information, see the project page.

  1. I develop on OS X but my server runs Ubuntu.

  2. This doesn’t mean, however, that you can’t call rsync-deploy after every git push.

  3. Limited by disk space, of course.