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?
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.
I realise this thread is two years old, but I'm facing the same challenge.
Our project includes:
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.
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"
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.
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.
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...
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in talking to 20 people planning t...
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