Let’s face it, nobody wants to deal with a complex bug fixing workflow. Communication issues and unseen errors often trip up deployments and even take projects back to the drawing board.
What does a highly tuned bug fixing workflow look like? Not as complicated as you may think. In fact, it could be a case of simplifying the steps in your current process.
We’ve designed a simple yet powerful bug fixing workflow which will help to pinpoint the root cause of performance issues in your software. We’ll be using our new two-way sync feature with good friends Atlassian.
The tools we’ll be using are:
- Raygun Crash Reporting which is used as the software for detecting errors in your code
- HipChat for communicating and allocating errors to your wider team
- Bitbucket to serve as the Git repository for any code creating an error
- JIRA Software as the issue tracking system which will allows you to plan, track, release and support your software
Watch our short video for an overview of a bug fixing workflow in action:
Below is an example workflow of how to manage and fix bugs that occur in your software:
1. Raygun sends an error to HipChat
Here you can see an exception that has been reported to HipChat from Raygun Crash Reporting:
A team member is able to write any notes corresponding to that error using the chat screen. This is particularly useful for project management and visibility on an error status across your team:
2. Get the diagnostic details you need
Click on the error inside Raygun Crash Reporting to look at the deeper diagnostics of the error (including the stack trace). When clicking the Bitbucket icon next to the stack trace code lines, we can go directly to the location of that code in Bitbucket:
Here you can see the exact line of code in which error occurred, aiding a faster fix:
3. Keep your team organized using JIRA Software
Inside Raygun, click on the integrations button, and choose ‘JIRA’ from the drop down menu. You can see the new JIRA Software issue from the exception itself:
Click on the error inside Raygun to be taken to the corresponding JIRA Software issue:
Using Raygun’s two-way sync with JIRA Software, marking the issue as ‘Done’ inside the dashboard will sync that information back to Raygun. The exception is automatically moved to the ‘Resolved’ group in your Raygun dashboard:
Implementing a simple bug fixing workflow will allow you to have a detailed high level overview of exceptions that are thrown by your software. A smooth bug fixing workflow creates team-wide visibility on errors so they are found in your workflow well before your customers experience them.
If you’d like to replicate this workflow for your company, head to the appropriate documentation below:
Log in or take a free 14 day trial of Raygun Crash Reporting
3 Comments on “Raygun creates a seamless bug fixing workflow for Atlassian HipChat, Bitbucket and JIRA Software”
This is good stuff and would love to get it going, but I don’t really see the need for Raygun to ask for all of these permission when trying to set up the Bitbucket integration, when all I want is for Raygun to show the Bitbucket links in the stack trace:
– Read and modify your account information
– Read and modify your repositories’ issues
– Access your repositories’ build pipelines and configure their variables
– Read and modify your team’s project settings, and read and transfer repositories within your team’s projects
– Read and modify your repositories and their pull requests
– Administer your repositories
– Delete your repositories
– Read and modify your snippets
– Read and modify your team membership information
– Read and modify your repositories’ webhooks
– Read and modify your repositories’ wikis
Seems a bit excessive to me.
Thanks for your comment Frederik, we believe a lot of this is needed as we integrate with issue tracking and deployment tracking for commit history, so we ask for it all at once. The link to source piggybacks on those other features, hence why we ask for all those permissions. We will also review the permissions requested by the integration as a couple of them do seem odd (like delete repositories.) I hope that sheds some light on our thought process for this workflow! Thanks again, Freyja
Pingback: Atlassian Summit Review: A full breakdown of the 2016 conference