345 / 478
OK
Destroying test database for alias 'default'...
Hooray!
I’ve shown one way of managing the test database, but you could
experiment with others—for example, if you were using MySQL or
Postgres, you could open up an SSH tunnel to the server, and use port
forwarding to talk to the database directly. You could then amend
settings.DATABASES
during FTs to talk to the tunnelled port.
Warning: Be Careful Not to Run Test Code Against the Live Server
We’re into dangerous territory, now that we have code that can directly affect a database
on the server. You want to be very, very careful that you don’t accidentally blow away
your production database by running FTs against the wrong host.
You might consider putting some safeguards in place at this point. For example, you
could put staging and production on different servers, and make it so they use different
keypairs for authentication, with different passphrases.
This is similar dangerous territory to running tests against clones of production data,
if you remember my little story about accidentally sending thousands of duplicate in‐
voices to clients. LFMF.
Baking In Our Logging Code
Before we finish, let’s “bake in” our logging code. It would be useful to keep our new
logging code in there, under source control, so that we can debug any future login
problems. They may indicate someone is up to no good, after all.
Let’s start by saving the Gunicorn config to our template file in
deploy_tools
:
deploy_tools/gunicorn-upstart.template.conf.
[
...
]
chdir /home/elspeth/sites/SITENAME/source
exec
../virtualenv/bin/gunicorn
\
--bind unix:/tmp/SITENAME.socket
\
--access-logfile ../access.log
\
--error-logfile ../error.log
\
superlists
.wsgi:applicationBaking In Our Logging Code
|
317