Distributing the Build Token with Hubot
At last week’s Talis Hackday I worked on “powering up” Lord Zeus, our Hubot plug-in to Hipchat. Hubot can be great fun and amazingly useful. We added scripts that were both.
One of the fun things we added was “Steve’s Rules of Acquisition”, a clone of the “Ferengi Rules of Acquisition” hubot script. Steve looks after all our expenses and purchase orders etc. at Talis. Now anytime anyone mentions anything vaguely financial, Steve jumps in with comments like:
Steve’s Rule of Acquisition #98: Every man has his price.
And Steve makes sure we find his lowest one!
We added more functional things too, one being a build token script.
A build token is a tool often used by development teams with a continuous integration build. I think it’s particularly useful for teams who want to progress towards continuous deployment, which is something we are talking about at Talis.
The idea is that only one person should be merging to trunk at any point in time. This means that two check-ins can not interfere with each other, causing the build to break. If the branch has been rebased against master and the tests run against it, there should be a high degree of confidence that the tests will pass. The final merge to master should go smoothly, giving the team an increasing level of confidence. A high level of confidence in your builds and tests is important before you trust the process enough to start continuous deployment.
In their book, “Agile Coaching“, Rachel Davies and Liz Sedley describe a build token in the following way.
For this [CI] to work, developers need to avoid treading on one another’s toes by attempting to integrate changes at the same time. Lots of teams use a build token, which can be any object that makes it obvious to the rest of the team that there’s an integration in progress. Teams have a bit of fun with this, which helps establish the CI process as a team ritual. We’ve seen teams use a rubber chicken, a moo cow, funny hats, and even a “Sword of Integration” made from index cards.
At Talis, we used to use an R2-D2 Mr Potato Head as a physical build token. However, we often have developers working remotely and we are increasingly using great collaboration tools like Hipchat. Being able to pass a build token remotely in the chat room seemed like a great idea.
The script we created is used in the following way.
Firstly you create a build token with a name matching it’s gitub repository by typing:
create build token for <projectname>The script replies:
You have created a build token for <projectname>You can see if anyone has picked up a build token with:
who has the build token for <projectname>To which the reply is either:
no one has the build token for <projectname>or maybe
<username> has the build token for <projectname>If someone already has the token, you can not take it. If no one has it, the command:
give me the build token for <projectname>will get you the token:
You have the build token for <projectname>!You put the build token down by typing:
release the build token for <projectname>As we are using a github plugin for Hipchat, the script also watches for commits to master.
If it sees a check-in, it will check to see if the committer has the token. If they do, it will just output:
Build token for <projectname> held by <username>However, if they don’t have the token, the script outputs:
Build token for <projectname> held by <anotheruser>
<username> DID not have permission to push to master of <projectname>.
You're heading the right way for a SMACKED BOTTOM!Of course, a build token can never enforce check-ins from only one developer at a time, but getting into the habit of using the tool can become part of the regular process, and a bit of fun too. As the build token is obtained via Hipchat, there is no excuse, even when your not in the office!
The full hubot script can be found here. Feel free to fork it and modify as you wish.
The blog post, “Build Token“ by Marcin Floryan, talks about the “broken” build token.
This is a token that the developer, who broke the build, takes so it’s visible which team member is responsible for fixing it. There is a great picture of a developer wearing a “Piggy Broke the Build” hat. This is their physical broken build token which he has to wear while he works to fix the build.
It occurred to me that, quite unintentionally, another hack day team also created a sort of broken build token.
I’ll leave it to that team to explain, but it involved cowboy hats and dubious facial hair!