Usage of Jira Deployments with staging environment

[Ricky]

I have set up Jira deployments to track Github deployments to our staging environment. The staging environment is our only environment pre-prod and is used by our PMs to test stories before they go to production. We only deploy feature branches (not long living branches) to the staging environment.

Currently, the PMs don't have an easy way to find out what is deployed to different servers in the staging environment. I thought that the Jira deployment view might help. However, I suspect that the Jira Deployment view is only made for long living branches. It shows data that I can't make sense of: Branches/tickets that are already merged and deployed to prod will be displayed as deployed again between 1 - 5 times thereafter, making the view incomprehensible at the moment.

I suspect  that it internally creates a diff between the commit SHA of the last and current deployment and associates those commits to tickets and then creates a deployment in the respective tickets.

Can somebody confirm or deny this? Is there a way to make this work for our setup?

[Martin Runge · Accepted solution]

Hi @Ricky

Welcome to the community!

You are correct, Jira’s deployment engine relies on identifying the "delta' between deployment events. Short-lived feature branches that are frequently merged and redeployed can cause Jira to re-associate the same commits or tickets multiple times, leading to duplication. The Deployment view is optimized for a linear flow with long-lived branches or tags, like Develop, Staging, and Production.

To customize this for your setup, consider these adjustments:

• Environment Mapping: Explicitly define environment names for environment mapping in your GitHub Action/Pipeline. 
• Instead of tracking every feature branch push, trigger the Jira deployment notification only when a branch is merged into your primary integration branch. 
• If the Deployment view is unclear, consider Jira Releases (Versions). Automate ticket assignment to 'Staging' in your pipeline. PMs prefer the Release Hub for a cleaner view of tickets in specific environments.