Skip to content

Latest commit

 

History

History
130 lines (89 loc) · 3.58 KB

chapter_deploying_validation.asciidoc

File metadata and controls

130 lines (89 loc) · 3.58 KB
Raw

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.

Note
 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: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

Live Deploy

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

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
Note
 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 [part2], and move on to the more exciting topics that comprise [part3]. Can’t wait!

Deployment Procedure Review

We’ve done a couple of deploys now, so this is a good time for a little recap:

  • git push latest code

  • Deploy to staging and run functional tests against staging

  • Deploy to live

  • Tag the release

Deployment procedures evolve and get more complex as projects grow, and it’s an area that can grow hard to maintain, full of manual checks and procedures, if you’re not careful to keep things automated. There’s lots more to say about this, but it’s out of scope for this book. Do be sure to check out [appendix3], and have a read around on the topic of "continuous deployment."