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.
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:firstname.lastname@example.org [...] Disconnecting from superlists-staging.ottg.eu... done.
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:email@example.com
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 ...