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 deploy:[email protected] [...] Disconnecting from staging.ottg.co.uk... done.
Restart Gunicorn:
elspeth@server:$ sudo systemctl restart gunicorn-staging.ottg.co.uk
And run the tests against staging:
$ STAGING_SERVER=staging.ottg.co.uk python manage.py test functional_tests OK
Live Deploy
Assuming all is well, we then run our deploy against live:
$ fab deploy:[email protected]
elspeth@server:$ sudo service gunicorn-superlists.ottg.co.uk 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 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.
|
Comments