Best Practice: JIRA, source code, and build integrations

1. When a developer is closing a JIRA ticket, the checkin to the Git should be mentioned.

QA would typically like to know which build the fix is in.  However, it is hard to get the build number yet when the build has not yet done.  So the checkin number should be mentioned in the JIRA, and later we can use the checkin to locate the build.

Some systems can update the JIRA ticket automatically from the source control system or even from the build tool.  It will be ideal.

2. When a developer is checked in the codes, the JIRA tickets that are being fixed should be mentioned as part of the checkin.

It justifies the changes to code.  In a stable system, every change to the code should have a ticket.

3. A build is a collection of changes and a list of fixes should be available for each build

The impact from a build to a system needs to be known, when the system is stable, we know what change will be applied.

QA need to know which bugs should be verified or which features can be tested.  If a bug fix or a feature is not available, the QA won't need to spend time on it.

Build and build schedule affects the QA test schedule.

The changes are reflected in source code changes.  Some of the build tools can show the JIRA ticket numbers that are mentioned in the checkin comment and generate the list of changes in JIRA.