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?
We were faced with the same dilemma. These are the two options I came up with.
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.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
As part of the Bitbucket product team I'm always interested in better understanding what kind of impact the use of our tools have on the way you work. In a recent study we conducted of software devel...
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!
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