Best practices regarding projects vs products

Question

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?

J_s78d71 · Answer

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.

Nicolas Bourdages · Answer

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?