The meaning of "Fix Version" field in Jira, while working in agile, microservices and CI/CD processes

Question

When working on a monolith application in a "waterfall" process, a "Fix Version" field makes a lot of sense.

Say you have the "November 2020" planned release, you can add/plan dozens of relevant bugs and features to that release. Other bugs and features may be planned for the next release of "December 2020" and so on. So the "Fix version" field can have the same value for multiple issues/tickets.

Moving to a microservices architecture, the above process is significantly changed - Each microservice has its own release cycles that are completely independent of other MS. If a development team is responsible for 10 different MS, theoretically, each one of them can and should be released without any coupling to the others.

When we add on top of that a CI/CD process, things get even more volatile:

When each and every commit to the master results in a full automation tests suite and a potential (or de facto) version that can be deployed to staging/production, then every commit has its own "Fix Version".

Taking it to the Jira world (or any other issue tracking system) the meaning of that is that each and every ticket/issue may have its own "Fix Version". No more a common value that is shared across many tickets, but a disposable "Fix Version" value that will be used once.

Moreover, when an issue is created, you have no way to know in which build it will end up, as other tasks may finish before or after it.

In Jira, creating a "Fix Version" is manual, making the process of updating and ticket's "Fix Version" a tedious and error-prone work.

So my questions are:

• Are the above assumptions correct?
• Is there a meaning to a "Fix Version" field in an Agile + Microservices + CI/CD environment?
• How do you handle the "Fix version" challenge?
• How do you do it in Jira?

Answer 1

Are the above assumptions correct?

It sounds like you have a hidden assumption that is wrong: namely that the field has a fixed meaning and usage. The thing is: the basic concept of what a "version" or "release" is changes with the development process, and with that the meaning and usage of the field changes.

In a heavyweight process where you have a big, global release on a 6 month or even longer cycle, the field is used for planning, to make sure someone completes it in time for the release it should be in.

In an agile process, that usage is not practical and basically disappears. You don't fill the field at all when you create a ticket. But the field still has an important role: it documents when exactly the change became "live". This can be an important information in any process where you still have versions and releases (which bundle changes and are deployed on different environments) in any form. It may lose meaning in a hyper-continuous process where every committed change is automatically deployed to production.

How do you handle the "Fix version" challenge? How do you do it in Jira?

In my current project:

• the CI server automatically tags (in git) each automated master build with a monotonously increasing "build" version number.
• it also uploads the generated artifacts under that version to a Maven repository.
• when a ticket is merged to master, the "Fix version" field is set to "<componentname> next"
• A release is created by choosing a build version number and creating a new "release" tag with the same number (via a manually triggered CI job)
• When we create a release, we use JIRA's bulk change feature to change the version of each issue that currently has the "<componentname> next" version to "<componentname> <version>".
• Another manually triggered CI job can deploy any given release to a test, integration or production environment.

You could probably automate the JIRA stuff if you really wanted it.

Answer 2

The Fix Version field in Jira and related fields in similar tools are not only applicable to monolithic applications in a sequential or waterfall process.

Having CI/CD does not make this field useless. The value is greatly reduced if there is Continuous Deployment where every commit is deployed to production - at this point, tying the commit(s) to the issue is sufficient for traceability and doesn't need a Fix Version. If you have Continuous Integration and are building every commit or Continuous Delivery where you are making deployable entities available but not necessarily deploying them, you may still be identifying particular versions that are deployed to the production environment, in which case this field is useful.

Having a microservice architecture also does not make this field useless. Even if you have a true microservice architecture, you may version each service and/or the set of services as a system. Combined with an environment that is not practicing Continuous Deployment, it can be useful to identify the planned and/or actual version of either the service or the system (set of services) where the fix was made available to end-users.

As long as you have planned releases, it is possible to get meaning from the Fix Version field. The only time that I can see it not making sense is in a Continuous Deployment setting. However, just because you can get meaning from the Fix Version field doesn't mean that you have to use this functionality. Connecting Jira to your version control system (to relate commits to issues), build server (to relate builds to issues), and deployment system (to understand when commits are deployed) may be sufficient for your needs and you can safely ignore the Releases functionality in Jira and not use the Fix Version field.

Answer 3

So from the Jira Manual:

Fix version is the version where you plan on releasing a feature or bugfix to customers

Its used when your project doesn't have a backlog to effectively schedule the work.

If you are "using agile" you will have a backlog and most likely not use this field. Although you might still record the same information in the patch or release notes for a product.

I guess your other point is about an issue requiring changes to multiple software components, each having their own version and hence making it impossible to apply a single version number to an issue.

This is true even for monolith projects which could use multiple libraries/components. The trick is to say what product the issue is with. You can then say the issue is fixed in release version X of that product. Version X of the product will of course ensure the it's communicating with the updated versions of all the other microservices and hence guarantee that the issue is fixed for that version

Answer 4

I find that this field works quite nicely with the release report so I use it for very simple reporting to the business on progress. We operate an agile framework that suits our small team and are building out micro-frontends on microservices so a complex code base. By using this I am psuedo-"tagging" delivery across the various services that result in a business feature ready to go.