How to track internal builds versus public builds?

[Robert Dailey]

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). We also still want to be able to track changelogs between customer releases (we already track these versions in JIRA).

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?

[Benjamin Lipman]

We were faced with the same dilemma. These are the two options I came up with.

1. Just Version, NO Builds. 
   1. Don't add versions you don't intend to release. 
   2. Builds are not versions. 
   3. Don't include build information anywhere in the version name. (eg. 1.0.13243 becomes 1.0)
   4. add new fields or use comments to communicate any testing on a specific build.
2. Merge Internals
   1. Make internal versions from builds or planned internal releases (eg 1.0-beta2, sprint 23)
   2. Aggressively delete internal versions which jira will prompt for moving issues to another version.
   3. Note that fields will change when you merge/delete so you might want to again make additional fields for tracking build info.

We ended up choosing 1.  If your pipeline has the build number tied up in the version name and you can't control what gets released, you may want to use option 2.