We've all been there: experiencing the primal fear and anxiety surrounding a deployment — whether new code or just updates — and sending it out into the world for our users to, hopefully, enjoy. The nature of the beast that is software development shines a glaring light on imperfection. Errors will inevitably occur.
Table of Contents
- No Release Fridays
- What is Error Monitoring?
- Demonstrating Error Monitoring in an Application
- Step 1 – Create a Rollbar Account and Set Up a Project
- Step 2 – Integrate the Rollbar SDK in a Vue.js Application
- Step 3 – Get Acquainted with Error Monitoring
- Step 4 – Deploy with Confidence
- Step 5 – Relax and Enjoy your Weekend
So how do we deploy with confidence rather than anxiety?
The answer is: error monitoring. When we say "monitoring," we're not just capturing discrete errors through try-catch blocks, logged messages, and alerts. We're instrumenting our application to report on the overall health of an application so you'll know not just when a component fails, but also when it's not performing as expected. Good error monitoring also means knowing where problems are occurring in our application and tracing them back to the codebase.
Many development organizations have established strategies to deal with the pain and anxiety of deployments, including the infamous "No Release Fridays." Nobody in their right mind wants to deal with application issues over the weekend!
Some teams staff lead developers to oversee the release, assign overnight and weekend on-call duty, and have business analysts ready at the helm to run through a battery of manual sanity check tests to ensure that things look right post-deployment.
Another strategy might be to beef up the testing, staging, and QA cycles before deployment, much to the detriment of engineering velocity and deployment frequency. But at a certain point, too much testing and QA ends up being counterproductive and expensive — keep in mind that no software will ever be perfect.
While these strategies do help in identifying issues early on, they are not representative of the regular usage of an application in production. End-user behavior is not predictable. Dependencies on third-party services may fail or change unexpectedly. What development organizations need today is a way to find a healthy balance of pre-deployment QA and testing paired up with effective monitoring of the application across pre-production and production environment. This is error monitoring.
Error monitoring is a lot more than quietly logging stack traces and crash reporting. Error monitoring is used to provide insight into critical aspects related to the overall health of an application. These aspects include errors that the application code may be throwing, whether requests and transactions are completed promptly and successfully, and whether third-party dependencies are available when needed and are functioning correctly.
For web developers, key areas to instrument code would be on all service calls, interfaces to third-party libraries (as well as those linked via CDN), retrieving and parsing information from local storage and cookies, caught application exceptions, as well as uncaught application exceptions.
While this could be just about any web dashboard project, my recent work has been in IoT applications. This sample application is responsible for observing water level data readings from IoT devices in the field to view history and identify trends. So it adds another twist to the typical deployment anxieties: interacting with remote, self-contained systems that aren't frequently monitored by people. We have to take extra care to stay aware that they're functioning correctly.
Full source code (complete with Rollbar code instrumentation) for this example is available on GitHub. The app is shown below.
First create a Rollbar project. In this activity, you will name your project. In this case, the project name is "Water Level Dashboard".
Now we'll integrate Rollbar into the app. The next screen will show an example of how to integrate Rollbar into your specific application. We will skip this step for now, as we will follow specific guidance available for Vue.js.
We are now ready to integrate the Rollbar SDK into a Vue.js application. We will be following the guidance for the Vue.js quick start.
In a terminal window, in the root of your source folder, install the vue-rollbar package from npm:
npm install vue-rollbar --save
Open main.js and add the Rollbar SDK by adding the following:
var Rollbar = require('vue-rollbar')
Configure Vue to use Rollbar by adding:
Finally, add a test debug statement so we can see something pop up in the Rollbar Dashboard for the project:
The main.js file should now look similar to the following:
After saving main.js and running the Vue application, the Rollbar SDK will send the debug message to Rollbar so that you can see it on the Dashboard.
Drill into the message by clicking on the link, and you can mark this message as Resolved. Once resolved, the message will no longer be deemed active and will no longer display in the Dashboard view.
Feel free to remove the test debug message from main.js.
Let’s take a moment now to review how to add instrumentation to the code and view the results of these errors in the Rollbar dashboard. For this example, we’ll look at instrumenting code surrounding a third-party service call.
When issuing a service call, multiple things can go wrong: the service could be unavailable, the result could be in the incorrect format, or some other HTTP error could occur. There is a service call that takes place in the Device Detail component (src/components/DeviceDetail.vue line 105). This code should catch any errors processing the result of a successful call, as well as any general failures of the service itself.
Note that, in this code, the logic responsible for processing the response from the service is surrounded by a try/catch block. Therefore, it logs any issues arising from the translation of the results.
The service call can be a call to anywhere. In this case, I have it calling to a service running on my localhost that I have full control over. I exercised this code by first modifying the service host disallow the call through CORS, then altering the method to return an unauthorized HTTP code, followed by increasing the latency of the service call to over 1 second, and finally throwing an exception in the result processing code to simulate a result that is not processed correctly.
Let’s take a look at what the Rollbar Dashboard looks like now.
By drilling into the Network Error item, you will see that the Unauthorized Error and the CORS error are available here. Rollbar automatically categorizes related errors to avoid flooding the dashboard with unique instances.
Rollbar also has the ability to see the events that lead up to an error. I’ve drilled into the manually thrown application error and can see that Rollbar has recorded the events leading up to the exception.
Code instrumentation and error monitoring is a great practice, but you’re probably wondering: how does this help deploy applications with more confidence?
Depending on your Rollbar SDK configuration, your application will report both caught and uncaught exceptions. When new code is released, all errors are captured by Rollbar and, depending on the severity, notifications can be sent automatically through tools such as Campfire or Slack.
Many times these notifications will be received before a user even has a chance to complain!
Beyond this, Rollbar can become a critical part of your Continuous Integration/Continuous Deployment (CI/CD) cycle. Source control integrationenables Rollbar stack traces to link to the specific file causing issues and resolve the problems with traceable source control commits. Rollbar also provides the ability to version code, so that when an error occurs, you will know precisely which version of the source code is responsible.
Deployment tracking is another highly useful feature of Rollbar. It allows for integration with a CI platform such as Jenkins, where you can see deployment history, associated code version, which commits were part of the deployment, and which commits remain undeployed.
Rollbar has support for multiple environments (development, QA, staging, production, and so on) and treats them separately. This means Rollbar captures errors even before production source code deployment, so it can be corrected before causing an issue. Multiple environment support also covers distributed production systems, so if you have an application deployed to various regions on a cloud host, errors can be reported in the context of that specific host.
In this article we discussed some of the pain points surrounding the fear of deploying new code into production and how error monitoring can help. In particular, we demonstrated how to use the Rollbar SDK in your project, and discussed how incorporating Rollbar into your CI/CD process can virtually eliminate the fear of release day, yes, even with deployments on a Friday!
Like this article? Follow @rollbar on Twitter
This content is sponsored via Syndicate Ads.