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:[email protected] [...] Disconnecting from superlists-staging.ottg.eu... done.
[email protected]:$ 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 protected]
[email protected]:$ 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 [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