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@example.com Disconnecting from superlists-staging.ottg.eu... done.
elspeth@server:$ sudo systemctl restart gunicorn-superlists-staging.ottg.eu
And run the tests against staging:
$ python manage.py test functional_tests --liveserver=superlists-staging.ottg.eu OK
Assuming all is well, we then run our deploy against live:
$ fab deploy:firstname.lastname@example.org
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!
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