Chapter 14. 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:

$ cd deploy_tools
$ fab deploy:host=elspeth@superlists-staging.ottg.eu
Disconnecting from superlists-staging.ottg.eu... done.

Restart Gunicorn:

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

And run the tests against staging:

$ python3 manage.py test functional_tests --liveserver=superlists-staging.ottg.eu
OK

Live Deploy

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

$ fab deploy:host=elspeth@superlists.ottg.eu

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!
• Or, learn about data migrations. See Appendix D.

Wrap-Up: git tag the New Release

The last thing to do is to tag the release in our VCS—it’s important that we’re always able to keep track of what’s live:

$ git tag -f LIVE  # needs the -f because we are replacing the old tag
$ export TAG=`date +DEPLOYED-%F/%H%M`
$ git tag $TAG
$ git push -f origin LIVE $TAG

Note

Some people don’t like to use push -f and update an existing tag, and will instead some kind of version number to tag their releases. Use whatever works for you.

And on that note, we can wrap up Part II, and move on to the more exciting topics that comprise Part III. Can’t wait!