1

What is the best practice (and why) on closing tickets/issues in the versioning/ticketing system during software development?

Our workflow is based on creating FEATURE or PATCH branches to implement changes and then merge into a controlled master that is (mostly) guaranteed to build and be ready for deployment.

Our ticket system holds bug reports or feature requests we subsequently fix/implement in said branches, then merge into master before the next release.

Which solution is better:

A. Close the ticket once the solution is implemented (and verified) in the FEATURE/PATCH branch. This cleans out the list of open tickets fast and gives a good overview off how much work is left for the next release.

B. Keep it open until the branch has been merged to master and verified there. Only master represents the final product, so technically only now the work is done. And no bug might stay un-fixed because someone forgot the merge.

Chaos_99
  • 2,284
  • 2
  • 25
  • 29

1 Answers1

0

My experience is that a support ticket with a feature request is closed after the request is logged with the Product Manager, they acknowledge with a time-frame and the customer has been suitably advised.

For a patch, both are valid approaches, but depending on when the fix is liable to be applied. If it's liable to be a fix-pack release within two weeks: keep the ticket open until the patch is deployed to that customer. Use the ticket as the root for the change management system. Otherwise, if the fix will not be deployed until some future routine release, then my advice is to let the customer know accordingly, and close the ticket.

Robert Howe
  • 314
  • 1
  • 11