Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Automatically Identify Which Code Changes Caused Errors With Rollbar and CircleCI

DZone's Guide to

Automatically Identify Which Code Changes Caused Errors With Rollbar and CircleCI

See how Rollbar can help you automatically identify code changes that may have caused errors, following up on error tracking after deployment in Part 1 of this series.

· DevOps Zone ·
Free Resource

Learn more about how CareerBuilder was able to resolve customer issues 5x faster by using Scalyr, the fastest log management tool on the market. 

This is the second of a two-part blog post on detecting and correcting errors with Rollbar and CircleCI, by guest contributor Jason Skowronski. Read part 1 here.

When you're practicing continuous delivery, it's essential that you monitor your application so you know that it's performing well after deployments. You need to be notified immediately if something is wrong or if users are having a poor experience so you can resolve the issue quickly. When your monitoring solution can also tell you which code changes caused the error, you can save valuable time troubleshooting. In part one of our blog series, we showed how you can use Rollbar to track the errors occurring after each deployment in CircleCI. Rollbar shows you which new errors occurred and which ones reactivated. For any given error, it can also show you the suspected deployment after which the error first occurred.

Here in part two, we will show you how Rollbar can automatically identify the code changes that may have caused the error. This won't help with errors caused by external factors like third-party APIs or infrastructure problems, but it will help you narrow down errors due to code bugs faster. This will increase your development velocity and help you deliver a better experience to your customers.

We'll continue our example showing how Rollbar integrates with CircleCI and GitHub to make this work.

Track Deployments in CircleCI

To link the error to the source code, first you need to set up CircleCI with your application. We will assume that you already have an account with CircleCI. If not, sign up and then configure the source code repository such as Git and Bitbucket. Then, follow the instructions in part one of our blog series to notify Rollbar when making a deployment.

Send Your Source Maps to Rollbar

If you use JavaScript, Rollbar can map the error message back to your original source code using source maps. If not, you can skip this section.

Source maps are essential to debugging production code. They link the browser's debug output back to the original source code before it was minified or transpiled. In order to display stack traces with your original code, Rollbar needs access to the source maps for your minified JavaScript.

In order to upload the source map, you need to add the Rollbar source map API call before the deployment script in the CircleCI config file.

- run:
     name: Upload sourcemap to Rollbar 
     command: |
     curl https://api.rollbar.com/api/1/sourcemap/ \
     -F access_token=2a208f30fa1b4f0183adb694c4432038 \
     -F version=$CIRCLE_SHA1 \
     -F minified_url=https://s3.us-east-2.amazonaws.com/rollbar-example/
      main.[hash].bundle.js \
     -F source_map=main.[hash].bundle.js.map \
     -F main.js=main.[hash].js
    # Deployment script
  • access_token: The destination project token on Rollbar. This token is generated when a project is created on Rollbar.
  • environment: The deployment environment where the service is deployed. We can configure different environments such as development, staging, and production.
  • version: The deployed application version. This should be repository commit ID. Rollbar will create a link to the repository commit source code if the supplied version is the commit ID.
  • minified_url: The full URL of the minified file. Should start with http: or https:, which we'll strip off.
  • source_map: The contents of the source map, as a multipart file upload.

Identify the Code Version

In order for Rollbar to identify the suspected deployment for an error, it has to know which version is currently deployed. One convenient way to track diversion is using the git SHA number because it uniquely identifies your code at a point in time. Since this version is set when you commit the code, it can't be hardcoded in your application. Instead, we can insert the version at build time.

We want npm, our package builder, to insert the code version automatically, so we'll insert a short script to do that. Let's create a custom ts file named git.version.ts to get the latest SHA revision number of source code.

var fs = require('fs');
import { Observable } from 'rxjs';

let exec = require('child_process').exec;

const revision = new Observable<string>(s => {
   exec('git rev-parse HEAD',
       function (error: Error, stdout: Buffer, stderr: Buffer) {
           if (error !== null) {
               console.log('git error: ' + error + stderr);
           }
           s.next(stdout.toString().trim());
           s.complete();
       });
});
const branch = new Observable<string>(s => {
   exec('git rev-parse --abbrev-ref HEAD',
       function (error: Error, stdout: Buffer, stderr: Buffer) {
           if (error !== null) {
               console.log('git error: ' + error + stderr);
           }
           s.next(stdout.toString().trim());
           s.complete();
       });
});

Observable
   .combineLatest(revision, branch)
   .subscribe(([revision, branch]) => {
       console.log(`version: '${process.env.npm_package_version}', revision: '${revision}', branch: '${branch}'`);

       const content = '// this file is automatically generated by git.version.ts script\n' +
           `export const versions = {version: '${process.env.npm_package_version}', revision: '${revision}', branch: '${branch}'};\n`;

       fs.writeFileSync(
           'src/environments/versions.ts',
           content,
           {encoding: 'utf8'}
       );
   });

Next, add the pre-build script in the package.json. The pre build script will automatically execute at the time of building the application, and it will create a version.ts file with git revision info such as branch, revision number, etc. You can directly access the version.ts file throughout the project.

"scripts": {
   "prebuild.prod": "ts-node git.version.ts",
   "build.prod": "ng build --prod --aot false --sourcemaps "
 }

Tell Rollbar the Code Version

Now we can configure Rollbar's code_version variable so it can track the version number. We will read the revision number using the git.version.ts file. We'll initiate Rollbar in our app.module.ts file as shown below.

const versions = require('../environments/versions');
const rollbarConfig = {
  accessToken: 'f627d5e044a24b9987a23e54c5df352e',
  captureUncaught: true,
  captureUnhandledRejections: true,
  enabled: true,
  source_map_enabled: true,
  environment: 'production',
  payload: {
	server: {
  	   branch: 'master',
  	   root: 'webpack:///./'
	},
	client: {
  	   javascript: {
    	       code_version: versions.versions.revision
  	   }
	}
  }
};

export function rollbarFactory() {
 return new Rollbar(rollbarConfig);
}

@NgModule({
 declarations: [
   AppComponent
 ],
 imports: [
   BrowserModule,
   FormsModule
 ],
 providers: [
   { provide: ErrorHandler, useClass: RollbarErrorHandler },
   { provide: Rollbar,  useFactory: rollbarFactory }
 ],
 bootstrap: [AppComponent]
})
export class AppModule { }

Add Source Control Integration

We would also like Rollbar to integrate with our source control repository so that when an error occurs, it can automatically link us to the proper line of code. It can also tell us when there are code changes that break the deployment.

Below, you can see that we have configured in integration with GitHub. Make sure to have the project root configured in Rollbar as shown below; it's the source code location where the root is placed. If this is not configured properly, Rollbar will not be able to link the source code to an error. In this example, the project root is /.

Run the Test Cases to Generate Errors

Now we will test all the pieces that we just put together. We will execute our build on CircleCI, run the application, then generate a test error. This will send a test error to Rollbar so we can see how it identifies the deployment and source code next.

Find the Root Cause of Errors

Check the Rollbar dashboard for the error logging on the Items menu tab which will show the error details along with the link to the source code file that caused the error. The error will show the suspected deployment version along with the piece of code causing the error.

Clicking on an error item in the list, we see the item detail page. Next, to the traceback, we can see a link to the source code causing the error.

When you click on the link it will directly open the class in the GitHub repository and highlight the changed piece of the code, depicted in the next screenshot:

A second way to investigate the cause of errors is by using the Suspect Deploy tab. It shows the revision where the error was first observed, along with changes that were made to the code since the previous deployment. We can see the commit message indicating that an error code was introduced.

Now, you can go directly from an error reported in Rollbar to the exact deployment and source code that likely caused the problem in a few clicks. No more hunting through noisy log files and searching through the source code to find the responsible line. This will save you time when you're troubleshooting issues and will help you get your production systems working faster.

Find out more about how Scalyr built a proprietary database that does not use text indexing for their log management tool.

Topics:
devops ,continuous integration ,rollbar ,tutorial ,automation ,error tracking

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}