Many of JIRA’s users are software developers, and most of them also use version control software. (If you’re working on a software project and you’re not using version control, you should be. It’s question #1 on the Joel Software Test.)
We are heavy users of CVS and Subversion ourselves. Several years ago, when we wanted a better way to tie our version control changes into our JIRA issues, we wrote the JIRA Subversion Plugin. It auto-magically scans through your commit messages and looks for any issue keys in the message, and then associates issue and the commit in the Version Control Issue Tab.
But that’s really only useful if you remember to put the issue key into your commit message. After a couple of years, we’ve gotten pretty good at this, but everyone still forgets occassionally.
When we shipped JIRA 3.7, we added an new plugin to address this issue: the Commit Acceptance Plugin. It allows you to prevent developers from committing unless certain, simple conditions are met.
For starters, you can prevent any commits that don’t have an issue key. That’s a good way to make sure that you’re got a record of the reason behind every change to the codebase. We have some customers who work in very tight regulatory environments where this is particularly critical.
We also added two other criteria which you can check, if you like. Second, the issues in question must be in an unresolved state. And third, the issues in question must actually be assigned to the committer. (This last is a little tricker because your JIRA usernames must match your CVS user names for this check to pass.*)
Each of these criteria can be toggled individually, so you can select the restrictions that make sense for your team. It works with CVS and SVN right now, and if you’re interested in other VCS systems, please let us know. In the meantime, download the Commit Acceptance Plugin here.
* If you’re stuck on that problem, allow me to direct you to our brand new user-management and SSO tool, Crowd.