Planet Argon Podcast, Episode 3: How We Manage Bugs
Earlier this week, we published Episode 3 of the Planet Argon Podcast. In this latest episode we responded to one of the ideas someone in the audience asked on this brainstormr, which was, “How do you manage bugs?”
We had a round table discussion about how we classify and prioritize bugs with our clients, ticketing systems, and other tools that we use to streamline this process.
Git commit-msg for Lighthouse tickets
A quick follow-up to a post from a few months ago on how our team has a naming convention for git branches when we’re working on Lighthouse tickets (read previous post).
I’ve just put together a quick git hook for commit-msg
, which will automatically amend the commit message with the current ticket number when you’re following the branch naming conventions described here.
Just toss this gist into .git/hooks/commit-msg
.
#!/bin/sh
#
# Will append the current Lighthouse ticket number to the commit message automatically
# when you use the LH_* branch naming convention.
#
# Drop into .git/hooks/commit-msg
# chmod +x .git/hooks/commit-msg
exec < /dev/tty
commit_message=$1
ref=$(git symbolic-ref HEAD 2> /dev/null) || return
branch=${ref#refs/heads/}
if [[ $branch =~ LH_(.*) ]]
then
lighthouse_ticket=${BASH_REMATCH[1]}
echo "What is the state of ticket #${lighthouse_ticket}? "
echo "(o)pen "
echo "(h)old"
echo "(r)esolved"
echo "Enter the current state for #${lighthouse_ticket}: (o)"
state="open"
read state_selection
case $state_selection in
"o" )
state="open"
;;
"h" )
state="hold"
;;
"r" )
state="resolved"
;;
esac
echo >&2 "[#${lighthouse_ticket} state:${state}]" >> "$1"
exit 0
fi
Then a quick example of how this works…
➜ bin git:(LH_9912 ♻ ) git ci -m "another test"
What is the state of this ticket?
(o)pen
(h)old
(r)esolved
Enter the current state: (o)
h
Created commit 1ed2713: another test
1 files changed, 3 insertions(+), 1 deletions(-)
Now to see this in action… (screenshot)
Then we’ll check out the git log really quick.
➜ bin git:(LH_9912) git log
commit 1ed271323c4a054fe56e76bddc9ac81d241a1032
Author: Robby Russell <robby@planetargon.com>
Date: Mon Feb 16 12:06:33 2009 -0800
another test
[#9912 state:hold]
Thanks to Andy for helping me figure out how to read user input during a git hook.
Lighthouse tickets and Git branching
We’re currently using Lighthouse as our ticketing system with clients for maintenance/bug requests. We’re also using Github for all of our major client projects. I’m sure that many of you take advantage of the Lighthouse service that Github allows you to use so that your commits can trigger actions on your tickets in Lighthouse.
If you’re not already, you might consider running (cheat ?):
cheat lighthouse
lighthouse:
- Commit comment [#213]
Adds message as comment to ticket #213
* tagged - adds tag to the ticket (does not replace)
* responsible - sets the user responsible for ticket (responsible:none to
clear)
* milestone - sets the milestone for ticket (milestone:none to clear)
* state - sets state (new, open, hold, resolved, invalid)
- Commit comment [#213 tagged:committed responsible:johan milestone:"Launch"
state:resolved]
With your commit messages, you can just pass in the ticket # and resolve your ticket without needing to interact with Lighthouse too much.
Okay, so one of the problems that I’ve had with this process is that I have had to constantly look back in my browser to see what the ticket # was that I was working on. So, I decided to start writing it down on a notepad as I was working through tickets so that I could look down at my desk, but this wasn’t terribly efficient either.
So, I decided to start leveraging the features of git to help me out. For each ticket that I work on, this is my process.
In Lighthouse, I decide which ticket I’m going to work on next. I then create a local branch using the ticket # in the name. Example: LH_1623
The workflow ends up looking like:
alphaclone git:(master): git checkout -b LH_1615
alphaclone git:(LH_1615):
<—I am using zsh and have it display the current local branch
I then work on this ticket. Since I’m working within the branch and my prompt reminds me what ticket # is being worked on, it makes it easy for me to add this into my commit message.
git commit -m "Fixed the do-whacky issue with data importing. [#1615 state:resolved]"
At some point, this will be ready to be merged back into master and pushed to Github.
git checkout master
git merge LH_1615
git push origin master
Github will take your commit message and pass it over to Lighthouse and your ticket will be marked as resolved automatically. This workflow has saved me a lot of time from navigating through Lighthouse and has also helped me stay focused on individual tickets throughout the day. Quite often, I’ll get interrupted by something non-development related and seeing the ticket # in my terminal helps get me back on task.
I’ve managed to encourage a few of the others at Planet Argon to adopt this ticket-based branch process as well so that when we need to collaborate on a ticket we publish the ticket branch to Github so that others can work on it as well. (happens a lot when a designer and developer need to work together on the same issue/feature)
Anyhow, just a quick little introduction to something simple that I did that has definitely helped me become a little more efficient throughout the day. Perhaps you have a better approach and/or tips for others that you’d like to share?
Related Posts
1Password and Fluid.app
I’ve been really happy with my purchase of 1Password so far. If you’re not familiar with it, I would really recommend their free-trial. I’ve been really impressed with how quickly it became reliant upon it. 1Password works across several browsers, imports existing passwords, and even has integration with your iPhone. However, over the past month, I’ve been wishing that it worked with my Fluid applications.
1Password 2.6.BETA-2 was released a few days ago one of the features added was integration with Fluid applications.
I’m glad to see that Agile Web Solutions was so quick to respond to the flurry of people requesting this.