Test-Driven Development with Python, 2nd Edition

Chapter 17. Deploying Our New Code

It’s time to deploy our brilliant new validation code to our live servers. This will be a chance to see our automated deploy scripts in action for the second time.

Note

At this point I want to say a huge thanks to Andrew Godwin and the whole Django team. Up until Django 1.7, I used to have a whole long section, entirely devoted to migrations. Migrations now “just work”, so I was able to drop it altogether. Thanks for all the great work, gang!

Staging Deploy

We start with the staging server:

$ git push
$ cd deploy_tools
$ fab deploy:host=[e-mail]
[...]
Disconnecting from superlists-staging.ottg.eu... done.

Restart Gunicorn:

elspeth@server:$ sudo systemctl restart gunicorn-superlists-staging.ottg.eu

And run the tests against staging:

$ STAGING_SERVER=superlists-staging.ottg.eu python manage.py test functional_tests
OK

Live Deploy

Assuming all is well, we then run our deploy against live:

$ fab deploy:host=[e-mail]

elspeth@server:$ sudo service gunicorn-superlists.ottg.eu restart

What to Do If You See a Database Error

Because our migrations introduce a new integrity constraint, you may find that it fails to apply because some existing data violates that constraint.

At this point you have two choices:

• Delete the database on the server and try again. After all, it’s only a toy project!

• Learn about data migrations. See Appendix D.

Wrap-Up: git tag the New Release

The last thing to do is to tag ...