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; } } }

General question about project layout

Christoph Berli

Hi everyone,

I have a question regarding configuring JIRA for our development team and I am not sure if I think too complicated or if the root cause is truly tricky.

Let's say we have a development team that focuses on three different products: home, smb and enterprise. Each product has its own release schedule, versions and milestones. However the problem is that all three products share quite a bit of the same code base (let's call it CommonCode or CC). All projects use code from CC but build different features on top of it.

First I thought we simply setup three projects (home, smb, enterprise) and start from there however the problem is because they share code, it very likely that a bug belongs in the CC bucket but will be filed in a product bucket. Ideally we want to make sure fixing the bug applies to all products rather than just one. Because of that I thought it would make sense to create a fourth project called CC and all common bugs go on there...but then time tracking and project management gets screwed up because it works on project basis.

Long story short: is there a more elegant way to achieve what we want? Or is there a way to combine time tracking reports and versioning reports to including the product project (home, smb or enterprise) AND CC?

Again maybe I just have a brain freeze and therefore any input would be more than welcome.

I apprecaite it. Chris

Accepted answers

All comments

Norman Abramovitz

First, do not confuse what happens in your source tree and what gets entered into the bug tracker. If someone fixes something in the common code, it can be recorded under any of the products. The common code will have a new version number from the source repository, so it should be picked up by all developers when they update their working copy from the respository. This assumes that each project did not make its own copy of the common code.

It is important that the source respository contains comments about the update even if it is just the jira issue because it is the source repository history that will tell you what changed when you do a release.

The bug tracker history has the direct changes for each project and its worklog.

Christoph Berli

Thanks Norman, I appreciate the reply and you are absolutely right that the projects should not map directly to the source trees however from a project management point of view I am still in the dark. Let's say I entered a bug for the commoncode and filed it under Home then it is pretty much clear that this common bug shows up under ounstanding Home issues. If it gets fixed, all the other projects (SMB and enterprise) participate from it by using the latest common code version. However let's say a commoncode bug is filed under Home but I want to release SMB then I might miss that the bug still has to be addressed before shipping. One option could be to link all common bug to the product projects but a) I have no idea if links can be created automatically by ticket creation and b) this seems overkill to me...

I thought about making it real simple and just creating one project with categories (common, home, smb, enterprise) and sub categories but I wonder if that make sense. I cannot release just a component...

Thanks again

Renjith Pillai

In my opinion, what you are doing right now with four projects is the way to handle this. But I am not sure why you say time tracking has an issue for the items created under CC?

Christoph Berli

Hi Renjith,

The problem with time tracking will be that I theoretically have to manage two projects (home, common) for one release (home). It will require manual work to map all the outstanding tasks together in order to fully visualize the project status.

However after writing my last response I actually came to realization that it would make most sense to link commoncode issues into the product projects. For example CommonCode-1 is a blocker for Home-1 (which is a placeholder for CommonCode-1) and SMB-1. If CommonCode-1 gets resolved then Home-1 and SMB-1. The reason why I came to this realization is because CommonCode will actually never release and it could be that I want to release Home without resolving all issues in CommonCode project.

Does this make sense?

If yes then I need to find out how to efficiently create links. Is there a way to create a new product ticket (Home-1) when creating a link from CommonCode-1? Also is there a way to automatically resolve the (placeholder) ticket (Home-1) when the CommonCode-1 is resolved?

Maybe I make this whole thing utterly complicated

Chris

Christoph Berli

Thanks Renjith, much appreciated it. The create and link plugin seems to do the trick. I am a bit bumped that I cannot update linked tickets automatically. Is there another way to do it? We use ZenDesk for support and here the ZenDesk ticket gets resolved then the JIRA ticket gets resolved. Why can't I do that for JIRA to JIRA projects? Thanks again

Renjith Pillai

Links ofcourse can be used to indicate the issue dependencies. But apart from that, nothing automatically happens via Links.

You have a plugin which does the reverse, Create and Link.

And the time tracking issue remains when you have multiple projects, and I guess Tempo could be an answer.

Norman Abramovitz

In your second case, you would create an issue to track the common fix for the project and either link or make the common code issue a subtask. Your time tracking would still be under the release projects.

The issues under the common code never gets released by itself, so the linking or subtask approach allows you to know which project actually fixed the issue.

I am heading out of town, so I will not be able to respond more until Monday.

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-cloud