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=elspeth@superlists-staging.ottg.eu
[...]
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=elspeth@superlists.ottg.eu
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 ...

Get Test-Driven Development with Python, 2nd Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial