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.
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.
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)
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.
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Hi, everyone! Molly here from the Jira Service Desk Product Marketing Team :). In the spirit of this month's august-challenge, we're sourcing stories of Jira Service Desk activation fro...
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!
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