You Can't Fix Your System Just by Refactoring Ticket Management
we have a lot of bugs: on stage, on prod and bugs that come from releases
This is the X in your X/Y problem. You shouldn't really have three buckets of "bugs" for the same issue, unless the issues are environment-specific. Even then, I'd challenge the idea that they are truly separate issues.
Your underlying issue is that gated environments should be conceptualized as a pipeline. For example:
Backlog -> Development -> QA -> Staging -> Production
Backlog <- (all bugs go here)
In other words, it doesn't matter where a bug is found. If it's a bug in the product or service, then it should go back to the start of your loop, whether that's a backlog in Jira or directly to the development team for triage and disposition.
The only "bugs" that really belong to other stages are those that are environment-specific. For example, a gap in the Staging infrastructure itself is something that should usually be fixed in Staging by Staging engineers, not by developers. Even then, I could make an argument for "shifting left" and having infrastructure-as-code developed in Development and then tested in later pipeline stages.
Different Environments May Use Modified Settings
Consider the following, which should be developed and committed in Development but possibly tuned in other environments:
# pseudo-code for per-environment settings
case environment
when dev
set foo 1
set bar 1
when qa
set foo 3
set bar 2
else
set foo 5
set bar 5
end
With software, higher environments may need to tweak settings and use different credentials or data sources, but shouldn't be changing anything fundamental about an application. If they uncover a bug, or a knob they can't twiddle, then that should be reported as a bug to Development. If you have QA, Staging, or Production making fundamental changes to an application, then you're doing the whole thing wrong anyway.
Use Systems Thinking
Regardless of your project management framework, environments should be considered testing gates on your way from "not done" to "done." As such, the fact that you seem to be:
- Working off of different backlogs in each environment is a "process smell."
- Releasing to higher environments without adequate gate testing is another process smell.
- Lacking feature toggles so that you can release often without breaking your build in higher environments is another process smell to consider.
In short, the whole cycle lacks systems thinking. Each department is focused on itself, rather than collaborating together on a holistic CI/CD and testing pipeline that represents a low-friction cohesive process. Focus on fixing that, and the issue of how to represent the work within in your ticketing system will generally become self-evident.
