I’m working on a software project that has a shared core system used across different products (let’s call them ProductA, ProductB, etc). Each product has its own specific components on top of the core.
We maintain several branches for each product because we have different versions deployed to customers that need ongoing support and sometimes we need to backport features.
Right now we’re using JIRA for issue tracking but I’m struggling with how to properly organize our setup. Here’s what we’re doing currently:
- Components are used to separate CORE, PRODA, PRODB, and so on
- Components also track which branches are involved
- Fix Version field tracks our sprint cycles (we do 2-week sprints)
This approach kind of works but using Components for branch tracking feels wrong. The main problem is you can’t retire components in JIRA, only delete them completely. We went this route because mixing sprints and branches in Fix Version means we can’t search for specific combinations like “sprint 5 AND branch-v2” since JIRA doesn’t support that kind of AND filtering.
Does anyone have experience with better ways to handle branch management and sprint tracking in JIRA? We’re dealing with about 4 different products and roughly 3 active branches per product that need maintenance.
We faced a similar challenge managing multiple product branches and found success using custom fields instead of overloading Components. Created two custom fields: “Product Branch” (select list) and “Target Release” (separate from Fix Version). This lets you maintain Components for actual system architecture while tracking branch information cleanly. The key was setting up proper field configurations so only relevant branches show for each product component. For sprint tracking, we kept Fix Version purely for sprint cycles and used the Target Release field for actual deployment versions. This approach scales better since you can easily add/remove branch values from the custom field without the deletion headaches of Components. The reporting becomes much cleaner too since you can filter on product, branch, and sprint independently. Takes some initial setup time to configure the field schemes properly, but the long-term maintenance is significantly easier than trying to make Components do double duty.
After dealing with similar branch tracking headaches, I ended up restructuring our workflow around project hierarchy instead of cramming everything into one project. We created separate projects for each major product line with shared issue linking back to a core project for common components. Each product project has its own simplified branch tracking using Fix Version for actual releases and a single custom field for maintenance branch designation. The cross-project linking lets us track dependencies between core and product-specific work without the component mess. Yes, it means more projects to manage, but the clarity in reporting and workflow configuration makes it worthwhile. JQL queries become much more straightforward when you can scope searches to specific product projects first, then filter by branch metadata. The overhead of managing multiple projects is offset by not having to maintain complex field schemes that try to accommodate every possible product-branch combination in one place.
honestly we just use labels for branch tracking - way more flexible than components. create labels like ‘branch-v2-prodA’ or ‘maintenance-v1.3’ and you can add/remove them easily without jira throwing fits. keeps components for actual architecture stuff where they belong.