How and why to use an issue tracker and source control effectively combined
Every software development team should have an issue/bug-tracker (trac, jira, bugzilla, mantis, fogbugz, redmine, etc.) [1], and use source control (cvs, subversion, git, etc.) [2].
“I don’t care what you say. If you are developing code, even on a team of one, without an organized database listing all known bugs in the code, you are going to ship low quality code. Lots of programmers think they can hold the bug list in their heads. Nonsense. I can’t remember more than two or three bugs at a time, and the next morning, or in the rush of shipping, they are forgotten. You absolutely have to keep track of bugs formally.” [3]
The issue tracker allows you to create tasks with detailed descriptions and progress information, source control lets you add a commit message to give short information why you changed something and link it to the task.
Every good issue tracker will include tagged/linked commits to the related tasks.
If i have a ticket assigned, and commit a changeset to our repository, i will always tag it with the task id to establish a link (Check your source control connector for the syntax).
This allows not only followers of the timeline to instantly know why i did those changes, but they could also follow the link to the task and see any change related to it.
The other way around works equally: I can now check the ticket and see every related commit and its progress – even if it is not my task, i can get a feeling what the state is, what has been done, and who is working on it.
This adds transparency to my work and therefore the whole project.
My project manager now can see what i did when on which task. Using the functions of the particular issue tracker, he can see the progress of the subtask/task/milestone/project, who is doing what, and who has done what.
Leaving the commit message empty or not using the issue tracker makes your work a black box. You may have to explain, to many people, why or what for you did that commit. It will cost you (and your whole team) more time not to provide this information with the issue tracker/source control combination.
In short:
What to avoid:
- leave the commit message empty
- commit message not linked to a task
- not having created a task for your actual assignment
What to do:
+ Create a task for every task you are assigned to first
+ Link every commit through its message to the task (” * fix: caught HelloWorldException see ISSUE-1337″)
+ Always create tasks for everything (issues/bugs) you find (be sure to not duplicate issues, so use the search function first)
What you get for it:
+ You are saving your own and your team’s time
+ Transparency for yourself and the project manager(s)
+ Improved collaboration
+ Automatic documentation: what happened when to our code and why
Related links:
[1] Wikipedia: Comparison of issue tracking systems
[2] Wikipedia: Comparison of revision control software
[3] Joel Spolsky – Joel on Software – The Joel Test: 12 Steps to better Software
Related posts:
email me
follow me
2 Comments, Comment or Ping
Herbi
Great article. As I am currently looking for a PHP based issue tracker, what are your recommendations?
Apr 27th, 2009
Karsten Deubert
@Herbi:
The only full PHP issue tracker I have decent experience with is Mantis (http://www.mantisbt.org/). It is highly customizable and extendable (i.e. authentication plugins for your system), but the interface looks somewhat old, and therefore more techie-/developerfriendly then customer- or marketingfriendly
The last version i have used also didn’t have ajax features.
Fogbugz (http://www.fogcreek.com/FogBugz/) is available in PHP too, but i it is a) not free for commercial use (10 users = 1900$) and b) despite its good critics, i have never used it.
I’d like to know if you find any good PHP issue tracking alternative
Apr 27th, 2009
Reply to “How and why to use an issue tracker and source control effectively combined”