buy the book ribbon

Deploying Our New Code

Major update released for Selenium 3. If you started this book on or before Jan 30th 2017, be aware: chapters have been renumbered, so check this is the one you think it is, and have a look at the new [chapter_explicit_waits_1] for an indication of the changes you’ll need in your FTs. You should do a pip install --upgrade selenium too.

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

$ python manage.py test functional_tests --liveserver=superlists-staging.ottg.eu
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!

  • 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 push -f and update an existing tag, and will instead 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!

Comments