Issues with multiple product-version relations?

[janpio]

I am trying to find out if JIRA can support the following situation:

• We develop software
• It is a 'platform' used to build several 'products'
• There is a 'library', that is used in all products
• Each product implements lots of interfaces from the library (in different ways)
• The frontend is different (modified) with each product

Here it gets nasty:

• Issues (Bugs, Features, Improvements) can apply to several products
• When issues are worked on, they often are only resolved for one product, the resulting changes to be merged to other products later
• Developers shift focus from one product to another quite regularly
• The products are developed in parallel, but are not synchronized
• Versioning is not synchronized (later products start with 0.0.1 containing all the functionality the other product got in 4.x.x)
• Releases are not synchronized, but every time when "enough" issues are resolved to justify a release
• Roadmaps can be different for every product
• Products use different versions of the library at the same time

And despite this workflow me and my team need at least the following insights:

• Overview of the situation each individual product
• A changelog of all the issues that affect a version

Does JIRA support this workflow?

Thanks.

---

Additional information: Right now we are using MantisBT as our issue tracking system. After we tried the "product-matrix" plugin [1], that did basically what we wanted, but was not very well integrated, we thought about implementing a plugin for Mantis that would have worked the following way:

• Right now every issue has one 'version', 'target version', 'priority' and 'status'
• After the change all these 4 attributes would be children of a issue-'product'-relation
• For every issue you can choose which product it applies to
• If a product is selected for an issue, you can give it a version, target version, priority or status
• You can view only issues for one of the products
• You can generate a changelog for an individual product-version combination

But as implementing this seems like very hard and we were already thinking about moving away from Mantis (too old, too inflexible [workflow]) I thought it would be best to ask the community about better solutions to our problem.

[1] http://git.mantisforge.org/w/product-matrix.git

[Dana Frost]

I have a similar issue for the system I have set up. Most solutions either involve...

• Links between issues
• Clones of issue

And of course either can work when they are not needed for most issues but when they are needed more often, the users naturaly push back on all the work needed to connect the dots.

The only other solution I have come up with is this:

• Create a new cross-project subtask that only has a few fields (summary, and custom field Cross-Project) but follows the same/similar workflow.
• When an issue impacts multiple x-projects and need need testing/resolution for each, the user creats a cross project subtask for only those x-projects it has direct impact and makes the x-project FixVersion the Summary. No need for a descriptive summary because its the same as the parent (or you could just add a cross-project field etc).
• Change it so that subtaks must be resolved/closed before issue can be resovled.

So, now the process is a bit more light-weight and all the x-project info is in one place instead of x-linked all over. Also, each project can find these x-project issue easily using the Cross-Project field of the Cross-Project Subtask.

Still some major negatives here...

• Its still a bit of work creating cross-project subtasks
• The Cross-Project field can not be a pulldown of the Cross-project FixVersion (unless there is a plugin or advanced mods available that I have yet to discover).

What this offers is an easier way to create these x-project dependencies without clones/links where all the info about the issue is in one place instead of cloned/linked to each project.

I am going to demo this to the team and see but its still a pretty clunky solution. I wish that Atlassian would take a task to figure out a better way to create cross-project dependent tasks and custom fields that could refrence x-project versions to implement them.

Honestly though I think having cross-project dependencies is an indicator that what you really need are common projects with there own versions and there own project (like a Graphics Library with a Version) and you only track the bugs in that one project that is used in other Products. Then each product has a manifest of versions of the components being used.

I think that is the only good manageable solution as things scale up. And its the way most large open source projects work. For example, you may have a bug in your Web Store front that relates to a MySql bug. But I don't think you are going to track all the MySql bugs in your Web Store project. You would probably just track a customer issue and you would state that the issue relates to a MySql bug (put a ref in there) and it will be fixed when a new version of MySql is incorporated etc.

Its a tough problem with large organizations that use a lot of common code but don'e do symantic, independent versioing of the common code/libs.

[janpio]

Already a thanks for your answer, I will have to think about it a little bit before answering.

[janpio]

"Good" to hear I am not the only person searching for a solution to this problem. I tried to understand the solution you described, but still have some questions:

• Am I correct that you have one base project where the main issues are created and several product projects where you create lightweight sub-isseues to the base issue? Then these base and sub issues are linked?
• Can you create the project subissues directly from the base issue?
• What do you mean with "The Cross-Project field can not be a pulldown of the Cross-project FixVersion"? I didn't get that part.

I don't really agree with your conclusion that this situation indicates the need for real project plus smaller components as their own projects, as the products we have really are 'implementations' of the framework/template project. I'm sill looking for an analogy to explain this better, what we do, but I can't find one. It's too mangled and connected to really have this seperation. That's why I'm even not sure if I better have one big project with indication in the issues, or several projects with some form of linked issues.

[Dana Frost]

1. For us we have 3 interdepended project, there is not one "Common Libs" project just 3 interdependent ones. So, there is no base project. Each project would have "Cross Project" subtasks that refer to another project.
2. All subtasks must be created from the same project (JIRA does not allow cross-project subtasks)
3. Because (#2)

[janpio]

Sorry, but I'm still a bit confused, probably because I didn't use JIRA before. These "cross-project subtasks", how do they work? Is there one main issue and 2 subtasks?

[Dana Frost]

In JIRA (out of the box) issues can have one or more sub-tasks. I am just talking about creating a custom sub-task which is also possible with basic JIRA.

[Renjith Pillai]

First thoughts, provided I understood your situation correctly.

• Most probaly you need one Jira project per product (going with your desription of releases and roadmaps)
• One project for tracking your library which is developed seperately (which also has versions of it's own as I understood from your explanation)
• So every issue now in your product related Jira projects will have the product versions it affects.
• You may need a custom field for product related Jira projects to put in the version of the library that you are using (since you mentioned different products use different versions of the library) (this may be a bit of duplication of information in every issue)
• For those Issues, Bugs and Features that affects multiple products, you need to create individual issues in each of the respective products. The reason being your releases and roadmaps are independent for these products. You should also additionally link them to denote that they are related to each other.

And with Rapidboard in Greenhopper you could prioritize across multiple projects for teams to focus as per priority.

[janpio]

Thanks Renjith, you understood the situation absolutely correctly. The process you describe is quite similar to how we handle the project with our current setup in Mantis right now. But it has some major problems:

• Issues affecting multiple issues is the rule, not the exception
• So creating a simple issue is real work, you need to create x issues and link them
• Comments on the issues aren't synchronized, so if the developer starts working with the 'wrong' one (without all comments) he may do unnecessary work
• Updates on the issues (changes in priority, category, description, title) tend to not be snchronized, too
• Getting an overview about an issue (its status across all projects) is very hard

If there was a way to automatically synchronize changes from one project's issue to another, then maybe this could work. But as far as I know, there isn't.

[Renjith Pillai]

Since you need to handle the correction independently for each product, somehow we need to have seperate issues per product. Another option could be then sub-tasks.

Then it will mean, a single project for everything, and sub-tasks getting created to track the corrections in each product. This also means, you need a custom field to indicate which product this belongs to. Again, this becomes a bit messy with you losing all the built-in features of handling each product seperately. Roadmaps, release notes, project overview etc. A kind of workaround could be to have product specific filters and creating one dashboard per product which summarizes all the issues using the product filters.

Going back to option 1, if you are okay with some coding, you can develop a plugin which can then keep the fields synchronized across all the linked issues. Overview of the issues across all the projects should not be an issue in first approach as each issue will show the status of all the linked issues while viewing it. And the cloning of issues will be handy to create issues for multiple projects, of course, you need to clone and move the issue to mark it for a different project.

[janpio]

I only need to change priority, status and other attributes depending on the product, issue title and comments or discussion stream can/should be shared.

Basically you propose 2 possible solutions:

1. Use a project per product and create multiple issues to be connected by relations. This brings the pain of creating and onencting all these issues and keeping the seperate issues synchronized.
2. Use one project for all products, using a custom field to indicate the affected product. Here we lose the possibility to create seperate roadmas, release notes etc.

Did I understand that correctly?

Any pointers for how it would be possible to code a "issue content synchronization" plugin for option 1? Maybe it is even possible to simplify the issue creation...

(Thanks for you help, really appreciate it)

[Renjith Pillai]

Yes, that is what I meant.

Regarding issue content synchronization, what was done in one of our cases (not a similar one), we used to regularly run a external script which connects to Jira over SOAP, pulls out the Jira ids using the required filters. Also additionally load the xml feed of the filter (as SOAP does not support Issue Links) and then do a comparison of the contents. And if needed update the required issues. In your case it's a bit more complicated as you expect the Summary/Description to get updated in any of the items. Then you may need to look into the updated date (and probably issue history to check whether these fields are really changed) to make the updates. SOAP does not support issueHistory, but REST does (getHistory/getActivity).

For issue creation, in another case, was also achieved in a similar manner using SOAP (in my case, the users wanted to quickly transform emails into Issues - with some changes). So an Outlook Plugin was written again picks up an existing email and transforms the subject, mail body and attachments to an issue. A similar stuff could be done with the possibility to select multiple products to be selected during issue creation.

[janpio]

I also looked into the available APIs, but I don't think taking the ticket creation step outside the issue tracking system is a good idea. When we switch to JIRA, I want it to be fully integrated and matching our workflow.

I found a plugin that lets you "Synchronize fields for two linked issues": https://studio.plugins.atlassian.com/wiki/display/JCALP/JIRA+Create+Issue+And+Link+Plugin Maybe it even lets you create issues (sub issues) when creating an issue, I didn't really understand that part yet.

Another plugin gives a "Collapsable Check Boxes" that could be useful to select the connection between the parent ticket and several child issues in a nice way: https://plugins.atlassian.com/plugins/com.palm.jira.plugin.palm-custom-fields-plugin I have no idea how you could create these tickets then, but maybe there is a ticket for that, too.

The "Parent status field" custom field in this plugin would be really useful in the child issues: https://plugins.atlassian.com/plugins/com.innovalog.jmcf.jira-misc-custom-fields

And last, but not least with this plugin I think I get the power to require the users to fix all child issues first before being able to close the parent: https://studio.plugins.atlassian.com/wiki/display/JBHV/JIRA+Behaviours+Plugin

So basically I think I have all necessary parts but the automated child issue creation and deletion on selecting a checkbox on the parent issue. And of course I need a way to dynamically create and administrate the 'projects' for which child issues can be created.

Does this make any sense? I'm a total newbie to JIRA...