The data in OverOps enables QA and development teams to automatically create high value Jira tickets focused on new and resurfaced issues in your applications. The information provided by OverOps within a Jira ticket delivers full context of what is happening inside the code at the origin of an error or exception, including the line of offending code with the data that was being processed by the application.
This method of delivery into Jira significantly reduces the time necessary for developers to investigate and comprehensively document details of new issues. And for the developer whom the Jira is ultimately assigned, the process removes the need to request more information as they get complete code-level sight into the error so that it can be easily reproduced.
The final result is a concise list of Jira tasks that fit into existing developer project workflows and into a tool that developers are very familiar.
Please also review our Tech Talk Video
Best Practices Guidelines
For most efficient use of OverOps-to-Jira automation, follow the proven practices noted in this document. Following these practices will establish a full end-to-end automated solution that compliments existing Jira workflows, instills a continuous feedback loop, and ensures QA and development teams only need to work within the Jira tool and processes they currently use.
Create a Jira Project Dedicated to OverOps Events
New or resurfaced OverOps events should go into a dedicated OverOps project within Jira. This approach will ensure that existing Jira projects are not flooded with tickets, and will enable Development and QA teams with a highly focused triage and prioritization workflow.
Create Service ID in Jira Dedicated to OverOps
Request a general service user ID (i.e. named as overops) from your Jira Administrator. This ID will be used to auto-generate all new and resurfaced issues found by OverOps within the OverOps Jira Project.
Update Jira Settings in OverOps
- As an OverOps user with administrator privileges, go to Jira Settings and change the username & password(on-prem Jira) or API token (SaaS Jira) to that of the new service ID.
- Under Limit access to the following projects, ensure only the OverOps Jira project is chosen.
Create Jira Issues for New and Resurfaced Errors
Now it’s time to configure the automated creation of Jira tickets. We should only create Jira tickets for new or resurfaced errors observed by OverOps, and they will be created automatically within the Jira project called OverOps.
To do this, we need to leverage the view called New Today that can be found within the CI/CD view category from the OverOps Views Pane. With this view, we will create a new view and alert based on only new exceptions seen in the last day.
To learn about the Views Pane, go here.
To learn how to define alerts, go here.
- From the OverOps View Pane, expand the CI/CD view category and click on the view called New Today.
- From the event column, choose the filter icon and select uncaught exceptions, caught exceptions, and swallowed exceptions, then choose Apply.
- Save the view, and give it a name. Suggestions for a meaningful name are Critical New Exceptions, or New Exceptions Today.
- Choose Next to see the Alert Settings dialog.
- Choose When a new event is introduced into this view
- And select the toggle for Jira.
- Setup the Jira issue field values by clicking Edit. Set the Jira issue fields to automatically route the new event to the OverOps Project.
- Choose Save settings, and then Save & Finish.
These settings on the Critical New Exceptions view ensures only one Jira ticket will be automatically created for each unique, new exception found in OverOps. This promises the OverOps Jira project will not be flooded with duplicate events.
Congratulations! You have now set up OverOps to create Jira issues inside the OverOps Jira project only when a new error or exception occurs.
Note that Jira issues opened from OverOps will include a link to the Automated Root Cause (ARC) screen in OverOps. This link will be accompanied with the application name, deployment name, and server name or group. Therefore it is critical that applications, servers, and deployments are properly named while monitoring with OverOps.
To learn best practices when naming applications, servers, and deployments, go here.
Now with new application errors tracked within a dedicated OverOps project in Jira, development and scrum teams can iteratively triage and prioritize tickets by application, move tasks into existing Jira projects, and continue to work with existing Jira workflows.
Sync OverOps Event Status with Jira Status
By installing and configuring the Jira Integration UDF, Jira issue status can be used to sync OverOps event status for a closed loop process. This enables events to be automatically marked “Resolved” or “Hidden” inside OverOps according to their Jira issue status. All other status in Jira not mapped to “Resolved” or “Hidden” within the UDF configuration correspond to the Inbox status in OverOps.
With this UDF enabled, Jira becomes the single source of truth for event status in OverOps. Events with a Jira ticket that have been marked hidden or resolved in OverOps but are not updated in Jira to the matching status will revert back to the Inbox in OverOps.
To learn how to install and configure the Jira Integration UDF, go here.
Jira Sync Considerations
- When marking an issue “Hidden” and using multiple projects in Jira, we suggest keeping the issue in the default OverOps project if possible.
- Issues will still be synced after being moved to a different project in Jira.
- Use the same Workflow Scheme across all projects if using multiple projects, or ensure “Hidden” and “Resolved” statuses are exactly the same across all projects.
- For on-prem Jira installations, disable Maximum Authentication Attempts Allowed CAPTCHA challenge (Administration > System > General Configuration)
Tracking “Resurfaced” Events in Jira
When an event is fixed by a developer and marked in Jira with a status that is synced with “Resolved” in OverOps, the event is moved to the “Resolved Events” view in OverOps.
In the scenario where the “Resolved” event happens again, a new Jira issue will be created where the term “resurfaced” is placed within the title
(i.e. “NullPointerException resurfaced at classname.methodname”).
For a new Jira issue to be automatically labeled as “Resurfaced” in Jira, the following conditions must occur:
- A new deployment is detected by OverOps
- An event marked “Resolved” happens again in a newer release of code
- The original Jira issue (before is was marked “Resolved”) was automatically opened by an OverOps view from which an automated alert was configured
Note that if the practices in this document are followed, then no additional OverOps configuration is necessary to track “Resurfaced” events in Jira.