Tracking internal builds versus public builds

Question

At our office, we use JIRA to track issues reported by our QA teams. We also have Bamboo which builds each time we commit to our Git (Stash) repository. QA picks a build from Bamboo and they work with that build for about a week. Once all of the issues they filed on that build are resolved, they pick another build and regress/smoke test again until they find a fully passing build (i.e. no issues reported).

The problem is they want to be able to track changelogs between the internal builds they choose (the build they pick from bamboo) and our public release version which has been planned.

So for example, if our "public release" version is 1.0, then our internal builds will be 1.0.1, 1.0.2, and so on. They might pick a build in Bamboo 50 builds later and mark that as the public release. So even though we marketed our product to be version 1.0, the actual version is 1.0.50 (50 being our internal build number).

They want to track changelogs between each internal round of testing and also track changelogs on the public release as a whole. So let's say they picked the following builds for their weekly rounds of testing:

1.0.1 -> 1.0.25 -> 1.0.50

They want to see which JIRA issues are resolved between 1.0.1 and 1.0.25, and likewise between 1.0.25 and 1.0.50. The only solution I can think of for this problem is to add 4 versions to our project in JIRA:

1.0
1.0.1
1.0.25
1.0.50

1.0 would be unreleased, and each time QA adds an internal build, it will be immediately marked as released. This will allow them to assign 2 affects or fix versions per issue: 1.0 and 1.0.25 (or whatever internal build it was reported on)

This seems clunky, I don't like the idea of adding versions in JIRA for internal builds. It seems like JIRA should only care about public releases (i.e. 1.0 in this case). Is there a better way to handle this type of continuous integration / continuous delivery?

Answer 1

Presumably, build 1.0.50 happened on a certain date, and any Jira tickets resolved before that date represent fixes or features contained in that build (if not, the "resolved" status is probably being misused). So it should be possible to accomplish this by making custom filters that list all tickets resolved between certain dates (and affecting v1.0). That way Jira doesn't have to know about build numbers, and the testers can simply use the "QA Week 2" filter.

Answer 2

Issues can be filtered by type, fixed version, affected version, status etc in JIRA and one can save the filter, share it with others and attach it to a dashboard for a quick overview.

All the information you need is already there in Jira, if its not then QA probably shouldn't be concerned about it. Lets assume your QA team is testing one build at a time from Dev branch CI builds and run through a scenario.

• Issue is found and logged by QA in JIRA along with the Affected build version under test
• Issue goes through the triage, it gets assigned to a Developer
• Developer reproduces the issue, starts working on it and once the fix has been tested locally, it is pushed to the dev branch, and the CI build passes.
• Developers puts the status of the Issue to FIXED and sets the fix version to be same as the build version in CI (Bamboo) !Important
• Developer assigns the issue back to QA
• QA uses JIRA filters to filter all the issues that have been fixed and assigned to them and potentially also checks whether the fix version is same as what they are testing at the moment and or its a number higher, in both cases they can start retesting the issue. If the issue passes their test then the ticket is set to CLOSED.
• Once a build version has been reached which is ready for production. it takes QA half a minute to create a Jira filter which filters the changes that are going into the build.

In either way, QA has all the tooling they need within Jira, if its not then i'd suggest to review the current process of tracking and align it to the recommendations by Atlassian on their wiki.