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?