views:

111

answers:

2

I would like to seamlessly upgrade my Rails app:

Meaning:

  1. If no migrations need to run I would like to transparently upgrade the code and have no requests go 404 during the deployment.
  2. This is hard I would like to have some process that can upgrade the database seamlessly and during that time just hold back on the web requests (queue them in the pipe) when the db update is done, allow stuff through. (I only need this to work for short migrations - like 5-10 second migrations).

How would you go about achieving this?

A: 

You should have a look at Capistrano.

Simone Carletti
Are you saying that simply running a couple of *ln -s* commands is all you need to get a seamless deploy going? I use capistrano, its 404 central
Sam Saffron
Capistrano offers a maintenance mode you can enable on deploy. Also, you can configure Capistrano in order to return the appropriate 503 status code on deploy.
Simone Carletti
I dont want any 503s I want 200s all the way through
Sam Saffron
No problem at all. The default Capistrano maintenance mode sets 200. Also, Capistrano deploys a new release in a parallel folder so your users continue to browse the old version until the symlink is updated and the new release fully available.
Simone Carletti
+2  A: 

Upgrading just code

If you're just upgrading the application code passenger should allow you to do that without skipping a beat. However it's not going to protect you if an upgrade goes wrong, for that you should consider having two or more load balanced web servers which you can upgrade individually round robin.

Upgrading the database

As a user I'd rather see a "down for maintenance" page than my browser spinning for 10 seconds. If you explain that the downtime will be an order of a few seconds and set the page to auto-refresh.

If you're adamant about having no downtime while doing db upgrades you have a few options:

  1. You can refactor your database in such a way that you keep the old schema valid. This means you can keep two version of your app running against the same database and over time migrate to the new schema. There's a lot of 'database refactoring' articles, with most of them advocating using triggers/etc... to achieve the desired result. I personally think it's a lot of effort for not a lot of reward.

  2. Depending on your application you might be heavily biased towards reads over writes, which means you can show a 'maintenance' page for uncached data while you upgrade the database (this is how facebook does their database upgrades). This is even more effective if lots of your data is stored in memcached or redis. Alternatively you can switch to a readonly database slave and disable any write actions.

I hope this helps!

jonnii