How do "you" handle runtime incidents (say, a null-pointer exception, or an API input data validation failure) so that you (a) don't miss any, and (b) aren't spammed by duplicates? Are you doing log file introspection?
We're currently NOT using Jira for managing bug reports. We are going to want to do that.
In reality, if a runtime exception occurs, it's going to re-occur numerous times before we have a fix deployed to production, and we don't want to be notified 187 separate times about what is essentially a known issue.
What we've been doing (for about a decade) is:
- When a runtime exception handler can't resolve an incident programmatically, it will send an email (with metadata, stack trace, etc.) to a mailbox. (The email also serves as a one-way pipe out of a tightly regulated production environment.)
- The mailbox is monitored by a separate system that does some regex matching to generate standardized "bug reports" from these emails.
- A recurring task will then classify new bug reports in order to identify and assign the relevant project (software product) and the owning development team. The classifier will also identify re-occurrences of known issues and attach them as "children" to the original bug report for that issue. We can also tweak the parameters for how a "parent" bug report will classify re-occurrences.
- Individual bug reports can then be pulled into our sprints as tasks, but a bug report remains "open" (still catching re-occurrences) until it is marked as deployed.
This is a very effective system to "squelch" the stream of bug reports, allowing us to focus on actually unique issues.
...but all of this is outside of Jira, and Headquarters really wants us to "embrace Jira" so we need to think about how to retain the value of this triage automation.
(For clarification, I'm attaching a sample screen shot of our triage automation tool.)