How do you track which environment a ticket is deployed to across multiple repositories?

At minimum, enforce a ticket key in every branch name, pull request, or commit message and connect GitHub to Jira. That makes the ticket-to-code relationship automatic instead of relying on someone to update a version manually. It won’t solve the whole multi-service problem by itself, but it gives each deployment a much cleaner list of candidate tickets.

I’d also have the pipeline write the exact SHA being deployed and expose that information somewhere searchable. A ticket should not be considered deployed just because its branch was merged; it should be tied to the specific artifact or commit that reached the environment.

Semantic-version tags answer which release is running, but they don’t automatically answer whether a particular ticket is included, especially when one change spans six independently versioned services. You need a build manifest or deployment record that maps the release artifact back to ticket IDs for each repository.

I’d start with a small GitHub Actions step that generates that manifest and publishes it during every staging and production promotion. Once the data is correct and trusted, you can decide whether Jira’s built-in view is sufficient or whether a dedicated deployment-tracking tool is worth paying for.

This may be partly a workflow problem rather than a missing tool. If every branch has a ticket number, the ticket moves through clearly defined workflow states, and the deployment pipeline updates the environment field or label, the PM can usually find the answer directly on the ticket. For QA, some teams create a temporary environment per ticket and add its link to the issue while it’s being tested.

That works best when the workflow states have precise meanings—for example, ‘ready for staging,’ ‘in staging,’ and ‘in production’—instead of using a generic testing column as a proxy for deployment.

The reliable approach is to record deployments as promotions of immutable commits, not as inferred Git ranges. Each GitHub Actions deployment should publish a record containing the repository, commit SHA, target environment, deployment status, release or tag, and the ticket IDs associated with that exact build. Jira can then show deployment data based on those records instead of guessing from everything that changed between two deploys.

For a ticket that affects several services, define it as production-ready only when every affected repository has a successful production deployment record. Release notes are useful for describing what was intended for a version, but they don’t prove what is actually running. This also gives you a query or dashboard that PMs can use without asking an engineer or checking a spreadsheet.