Creating A Deployment Tracking Workflow With Raygun

Here at Raygun, the development team use Raygun, on Raygun itself. I guess when you’re developing the best error reporting solution on the market, you should use your own product to identify bugs, so we often see a software error report inside of Raygun, that’s been identified by Raygun and sent to Raygun. It’s kinda cool.

We use Raygun’s Deployment Tracking feature internally to identify problematic deployments and triage errors. Personally, I use it see what other errors first occurred in, or reoccurred in, a deployment, which gives me a better idea of the root cause of bugs that cause multiple (different) exceptions. I’m getting a little ahead of myself though; so I’ll run through how we have the system set up first, then explain how we use each of the features.

Getting deployments into Raygun

Raygun uses Octopus Deploy to push our code to the production environment, but we have support for the most popular deployment tools on the market. For the website project, our deployment process is the following:

1. Deploy the Raygun.Website package to the “web” machine group
2. Register the deployment in Raygun
3. Tag the deployment in Teamcity
4. Notify the team in Slack that the deployment succeeded/failed

We register the deployment in Raygun using a Step Template – there’s more information on how to set this up in the docs for Octopus Deploy. After the first deployment step has succeeded, that Powershell script will send a JSON payload to Raygun that looks something like this:

{
  apiKey: "Our Raygun Api Key",
  version: "1.2.3.4",
  ownerName: "Jamie",
  emailAddress: "jamie@example.com",
  comment: "# master\n\n* Added Deployment Tracking to Raygun\n\n#### Jamie",
  scmIdentifier: "75c046c625bbd9bc4c576312878b11c4fa7efeb4"
}

This gives us the following deployment in Raygun:

Using deployment tracking for release management

Once the code is released, we play the waiting game. An hour later as I’m sitting down to have my lunch: disaster strikes! A new error has occurred, and Raygun has emailed me about it. The deployment tracking endpoint is failing to validate the email address people are sending us! I check out the error page – looks like someone sent us a deployment with no email address. That should be fine…

The Commits tab on the Deployment page can help here by showing us what commits were released in this deployment.

Oh. I added that fancy email validation regex, and must have forgotten to add an empty check before it. Whoops. The Commits tab links through to each of the commits on Github so I can see the code that changed in that commit, and easily find it again.

I fix the problem, and while the build is running I go back to the error and mark it as Resolved in Version 1.2.3.5. This means Raygun will stop emailing me to say the error is still occurring, unless the version is greater than or equal to 1.2.3.5. Once the build is done and deployed, I can jump back into Deployment Tracking and see that the new release is doing a lot better.

It really is that simple to create an awesome workflow surrounding errors and deployments, giving you peace of mind that each release is tracked and associated errors identified. Deployment Tracking can tell you which errors have been introduced with the new release, which are still occurring and which have been fixed. That’s why Raygun is the essential tool in every software developers toolkit.

Want to give this a go yourself? Raygun offers a free 14 day trial, get started today!