Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 16:59:00 GMT)

Planet Argon Podcast, Episode 3: How We Manage Bugs

Posted by Wed, 11 Nov 2009 16:46:00 GMT

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.

You can listen to this on iTunes or online.

Git commit-msg for Lighthouse tickets

Posted by Mon, 16 Feb 2009 18:51:00 GMT

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)

git message hook

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

Posted by Thu, 11 Dec 2008 16:36:00 GMT

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

Posted by Fri, 04 Apr 2008 13:22:00 GMT

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.

Fluid and 1password
Signing into Lighthouse with 1Password

I’m glad to see that Agile Web Solutions was so quick to respond to the flurry of people requesting this.

Related Post(s)