Issue management guidelines

JIRA

JIRA is a tool developed by Atlassian company. The core functionality of JIRA is related to issue tracking. Other features combined with numerous add-ons extend the possibilities of JIRA so it can be used for example as a:

• Project management tool
• Source code review tool
• Workflow tool
• Task board
• Test planner
• Source of software development metrics
• Release notes generator JIRA reveals all its features when it is used regularly and consequently (each developer follows the agreed workflow).

General guidelines

Issues related to new features should be created by a person responsible for development of given module and then assigned to particular developers. All problems encountered in the software should be reported as bugs in the issue tracker, no matter how small they seem. Bug reporter should comply to the following simple principles:

• Be precise;
• Be clear – explain the bug, so others can reproduce it. Provide all additional materials (i.e. database dumps) if it is necessary to reproduce given problem;
• One bug per report;
• No bug is too trivial to report – small bugs may hide bigger bugs.

Bug report should be assigned to a person who is responsible for the module which most likely is causing the given problem. Teams can delegate to one person the responsibility of the bug assignment.

When an issue is solved, the developer should also resolve the given issue in the tracking system. In JIRA one of the steps during issue resolution includes the provision of the testing procedure.

The given testing procedure or unit test should verify that the original bugs were fixed.

Developers should provide a reference to unit test or document describing the testing scenario (this should be stored in the project source code repository). This information will be the base to verify whether implemented features works properly during the preparation of release.

Finally, testers (i.e, different users from the developer(s) who did the implementation of an issue) should work through the JIRA issues for the release marked as Resolved. These are tested to confirm they are solved, and if fixed marked as Closed, otherwise re-opened.

Basic JIRA workflow

Using JIRA with FishEye

JIRA can be integrated with other useful tools like FishEye and Crucible. The rules governing this link are straightforward: Before starting any code changes you must have a JIRA issue created, corresponding to the changes that you have to make.

• Each JIRA issue for the project will have a unique id with the following syntax: PROJECT_IDENTIFIER-. This issue id MUST be included in the message/comment that you provide while committing to the repository. For example it can look like this:
• PROJECT_IDENTIFIER-123 - Final fix for the NullPointerException
• The issue id can be anywhere in the commit message, but it has to be separated with some characters, like space, from other message words.
• Such issue ids are automatically detected and utilised for linking between JIRA and Fisheye+Crucible.
• Because of the nature of this linking, it is not recommended to commit several different files/changes with one message containing several issue ids. So for example if you have three files named A, B and C, and you have worked on PROJECT_IDENTIFIER-1 in file A, on PROJECT_IDENTIFIER-2 in file B and on PROJECT_IDENTIFIER-3 in file C, then instead of committing all three files at once with a general message like:
• PROJECT_IDENTIFIER-1 PROJECT_IDENTIFIER-2 PROJECT_IDENTIFIER-3 - Now all this should work
• You should do three separate commits having more meaningful messages and only the proper issues ids. Of course if there will be some very closely related issues, then such separation may not be possible.