What should you do when an issue ends up not being resolved after a deployment?

Kye Russell

Scenario:

1. Issue X is created and assigned a 'Fix Version'.
2. Issue reaches the end of its workflow (a 'Done' state, and is resolved). The team is under the impression that this has been actioned properly.
3. A deployment occurs and it is discovered that the issue wasn't really resolved.

Do you:

• Pull the issue back into an 'In Progress' / 'To Do' state, change / add to the Fix Version, and comment on it?, or
• Create a new issue referencing the existing 'completed' issue, meaning that anyone watching / actioning the issue will have to consult the original issue for more context.

The ideal solution is "everything should be fixed before a deployment and your testing / CI should pick this up before it happens", but this is not the reality.

I suppose that this is fairly dependent upon my workflow, which I've attached. We haven't begun the crux of our Jira migration yet so this workflow is highly theoretical and isn't remotely set in stone, so I'm happy to take "your workflow is wrong, and here's why" as an answer. However I've determined that Jira Software's 'Releases' functionality expects issues to be resolved before you can release (it'll let you, but it'll whinge about it first, so I suspect that it's not something I should be doing). So please keep this in mind.

Any and all help is appreciated. Thank you.

Tom Lister_fo1j4e

Hi @Kye Russell

I think this is really a question of what process you want to follow.

In my experience different teams worked this out in different ways. Some would push the issue back to dev status and unset the Resolution. Others would raise a new ticket for the patching work. The latter is a bit cleaner in my opinion and will give you a picture of how many repeats you do. I also had a team request a workflow step to allow them to edit a Resolved issue to set it to ‘Failed’ Resolution with a reason entered.

Most of the workflows I’ve set up for dev teams have a Test or QA status. That won’t prevent failed deployments on its own. But it does record who approved it and you can dig in to what the weak points are in the process.