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
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.
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...
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.
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 :)
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
Of course it can be done, but Jira is not coded for that to be done via Links. You may need additional plugins which does this or write one yourself.
Jamie's script runner can do magic with post functions with groovy scripts.
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
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