Project with multiple components

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

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 vote
Timothy Chin Community Champion 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. :)

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 Chin Community Champion 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.

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.

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,323 views 14 20
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot