How to effectively manage branches with JIRA?

Question

We develop a product that consists of a core runtime shared across products (project1, project2, ...) and a project/product specific part. For each of those "products" we maintain multiple branches because different versions are rolled out into the field and require maintenance and sometimes even feature backports.

We also use JIRA as an issue tracking system and I'm having trouble finding the right way to model our product types/branches. The JIRA elements that seem relevant in this context are components and versions:

• we use components to differentiate between CORE, PRO1, PRO2, etc
• we use components also to identify what branches are concerned
• we use Fix Version to keep track of what iteration to resolve the issue (iterative development, bi-weekly iterations)

This more or less works but using the Component type for branches is a hack and has the disadvantage that you can not "retire" components, only delete them. We choose to go this way since if we would mix the iterations together with the branches in the Fix Version field we can no longer query for "iteration X and branch Y" (JIRA does not support AND queries).

What sort of best practices exist for maintaining branches and tracking iterations in JIRA?

Some stats for context: we are talking about around 4 product types and about 3 major branches per product type to maintain.

Answer 1

One quick approach I can think of is to make your iteration names include the branch name (and possibly the project name as well). Then you could use the fix version to denote the iteration as well as the branch, with names like branch1_iteration1, branch1_iteration2, branch2_iteration1, etc.

This would let you query on issues for a specific iteration within a branch, and also has the advantage that you can put a due date against each fix version so that you can track whether you are on schedule.

As an aside, rather than using the JIRA component field to denote the project (CORE, PRO1 etc.), I would use separate JIRA projects instead; you'll get better granularity and flexibility that way.

Answer 2

I'd take a slightly different approach to this problem. I'd set up components for your Core Runtime and for each project/product specific part, but don't make these components branch specific. So, you might have the following components in your Jira project:

• Core
• ProductX
• ProductY
• ProductZ

Then, I'd differentiate the different branches by version. I'm assuming that you have some type of version numbering system that allows you to tie your binaries in the field back to a particular branch and version. Set up a version in Jira for each version/branch. When you report issues into Jira, you can select one or more affected versions.

This system has a couple of advantages:

1. If an issue spans multiple versions/branches you can identify all of the affected versions in the issue.
2. You can set the Fix For Version to one or more versions. At times, you may only fix an issue in your trunk, or a certain branch. Perhaps it's a major issue and you have to port the fix across branches. This system gives you the flexibility to see all of that and report on it.