Caffeine

As with any web company, we’re constantly honing our development and deployment process. Recently, we moved to Lighthouse – we were already using Git, but the convergence of the two has finally crystallized our workflow into something that, we feel, works really nicely.

Branch/Ticket conventions

Our system works largely based on convention. In order to facilitate a smoother workflow, we designate one person at a time to be the “Buildmaster.” This person is responsible for preparing hotfix branches, deploying to our staging environment, and communicating with the other developers if there is an issue with one of their branches.

Here is the lifecycle of a bug at Onehub:

1. Somebody finds a bug, or wants to request a feature. They open up a Lighthouse ticket and assign it to a developer.
2. The developer starts working on the ticket. They create a topic branch off master which is named starting with the ticket number, plus some additional descriptive information, ie. 24-fix-user-links
3. Once the developer is satisfied with the work they’ve done, they’ve written adequate specs, and haven’t broken any existing functionality, they mark the Lighthouse ticket with a custom state we’ve created called “ready”. This alerts the Buildmaster that the branch is ready to be staged.
4. The Buildmaster creates a hotfix branch into which he merges the developer’s changes. This hotfix branch is then deployed to the staging server and tested. Once a branch is deployed, the Buildmaster changes the ticket status from “ready” to “staged”
5. Once the developer sees that their fix has been staged, they test it once again to ensure that it’s fixed on the staging server. If this looks good, they change the ticket state to “verified.”

At the end of the day, after the Buildmaster has ensured that all the tickets are verified, he merges the hotfix branch back into master, and deploys to production.

This works great, but sometimes there are features which take a little longer to develop, which we would still like to stage and test remotely. To accommodate this, we have a separate experimental staging server, where we can deploy these branches without the intention of imminently hotfixing them into production. We manage the build process for these tickets in much the same way, however we use Lighthouse to tag these tickets “experimental”.

Lighthouse ticket bins make this all very simple to manage. We have the following bins:

Now, from the developer’s perspective, all of this is rather easy to manage. Github already has support for managing Lighthouse tickets directly in commit messages, and Lighthouse sends emails when your own tickets are updated. However, it’s a bit more work for the Buildmaster- having to constantly check for changes to ticket bin counts can become tiresome, and it’s easy to forget when you’re entrenched in your own code. Fortunately, we’ve developed a handy little gem, called Buildmeister, which alleviates a bit of this manual work.

Go check it out at: onehub.com/developer

Once you’ve done the initial setup, start the notifier in your shell…

$ buildmeister notify

… and you’ll get a growl notification informing you how many tickets are in your watched bins. You can dismiss the notification, and it’ll update only when the ticket counts change. That way, you can get back to coding, but spring into action at a moment’s notice when somebody has a fix to stage. It’s the best of both worlds.

Cleaning up your mess

Git branches are a great thing, but before long, you end up with way too many of them, both locally and on the remote repository. It’s easy to let the number of branches get out of hand, especially since there’s no good way to walk through your list of branches, triage their continued relevance, and delete them if necessary. Until now, that is.

Buildmeister comes with another useful script called Git Cleanup. You can run it on local or remote repositories, and it will step through each of your branches, asking if you want to keep or delete it. There are a couple of really nice touches, though. First, it displays how long it’s been since the branch has been updated. Second, if the branch has been idiomatically named as described above, then it will automagically display the Lighthouse ticket status, further informing your decision.

$ git_cleanup local
> 2086-notify-permissions-fix (updated 3 days ago)
> Lighthouse Info:
> Ticket #2086 state - new

> keep [return], delete [d]:

We’d love to hear suggestions on how we could improve these tools, so if you’ve got any ideas or feedback, feel free to comment or drop us an email.