Ask HN: how to push to a live site?

What's an example of a db change that "smart" people can do where Capistrano allows you to be less smart?

Deploying a long-running JavaScript application, like 280 Slides (and most Cappuccino apps), on one hand can be trivial (just copy the client resources to your webserver!), but also can be an interesting challenge. Namely keeping clients running an old version of the client-side code using the corresponding version of the server-side app. When you add in something like Gears for offline access it gets even tougher. There was a good presentation at Google IO that covered all these issues: http://sites.google.com/site/io/taking-large-scale-applicati...

We wrote a little custom code (we call it "bake") for deploying Cappuccino applications:

"bake": http://github.com/280north/cappuccino/tree/master/Tools/bake...

sample "bakefile": http://github.com/280north/cappuccino/tree/master/Tools/bake...

It pulls your code from git (but could easily do local files, scp, rsync, svn, etc), runs an optional build command (like "ant"), copies source paths to destination paths in a deployment directory, gzips the deployment directory, scp's the code to your server(s), ungzips it, and does a little magic...

Each version is placed in it's entirety in a uniquely named (unix timestamp) subdirectory. We could just redirect from "/" to "/1221268756/" (for example) but that's incredibly ugly, so we use the little known HTML tag to trick it. The index.html file in "/" is identical to the one in "/1221268756/" except it has a tag which tells the app all URLs are relative to "/1221268756/" instead of the default containing directory ("/").

And it actually seems to work really well. The big advantage of this is you can set your cache expire date arbitrarily far in the future, and your entire app will be cached until you change index.html to point to a new . 280 Slides, which is ~2.6MB uncompressed, loads on my computer in about 1.5 seconds if it's cached. The only problem with this approach is when you deploy, all clients will have to re-download every resource, even ones that don't change. A more granular system would be ideal, but significantly more complex.

I looked at Capistrano briefly but decided against it for some reason I can't remember. Perhaps that would have been better, but c'est la vie...

The capistrano approach is to collect a set of SQL sequences that will alter a sample server configuration from one configuration to another, with the purpose of repeating this on other servers such as your production server.

This is fine if you are paid by the hour.

The smarter way is to make changes that span codebase versions. You want to normalize a table so entities can have more than one address? Build an addresses table crosswalked to entity id and let the new code use it. Once you're happy with it you can drop some columns, but if you need to roll back, you haven't thrown anything away.

To me the difference is like that between hiring a hooker and charming a cheerleader. Either way you should make backups. ymmv.