We're a team of about 12 developers maintaining roughly six services. We use short-lived feature branches that are merged into main and deleted afterward. Main deploys automatically to staging, while production is a manual promotion from a semantic-version tag. We have development, staging, and production environments, and our CI runs through GitHub Actions.
Our PMs regularly ask whether a specific ticket is in staging, but it's often unclear to the engineering team too. We enabled Jira deployment tracking, hoping it would answer this, but the same ticket appears as deployed several times and unrelated tickets sometimes get associated with a deployment. It seems like the integration may be assigning every ticket between two deployment SHAs rather than tracking the actual changes.
We've mostly stopped using it and gone back to checking Git history or asking in chat. Someone also maintains a spreadsheet before every production release, which doesn't scale. A feature may affect several repositories, each with its own version, so knowing that a tag such as v2.14.3 is running in production doesn't directly answer whether a particular ticket is live everywhere it needs to be.
How do you reliably answer "which environment is this ticket in" across multiple repositories? Is Jira's deployment tracking unsuitable for short-lived branch workflows, or are we configuring it incorrectly? Do tools such as Sleuth provide enough value, or is a small custom deployment-tracking script more practical?
3 Answers
Make ticket association a hard part of the development workflow. Require the ticket ID in branch names and/or commit messages, then connect your issue tracker to GitHub so pull requests, commits, and deployments are linked automatically. Moving the ticket through defined workflow states can show its progress, but the deployment pipeline still needs to report the actual environment and SHA rather than relying only on board status.
The important distinction is between release notes and deployment state. A release can tell you what was intended to go into a version, but it doesn’t prove what is currently running.
Have every staging and production promotion publish a deployment record for each repository containing the immutable commit SHA, target environment, deployment status, and associated ticket IDs. Then answer a ticket query from those real promotion records—not from the range of commits between two deployment events. For a ticket that changes multiple services, consider it fully live only after every affected service has a successful production deployment record. That gives PMs a reliable view without maintaining a spreadsheet.
This is usually more of a process problem than a branch-model problem. A PM or release owner should have a clearly defined source of truth for each ticket’s state, with developers reporting blockers and environment changes as part of the normal workflow. Some teams use dedicated QA environments per ticket and add the environment link to the work item while it’s being tested.
That said, a board column alone won’t prove that a change is deployed. For your setup, I’d combine the workflow states with automated deployment records from GitHub Actions, especially since one ticket can span several services.
That’s the gap we keep hitting: tags and board states tell us about versions or workflow, but not whether a specific ticket has reached production across all the services it touched. We’ll probably need the deployment pipeline to provide that final answer instead of expecting Jira to infer it.