How to align projects and products

Nick Cuckson November 15, 2012

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?

4 answers

1 accepted

1 vote
Answer accepted
Norman Abramovitz
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.
November 15, 2012

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.

Nick Cuckson November 15, 2012

Thanks for your advice

Norman Abramovitz
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.
November 16, 2012

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
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.
November 16, 2012

Look at this plugin if you like the linking idea

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

1 vote
Nick Cuckson September 3, 2014

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...

1 vote
Hugh Brown September 3, 2014

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-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
September 3, 2014

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"

Richard Garner April 19, 2016

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.

0 votes
Norman Abramovitz
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.
November 15, 2012

You might want to vote for this ability.

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

Suggest an answer

Log in or Sign up to answer