Let’s add the fabfile to our repo:
$
git add deploy_tools/fabfile.py
$
git commit -m "Add a fabfile for automated deploys"
Git Tag the Release
One final bit of admin. In order to preserve a historical marker, we’ll use Git tags to
mark the state of the codebase that reflects what’s currently live on the server:
$
git tag LIVE
$
export TAG=`date +DEPLOYED-%F/%H%M`
# this generates a timestamp
$
echo $TAG
# should show "DEPLOYED-" and then the timestamp
$
git tag $TAG
$
git push origin LIVE $TAG
# pushes the tags up
Now it’s easy, at any time, to check what the difference is between our current codebase
and what’s live on the servers. This will come in useful in a few chapters, when we look
at database migrations. Have a look at the tag in the history:
$
git log --graph --oneline --decorate
Anyway, you now have a live website! Tell all your friends! Tell your mum, if no one else
is interested! And, in the next chapter, it’s back to coding again.
Further Reading
There’s no such thing as the One True Way in deployment, and I’m no grizzled expert
in any case. I’ve tried to set you off on a reasonably sane path, but there’s plenty of things
you could do differently, and lots, lots more to learn besides. Here are some resources
I used for inspiration:
•
Solid Python Deployments for Everybodyby Hynek Schlawack
•
Git-based fabric deployments are awesomeby Dan Bravender
• The deployment chapter of
Two Scoops of Djangoby Dan Greenfield and Audrey
Roy
•
The 12-factor Appby the Heroku team
For some ideas on how you might go about automating the provisioning step, and an
alternative to Fabric called Ansible, go check out
Appendix C.
166
|
Chapter 9: Automating Deployment with Fabric