How to track internal builds versus public builds?

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?

1 answer

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.

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,000 views 12 18
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot