Comment by sajidnizami | Hacker News Reader

Comment by sajidnizami | Hacker News Reader

Interesting stuff. I've been doing something similar with my sites for over two years now. Its more of an workflow than just a system really.

1. A staging server where the new changes are first tested 2. Production server which gets the updated and verified working code 3. In case of any trouble (which hasn't happened in quite sometime btw) the old solution backup is kept with a date and time and can be reverted just as easily as code is updated from staging server

You can actually use a load balancer to roll over the servers too while deployment and it takes the factor of downtime away to an extent. But this can't be done with a powershell or any shell script and a network admin has to be present at the time of deployment which makes it difficult.

I have had next to none downtime on my servers. Last I remember my sites going down was during a DNS shuffle well over 6 months ago, never because of some developer or sys admin screw up. Yes I do have more than ten deployments on a single site in a day.

We use Capistrano[0] to automate releases in the same manner. It keeps multiple copies of the site in timestamped directories and has a 'current' symlink which it just points to the latest. If you ever need to roll back, just point the symlink to a different timestamp.

Similarly, for our rails apps we use unicorn[1] to do no-downtime deploys. When we roll out new code, unicorn brings up new workers while the old workers are still running. The old workers are not sent any new requests, and once they finish their in-progress requests, they are killed.

[0] https://github.com/capistrano/capistrano/wiki While most of the docs talk about rails, capistrano isn't ruby-specific. We use it to deploy node.js apps as well. [1] http://unicorn.bogomips.org/ A forking ruby http server

Do you also have timestamped databases? How do you deal with schema changes between versions?

Most of our deploys don't have a schema change, and often when adding tables or columns the migration can be run before the new code is deployed. When dropping or renaming columns you'd usually need to first deploy code that is able to gracefully handle the migration.

However, sometimes it's not worth the extra code complexity and we just take the site down and migrate.

Reply on news.ycombinator.com