3 ms·
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
by mnutt 16y ago
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 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/ http://unicorn.bogomips.org/
A forking ruby http server
- scotth 16y agoDo you also have timestamped databases? How do you deal with schema changes between versions?
- deleted 16y ago[deleted]
- mnutt 16y agoMost 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.