343 / 478
You may need to adapt the call to
subprocess
if you are using a custom username or
password: make it match the
fab
arguments you use when you run the automated de‐
ployment script.
By the time you read this book, Fabric may well have been fully por‐
ted to Python 3. If so, investigate using the Fabric context managers
to call Fabric functions directly inline with your code.
Finally, let’s look at the fabfile that defines those two commands we want to run server
side, to reset the database or set up the session:
functional_tests/fabfile.py.
from
fabric.api
import
env
,
run
def
_get_base_folder
(
host
):
return
'~/sites/'
+
host
def
_get_manage_dot_py
(
host
):
return
'{path}/virtualenv/bin/python {path}/source/manage.py'
.
format
(
path
=
_get_base_folder
(
host
)
)
def
reset_database
():
run
(
'{manage_py} flush --noinput'
.
format
(
manage_py
=
_get_manage_dot_py
(
env
.
host
)
))
def
create_session_on_server
(
):
session_key
=
run
(
'{manage_py} create_session {email}'
.
format
(
manage_py
=
_get_manage_dot_py
(
env
.
host
),
=
,
))
(
session_key
)
Does that make a reasonable amount of sense? We’ve got a function that can create a
session in the database. If we detect we’re running locally, we call it directly. If we’re
against the server, there’s a couple of hops: we use
subprocess
to get to Fabric via
fab
,
which lets us run a management command that calls that same function, on the server.
How about an ASCII-art illustration?
Locally:
MyListsTest
.create_pre_authenticated_session --> .management.commands.create_session
.create_pre_authenticated_session
Managing the Test Database on Staging
|
315