Comments on: Dead Simple Rails Deployment

By: git monthly links: 2009-06 « git blog

git monthly links: 2009-06 « git blog — Sun, 07 Jun 2009 15:16:52 +0000

[...] Dead Simple Rails Deployment: Simple instructions to integrate git into Rails deployment scripts [...]

By: vitaly

vitaly — Thu, 04 Jun 2009 02:38:12 +0000

The production environment only caches code that is loaded.
So if you go to a controller that was not yet visited since the last restart *during* another”pull in progress” you can get an error.

Also consider static files. when you 'git pull' they do not change all at once, so you can have new html pointing to new images that are not yet there. etc.

in short: its not atomic

changing a symlink is.

well, almost ..:) you can still serve some old html and once the request comes for the accompanying images or css files they can already be served from the new release. but thats another story…

By: vitaly

vitaly — Wed, 03 Jun 2009 19:38:12 +0000

The production environment only caches code that is loaded.
So if you go to a controller that was not yet visited since the last restart *during* another”pull in progress” you can get an error.

Also consider static files. when you 'git pull' they do not change all at once, so you can have new html pointing to new images that are not yet there. etc.

in short: its not atomic

changing a symlink is.

well, almost ..:) you can still serve some old html and once the request comes for the accompanying images or css files they can already be served from the new release. but thats another story…

By: sant0sk1

sant0sk1 — Wed, 03 Jun 2009 10:44:02 +0000

Correct me if I'm wrong, but won't Passenger continue to serve the “old” data (in production mode) until it is restarted? I have never received Rails errors during a pull, but the apps I'm deploying aren't sustaining constant requests either.

By: Nils

Nils — Wed, 03 Jun 2009 05:50:03 +0000

With basic capistrano you would have a folder “releases” and a link “current” that links to the active realease within the release folder. So each time you deploy, a new release is created.

So it first pulls the release from the repo and when this is done, it refreshes the link to the new release. In that way you can easily switch between releases in a blink of an eye. Whereas this one would possibly create errors during the “pull”.

By: sant0sk1

sant0sk1 — Tue, 02 Jun 2009 23:08:12 +0000

Hi Vitaly-

Wondering if you could explain the “not atomic” piece and tell me how a traditional cap deploy solves this.

By: Aron Pilhofer

Aron Pilhofer — Tue, 02 Jun 2009 12:13:43 +0000

Wow. I couldn’t agree with Vitaly more… Can you explain why you would want to do this over, say, a traditional Capistrano deploy? Sorry to sounds like a debbie downer here, but I can’t think of a single upside to this strategy (and I can see plenty of downsides).

By: Integrum

Integrum — Mon, 01 Jun 2009 21:43:43 +0000

Rails deploy has come a long way from the pre 1.0 days.

By: Dead Simple Rails Deployment | blogt✪sk1 « Netcrema - creme de la social news via digg + delicious + stumpleupon + reddit

Mon, 01 Jun 2009 15:16:34 +0000

[...] Dead Simple Rails Deployment | blogt✪sk1blog.jerodsanto.net [...]

By: vitaly

vitaly — Mon, 01 Jun 2009 12:43:38 +0000

you are missing out on a many 'features' of a traditional capistrano/vlad deployment setup.
you can't easily revert to the previous version for example.
Also your deployment is NOT atomic. A Rails requests coming during the deployment can fail etc.