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.
Out of the box,
rsync is a great tool for efficiently sending files. As a deploy tool, however, I find it severely lacking.
- 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.