2010/2/10 Jeff Forcier
<address@hidden>
Hi Nicolas,
On Wed, Feb 10, 2010 at 11:32 AM, Nicolas Steinmetz
<
address@hidden> wrote:
>
> For complex deployment, i may need to run extra commandes like run some
> scripts on one or serveral frontal servers or on a given db.
>
> I would like to avoid providing a new fabfile and was looking for taking
> into account some extra commands which would not be used for simple
> deployment. Any clue ?
what you're asking :)
Yep, of course :-)
For now, I have a commands.upd file which can contains commands to execute against some servers :
Ex :
remote front cd /var/www/myapp && php path/to/script.php -s <arg> : will execute the given command on all frontals
remote once front cd /var/www/myapp && php /path/to/script2.php -s <arg> -u <arg> : will execute the command on the first frontal only
remote db mysql -u<usser> -p<pass> -e "SQL Query" : will execute the query on all db servers
So my perl script actually :
* first push files on given servers (db or frontal according to a tree structure of the package)
* execute content from the commands.upd file
Most of the time, I do always the same thing in my commands.upd file : clear cache and update version in DB. But sometimes, I can have extra commands to pass (for ex, when I deploy a new town in my app, I have some jobs to run for initialising the meteo block or stations list or ...
This scripts are part of my app but I need to call them.
So I used to have so far most of the time the same commands.upd file that I "extend" for a given release with some required commands.
I would like to do the same without modifying the fabfile.py (to avoid that at next release there are some old scripts that would be run because they were forgotten).
Is it clear enough ?
> My other concern is that I would like that all actions are written to a log
> file so that I can audit if a deployment went well or not.
Your assumption that output currently only goes to stdout/stderr, is
correct -- however, there are plans to change this. See
http://code.fabfile.org/issues/show/57 :)
There's also nothing preventing you from logging your own messages
using the Python logging module, but that obviously doesn't cover the
actual stdout/stderr.
However, all calls to run() and sudo() return strings containing
stdout, and those strings also have a '.stderr' attribute containing
stderr -- so you could still rig something up to log both types of
output to a file.
Again, however, we have plans to make that a lot easier or automatic,
in the future.
Ok, thanks for the information - Will try to see what can I do with the current .stderr, before 1.0 lands.
Nicolas
--