How to organize a web app deployment onto multiple servers at once?

Question

So - let's say I develop a PHP app which I develop in a vagrant box identical to production envrionment. So - as an end result I would have a *.tar.zip file with a code...

How would one organize a deployment into production environment where there are a lot of application servers? I mean - I'm confused how to push code into production synchronously all at once?

More information:

on server code is stored like this:

project
  +current_revision ->link to revisions/v[n]
  +revisions
    +v1
    +v2
    +v3
    ...
  +data

So when I have to deploy changes I usually run a deploy script that uploads updated tar onto server with ssh, untars into specific dir under revisions, symlinks it into current_revision and restart php-fpm.... This way I can rollback anytime just by symlinking to an older revision.

with multipe servers what bothers me is that not all boxes will be updated at once, ie. technically some glitches might be possible.

Answer 1

If you're looking for a "ready-to-go" answer, you'll need to provide some more info about your setup. For example, if you plan to use git for VCS, you could write a simple shell script that pulls the latest commit and rsync s with the server(s). Or if you're building on top of Symfony, capifony is a great tool. If your using AWS, there's a provider plugin written by the author of Vagrant that's super easy to use, and you can specify a regex for which machines to bring up or provision .

If instead you're looking for more of a "roadmap", then the considerations that you'll want to take are:

1. Make building of identical boxes in the remote and local environments as easy as possible, and try to make sure that your provisioning emphasizes idempotence .
2. Consider your versioning/release structure; what resources will rarely or never change? Include those in a setup function instead of a deploy function, and don't include them in your sync run.
3. Separate your development and system administration concerns; ie do not just package a vagrant box with a *.tar.gz and tie it through config.vm.box_url . The reason for this is that you'd have to repackage every production server with a new box every time you deploy, instead of just changing files on the server, or adding/removing some packages from the server.
4. Check out some config management tools like Chef and Puppet ; even if you don't end up using them, they'll give you an idea of how sysadmin professionals approach this problem.

Answer 2

Lots of ways. If starting from barebones (no cloud infrastructure), I'm a fan of the SVN branch hook. Have a SVN repo for your code. Set up a post-commit hook on it, which checks if anything in /branch/production/ has been changed.

If it has, let the post-commit hook fire all your automated roll-out procedure - and in this case, an easy way to do so is to let all your servers known* to svn export the branch. As simple as that!

(* that's the hard step)