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