On Monday, September 10, 2012 12:33:31 PM UTC-4, Alex Morega wrote: > > Hello! > > Here's a progress update on "sarge", the deployment tool. Turns out I > was trying to address too many concerns at once, so I focussed on the > core problem: managing the lifecycle of a version of the application. > > http://mgax.github.com/sarge/ > > Sarge acts as container for "instances". An instance can be *created*, > then you install code and configure stuff; you can then *start* and > *stop* it, and when a new version is ready, *destroy* the old one. > There's also a *run* command to bring up a REPL or execute custom > commands. Some documentation exists: http://mgax.github.com/sarge/ > > Instances are independent, so you can run them simultaneously; this > allows for different instances for different jobs (web, worker, cron > script) and also things like rolling back a failed deployment or > zero-downtime upgrade. I'm using this, for a couple of projects, in > production, today. >
I am using a system that installs each revision of a web application into a new virtualenv in a directory hostname/random-number (uuid), echoes the random number into a file hostname/active and creates a symlink hostname/current -> random-number. A uwsgi config file hosname/config.ini links to the currently active environment by loading its name from the file 'active': [uwsgi] virtualenv = %d/@(%d/active) When you touch the .ini file, uwsgi reloads the application. Another file 'history' has all the old 'active' lines in order with timestamps so you can revert. uwsgi's many features allow background workers and so on.
_______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
