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!
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
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
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.
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 use 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!