How to use Fix Versions?

[William Hoffmann]

Hi, I am managing a small team at a software company.

Here is our typical workflow:

-issue is assigned to programmer

-programmer works on issue

-when programmer has finished implementing the work in the software development editor, they assign the issue to QA

-every 2 weeks, a new build is made of the app

-QA tests issues assigned to them by testing work in the newly released build

-QA either resolves the issue if it is fixed, or reassigns to the programmer if it is not

We make a new build every couple weeks, which is mostly used internally. We have a more major release every few months (although we may be trying to make more frequent public releases in the future)

I am trying to properly integrate the Fix Version field so it can be most useful for our workflow, and so I can get meaningful info from JIRA's reports.

Currently, we use Fix Version to apply to an overarching project, over the course of months. However, I am wondering if instead we should use Fix Version to apply to each build we make.

I am not sure how Fix Version. Should it apply to the more frequent build version, even though that is more for internal use? Or should it apply to the more broad project release, which is a more significant goal, but much more infrequent?

Additionally, I am unsure how "releasing a version" (in the JIRA sense) meshes with our workflow. The most logical thing to me is to release a version when the build is made--however, at that point, zero issues have been completed, since they all still have to be resolved by QA. It isn't until after the build is made that we call any issues done. Furthermore, there will be builds made that will NOT be released to the public, since they will be found to be too buggy by QA.

Any advice on how I can get JIRA versions to work for us is appreciated.

[Nikki Zavadska _Appfire_]

Hi @William Hoffmann 

in one company I worked for we had similar release process. The release cycles were 6 weeks and during this 6 weeks there were 5 Release candidate builds.

Each week developers were releasing release candidate to our test environments for QAs to test.

In Jira we used Releases for our major release to production but also for Release candidates that weren't deployed to production, only to test.

Naming convention for Jira Releases was something like this:

Let's say we're working on version 36

RC-36.1

RC-36.2

RC-36.3

RC-36.4

RC-36.5

When RC-36.5 was regression tested and approved for production then that was our final release candidate and we deployed it to prod.

If there were any bugs we created new RC-36.6 and delivered bug fixes in this release, tested, if code passed QA we deployed that to production.

Issues were linked to each RC if they were fixed and delivered in that release so QAs could easily see what they should test.

We didn't mark RCs as released till we deployed to production because going through the test environment was one of our stages in the release process....So we marked all of RCs as released once we released final one to prod.

But this will more depend on what kind of reports are you expecting from this proccess and maybe you'll find usefull to release each candidate after it's deployed to test.

For us main thing was to be able to see what issues were delivered in what RC and then properly track their progress through testing (by moving issue status from Test to Done).