Best practices regarding projects vs products

J July 23, 2015

Our company produces a number of separate products (each with its own versions, release cycle, etc.).

Is it recommended that we use only one JIRA project to represent each product?

We've been creating JIRA projects to represent time-delimited tasks, like releases or new-feature development efforts. These might involve work in one or more products.

But I'm concerned that this will cause problems when we start using Fisheye to link commits to issues, or when we start using Releases/Versions to keep track of all the JIRA issues related to a release.

Is this a bad idea? Or is it common to handle things this way?

1 answer

1 vote
Nicolas Bourdages
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.
July 23, 2015

I feel it's pretty common to use one project per product. Even from within my small-ish office, I've seen project sub-elements used in a variety of ways to represent releases. Some would use versions to indicate deliveries (like, V3.04 - Client name), components, or Epics.

Your issues would still be quite easy to query. I suggest you get the Scriptrunner plugin to get advanced JQL functions, like versionMatch / componentMatch, and such. It would help making very precise filters to quickly find your releases.

I don't really see how any of that would impact fisheye commits though. Are you talking about having your repository structure matching JIRA's structure? What are your concerns exactly?

J July 24, 2015

Yeah, I guess it might not be a problem for Fisheye commits, although it seems less confusing to have a one-to-one project mapping there too.

Suggest an answer

Log in or Sign up to answer