Tag Archives: fabric

Deploying “The Whispering Thing”

After the shenanigans of getting that site pushing, building, testing, and deploying from git to Jenkins to DreamHost, I was able to get deployment for “The Whispering Thing” in place while I slept.

Seriously, Jira says I clocked 90 minutes, and that’s with versioning (details below) and using a new service–DreamObjects.

Twine (what “The Whispering Thing” is written in) produces a single HTML file with all CSS (Cascading Style Sheets) and JS right in the file. A dream for deployment–just put it somewhere.

DreamObjects is–from my perspective–like S3, but doesn’t require me to start the clock ticking on Future Proof Games’ free tier status with Amazon Web Services. DreamObjects is API-compliant with S3, so I can use boto and just change the host name to point to Dreamhost.

I use fabric for deployment scripts, and I wanted this to run through Jenkins so that pushes to the “develop” branch push to a staging location, and pushes with tags to the “master” branch release to prod. This is in alignment with git flow.

The tagging, though–ugh. I must be doing this wrong. The shell command git describe --abbrev=0 --tags --exact-match will get a tag that is on the current commit only. Future commits after that one won’t return the tag. I want that strictness to ensure that only intentionally versioned commits to master go live.

But if there isn’t a tag, the exit code on that command is some error code, which makes fabric stop the deployment and Jenkins fail the build. If you use “warn_only” to prevent that failure, you still have to check for that failure and set the version to something defaulty.

It’s awkward. The function looks like:

def set_version():
  with settings(warn_only=True):
    env.current_version = local('git describe --abbrev=0 --tags --exact-match', capture=True)
  if env.current_version.failed: #fabric creates "succeeded" and "failed"
    env.current_version = 'staging'

This is slightly cleaner than what’s currently in my FPG.com deployment scripts, but it’s ugly and not robust.

Also, pushing tags is a pain in the ass. To get Jenkins to properly have both tag and branch when it runs, you have to do the following on the master branch:

  git merge --no-ff release-1.1.1
  git tag -a 1.1.1
  git push --tags
  git push

Jenkins won’t build just for a pushed tag change (grr!), so the tag has to be out before the commit it’s attached to. And the current version of git doesn’t have a way to push both commits and tags simultaneously. It feels awkward and clunky.

Complaints about stank versioning aside, deployment is fast, smooth, and easy. Twenty seconds of Jenkins’ time, including setting up virtualenv with boto.

Then, less than 48 hours after I get deployments working,

Deployment Automation with Fabric: Bee’s Knees

One immensely valuable thing I learned at Skookum was the value of automated deployments. I worked with a gent who took the time to work up Capistrano scripts for each staging and production environment of the whale of a project I worked with him on.

I appreciated it during development, but I didn’t appreciate it until we were deploying single tweaks out to production on Amazon EC2 in rapid cycles. I haven’t worked with EC2 since then (second half of 2009), but let me tell you, deployments were for the birds.

With his scripts though: run the script, enter your SSH or git password(s) a few times, and you have an automated deployment that runs for each person on the team, despite all our separate setups (Mac, Linux, cygwin, etc.).

It sounds trivial and obvious, but how many deployments did I do by hand, or try (poorly) to document for someone else, or forget how to do before that really sunk in?

Continue reading Deployment Automation with Fabric: Bee’s Knees