Project with multiple components

Neil Hunt May 28, 2013

Our "programs" typically are comprised of multiple components - say a web application and a services application. These apps have different versions and different release cycles. From the business viewpoint, when they create tickets, they don't necessarily know or care whether the issue relates to the UI or backend service - they just want to create an issue related to the program. However, when we are release planning and tracking development tasks, we are focused on those individual components, for example we may be ready to deploy our services app but not our web app if the web app has outstanding issues related to that version.

How can we best accomplish this? If we associate the Jira project with the program level, we lose the independence of our deployable units and the Jira features associated with that isolation such as independent versions and ticket tracking. However if we make individual projects for each of our deployable components, that will confuse business users to have to know more about the technical architecture than they normally would.

Is there a way to create an issue at a level higher than a project? Or some kind of support for subprojects? Or perhaps an ability to use the Components classification with greater independence? We're open to any ideas on how to solve this (probably common) situation.

4 answers

1 accepted

2 votes
Answer accepted
Neil Hunt June 6, 2013

Thanks for input, Tim. We have decided to prefix Version with Component. So if we have components "Web Tier" and "Service Tier", we could have WT1.0, WT1.1, WT1.2 and ST 1.0, ST2.0, etc. Not super clean, but since we can hide those if we set Version to Archived, the list of versions should still be manageable and we can acheive deployable unit version independence while still maintaining one high level project.

0 votes
Deniz Oğuz
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 6, 2014

We have developed a JIRA plugin that allows component specific version numbers. It enforces component specific versions on issue create, edit, inline edit and workflow screens. You can check it out at Atlassian Marketplace, Component and Bundle Versions for JIRA or at the plug-in's help page for more detailed manual. This Plugin also allows you to group different versions of different components into one bundle. At issue creation page, if you do not select any component, this plugin only allows you to select bundle version numbers. It also provides two new JQL functions (affectsBundle and fixedInBundle) to query issues affecting a bundle. We welcome any feedbacks.

Meliora Technologies Ltd. May 18, 2020

So, I have been trying to add the plugin mentioned above, the link above points to an app called, configuration management tool-kits but I cannot find it on my Jira market place. Is it still supported?

Deniz Oğuz
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 18, 2020
0 votes
Vijay Bantanur May 29, 2013

Thanks Tim. I and Neil work together so I am responding on his behalf to earlier issue Neil had raised. If I got it right, your suggestion is to create a JIRA project that makes sense to business but create components that represent actual deployables. If we take this approach we would need capability to assign versions at component level as we want to tie deployable version with the component version. For example service changes may undergo different revision (1.1.0 for eg.) compared to web (1.0.0 for eg.)related deployment. (In this case we have web and service as two components/deployables under this project)

Timothy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 29, 2013

Yes. That's correct. Your business people can do whatever they want when they create issues. It's up to you to triage them with Components, Versions, labels and so on and so forth.

capability to assign versions at component level

At the moment, JIRA does not support this. You may be looking at splitting them into different projects then.

0 votes
Timothy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 29, 2013

From the business viewpoint, when they create tickets, they don't necessarily know or care whether the issue relates to the UI or backend service - they just want to create an issue related to the program. However, when we are release planning and tracking development tasks, we are focused on those individual components

IMO, what you can do is to have have a "Triage" status in between these two processes. While issues are in this Traiage status, the appropriate users will "fix up" the issues and move them into the development status. You can create filters to manage issues are in/not in the triage status.

Another way would be to change the issue type. When moving issues from one issue type to another, it is the duty of the development team to make sure things are recorded right in the issue.

And yea, there is no sub-projects. That's what components are there for. :)

Suggest an answer

Log in or Sign up to answer