nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to align projects and products

Nick Cuckson

We have several applications (e.g. Aa, Ab, Ac) and several products (e.g. P1, P2 etc) made up of these applications, so that P1 = Aa + Ab or P2 = Aa + Ac. I'm not sure how to organise the JIRA projects - should the project represent the product P1, P2 etc, or should the project represent the application Aa, Ab etc? There are multiple versions of each application and multiple products containing many combinations of applications.

I thought we could have a project per application (for versioning) and use components to identify the product, but this seems very confusing and unnatural - I was hoping to describe a hierarchical relationship. An alternative I thought of was to have a project for the product and use the component field to identify the application, but I want to version the apps. We could use the project category, but if a project represents an application, each project would have to have multiple categories assigned and the issues would then be associated with all the categories. No use for filtering.

I'm sure other people have faced this dilema, so I'm hoping for suggestions of what best practice might be?

Accepted answers

Norman Abramovitz

Each of your applications and products would be a separate Jira projects. You can then use versions or labels to define each indivdual delivery unit. Your application project would contain issues that would state project version/lable x is being used.

All comments

Norman Abramovitz

You might want to vote for this ability.

https://jira.atlassian.com/browse/JRA-5721

Norman Abramovitz

Nick Cuckson

Thanks for your advice

Norman Abramovitz

You can also use links from the application issues to the product isssues if you do not need a separate comment area outside the product issues.

Norman Abramovitz

Look at this plugin if you like the linking idea

https://marketplace.atlassian.com/plugins/com.docminer.jira.issue-links

Hugh Brown3

I realise this thread is two years old, but I'm facing the same challenge.

Our project includes:

Website
Windows App
Linux App
Mac OS App
Android App
iOS App
Web services shared by all of the above

Each of the above items could be released independently and therefore would have its own version number.

Any ideas on how to use Jira versioning? Having a separate project for each would be unmanageable.

Nic Brough -Adaptavist-

I'm afraid this is pretty simple. If you want to version things separately, you need separate projects, because versions are project level entities.

For what it's worth, most of my clients are doing exactly that, and really don't find it "unmanageable"

Nick Cuckson

For what it's worth, we ended up creating a project per product and then using a matrix in confluence to identify the components that went into each product release. This Confluence page is automatically updated by a Jenkins plugin, so it's always up to date. We use a subversion plugin to identify any code that was changed, so we can refer back to it if required. The components are identified by name and not version in an issue component field.

For us, there was too much 'joining up' to do to put everything in its own project. My main aim was to get everyone to use the system, so making it as simple as possible was an important consideration.

But there are many ways to skin a cat...

Richard Garner

The way we got round this is by having the application (or svn repository to be specific) take on the version from whichever project release it was part of. The chronology of releases for a given application was kept by simply prefixing the date. So if there are projects "PROJ", "OTHR" and "SOME" that all have code changes in "myapp" then the repo ends up looking like this.

myapp/20160102-PROJ.1.5.0

myapp/20160312-OTHR.2.0.0

myapp/20160410-SOME.1.5.0

myapp/20160420-PROJ.1.6.0

The order is kept by the date prefix and you can see which overriding project they were associated with. Admittedly it's not ideal if your versions are customer facing, but it makes sense to me.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

project

organization

best-practice

component