buy the book ribbon

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.

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
Disconnecting from done.

Restart Gunicorn:

elspeth@server:$ sudo systemctl restart

And run the tests against staging:

$ python test functional_tests

Live Deploy

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

$ fab
elspeth@server:$ sudo service 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!

  • Or, learn about data migrations. See [data-migrations-appendix].

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
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 [part2], and move on to the more exciting topics that comprise [part3]. Can’t wait!


comments powered by Disqus