Ask HN: how do you stage/push your code?

After all 40,000 unit tests have passed, sync that version to prod with ssh tunnel. Rsync to new directory on all target machines in a rsync tree. Switch to new version by moving a symlink. Verify new version by looking at metrics -- if something is off, automatically switch back. Repeat up to 50 times a day ;-)

I have a simple setup for my pet projects: 1. Push code in github 2. Run fab deploy (fabric)

Fabric pull the code from github, puts it in the server and restarts the services (mongo, nginx) if needed.

I took some inspiration from newblur's fabfile.py: https://github.com/samuelclay/NewsBlur/blob/master/fabfile.p...

We've been using Beanstalk (http://www.beanstalkapp.com) for a few months now to collaborate more effectively, and thus far pretty impressed. Great system, and they've consistently added new features often.

We use capifony, a Symfony-tailored version of Capistrano.

Because our workflow utilized git flow, we do the majority of our work in feature branches, submit PRs, and then merge those to develop when TravisCI says it passes.

Once on develop, we "cap staging deploy" and run any final tests using Testacular, Selenium, or just by hand.

Most of the time, though, all we do is eyeball the code changes on develop, confirm tests pass in TravisCI, and do a release on master and then "cap production deploy".

Database migrations are handled automatically via Doctrine with each deployment with rollback support.

Sessions are pooled, and there haven't been any issues between releases. NewRelic is our primary indicator for a successful release.

Using this method, we deploy 6+ times a day, and haven't had the the time to automate it all yet :)

The shop I just moved to has the usual roll-your-own mess, but the shop I just left did it right: "yum update". Making RPMs isn't hard, and it ensures appropriate versions of all dependencies are there (even stuff like syslog-ng configs), and their tiny overworked sysadmin team didn't have to know or care which language they're implemented in, or whether there's anything smuggled onto each box behind their backs, or how to bring a freshly-imaged box into production. They ran a small script to fake a health check failure on a few servers at a time to do it without load, because they didn't want to reserve the footprint to run two versions of an app server in parallel on each box.

We have a staging server which is a carbon copy of the production server, and is auto-updated via post-commit hook (SVN). Everybody tests on that server until no more issues are found, and then it is pushed manually to production.

If the push involves db schema changes, we'll take the production offline for the duration of the push, showing a "Be back shortly" page.

At work, we have different workflows from rsync and ssh into the machine, running a build script to git pull. For my pet project, I work with git push to the production server. Works pretty well with git post-recieve hook and phing (ant for php) targets to update dependencies (through composer) and doing some health checks.

For unscatter.com its simply git pull then supervisorctl restart all, but that app isn't anything more than a some tornado app servers.

Automate every step possible.

google app engine takes care of everything for me

Deploy? I just edit it live, I mean what could go wrong?