Docs Pricing Blog

Environment Details

Environment Details

The issue details page will now highlight information about a specific environment, with an additional focus on the most recent release.

To get started, you simply need to configure the release and environment attributes in the SDK:

Raven.config({
    release: 'abcdef',
    environment: 'production'
});

By default we automatically select the most production like environment, and overlay details from there. The First Seen and Last Seen attributes will reflect the chosen environment, and the frequency chart will highlight occurances from the most recent release in that environment. This makes it easier than ever to identify issues which are only happening in legacy versions of your application.

Additionally, we’ve added a few other useful tidbits:

  • If you’re using a multi-staged release process, you can also select a different default environment via [Project] > Settings.

  • Rules can now create conditions which match the ‘environment’ attribute allowing you to restrict alerts to only specific release stages.

  • We’ve tweaked tooltips and chart renderings to be more visible than ever.

We’re going to keep making updates around environments, building them into first class citizens in Sentry. Let us know what you think, and be on the lookout as we iterate on this concept.

Happy Friday!

Introducing support for iOS, macOS, and tvOS apps

Preview
Sentry and Cocoa

Huge news! After a limited release, we’re excited to open up preview support for iOS, macOS, and tvOS to everyone.

In short, we’ve beefed up our Swift and Objective-C clients so that they can now send proper crash reports. This enables us to do some really neat things like process the stacktraces on the server:

Cocoa Traceback

Words don’t quite do it justice, so we put together a screencast to show off just how awesome it is:

For more info on the Sentry Swift client, including setup and usage instructions for both CocoaPads and Carthage, as well as how to send us your debug symbols, head on over to our Cocoa docs.

As mentioned, Cocoa support is still in preview. We’d love to become your new favorite iOS/macOS/tvOS crash reporting tool, so make sure to let us know how we can make your life easier.


P.S. Big thanks to our friends at BYTEPOETS for helping us collect system symbols for older versions of iOS to improve our symbolication quality.

Releasing Open Source Sentry

Inside Sentry is a series in which we talk about how we build Sentry, including the technology we use and the workflows that move us forward.

Sentry Versioning

While thousands of teams use hosted Sentry, tens of thousands are running it on-premise. Keeping on-premise deployments up-to-date with the latest features and fixes is a priority for us. Fresh off our latest Sentry 8.6 release, we wanted to explain how we version Sentry and why it matters to you.

One of the benefits of using SaaS such as getsentry.com or other closed-source projects within an organization is continuous deployment. Continuous deployment is the idea of deploying your product as soon as changes are committed so that your users can get features and fixes as soon as possible.

Running continuous deployments on-premise can be tedious. Shipping versioned software alleviates the pain of trying to guess what is in your package. Operations teams don’t want to update their Sentry install multiple times per day, and can rest easier knowing that if they identify a problem, they won’t be the only team in the world running that specific version.

Prior to 8.0, we had a very loose schedule when it came to cutting releases. Our last major release was 7.7.0, almost 7 months before 8.0 dropped. To ensure that we make the process of updating on-premise deployments of Sentry easier, starting with version 8.0, we began to follow an official release schedule.

The Schedule

Sentry is loosely versioned around semver, but in practice, this is much harder to adhere to compared to libraries. But what this means for us is:

  • Major versions (e.g. 8.0, or 9.0) are massive changes, such as a complete UI refresh or major infrastructure changes.
  • Minor versions (e.g., 8.1 or 8.2) contain things like database migrations, new features added, and changes in behavior. We cut minor versions from our master git branch and will release them on the 1st of each month.
  • Patch versions (e.g. 8.1.1 or 8.1.2) include critical bug fixes only. We will not introduce database migrations or change in behaviors in a patch release. Patch versions are cut periodically between our minor releases as critical bugs are addressed. There should be no risk in upgrading between patch releases.

Our new process brings Sentry’s open source compliance a step forward, and helps set expectations for our customers and users. The monthly schedule is more predictable and will help to establish a regular schedule of incremental updates, rather than massive, unpredictable releases. Additonally, operations teams will know what to expect when upgrading their instance, and will have an easier time scheduling and performing regular upgrades, cutting down on the number of stale deployments of Sentry in the wild.

The Process

Sentry is primarily a Python webserver, but it also includes a JavaScript application to drive our UI. For those that have dabbled into Python packaging and/or JavaScript packaging, there’s not a straightforward answer on how to ship a package including both. At the end of the day, we want our users to be burdened as little as possible with installation.

We have two different distributions, a Docker image on Docker Hub, and PyPI (the standard Python package index). When packaging our application, we pre-compile the JavaScript application, and bundle our documentation into the derived release artifact. Our setup.py does all of the bundling for us and removes the requirement for developers to install the JavaScript and documentation tool-chains.

Docker makes this much simpler, and we ultimately just install this PyPI package into an image and ship to Docker Hub. In fact, it is now our recommended way to install Sentry inside your production systems.

The Future

With a more evolved release cycle, users now have the ability to view a detailed report of what is going into the next release via our GitHub Milestones. These milestones are planned by our engineering team at the beginning of every month and go through a checkup in the middle of the month.

Have an idea for a feature that can fit into this release cycle? Open an issue on GitHub.

See you at 8.7!

Workflow Notifications

We just shipped an overhaul to workflow notifications in Sentry. The new system splits Sentry’s notifications into two core systems: alerts and workflow. Alerts are very much the same as they always have been, but the new workflow emails are focused on improving the triage and issue management workflows.

Participation

The first thing you need to know about the new notifications is that they revolve around participation. If you use GitHub, you’ll feel right at home here as things work in a very similar way. By default you’ll participate in every conversation on a project, but you can change this to be explicit via your account settings. We’ll also explicitly mark you as participating the first time you interact with an issue, such as leaving a comment or changing the state.

Participants

All workflow email notifications are based purely on whether you’re participating or not, and will sidestep any rules configured for a project. This also means you can disable alerts and still receive workflow emails.

Settings

If you’ve previously opted out of receiving alerts, that won’t change. We have however opted you into workflow emails project-wide, which does mean you’ll now receive notifications for regressions. If you wish to change this you can do so from the Workflow email setting in Account › Settings › Notifications.

Settings

Changing the setting to only notify you when you’re participating will give you full control of when you receive emails. Don’t worry, as we’ll still automatically subscribe you to issues in which you enter as a new participant.

Expanded Notifications

In addition to splitting off notifications into two categories, we’ve also added several additionally activity-based notifications, as well as overhauled the existing.

Workflow notifications will now be generated in the following situations:

  • an issue is assigned or unassigned
  • a new comment was left on an issue
  • the state of an issue changes to resolved
  • an issue is reopened due to a regression
Email

Looking Forward

This is just the beginning of a large number of changes we’re making to notifications. We’re focused on making sure they work well in both small and large organizations, and you’ll be seeing some great additions (like a weekly summary) show up in the next few weeks.

Log Angular 2 Errors with Sentry

Sentry + Angular 2

Angular 2 is almost here, and so it’s with great pleasure that Sentry now officially provides Angular 2 support through our browser JavaScript SDK – including full support for use with TypeScript.

Getting Started

Install the sentry/raven-js package:

$ npm install raven-js --save

Configure SystemJS (the new default package manager for Angular 2) to locate the raven-js package:

System.config({
  packages: {'raven-js': { main: 'dist/raven.js' }},
  paths: {'raven-js': 'node_modules/raven-js'}
});

Declare a custom ExceptionHandler that calls Raven.captureException, and initiate it as part of your bootstrap call:

import Raven from 'raven-js';
...

Raven.config('your dsn').install();

class RavenExceptionHandler {
  call(err:any) {
    Raven.captureException(err.originalException);
  }
}

bootstrap(MainApp, [
  provide(ExceptionHandler, {useClass: RavenExceptionHandler})
]);

Once you’re done, Sentry will now start capturing both native JavaScript errors and errors occurring deep inside your Angular 2 application. For more in-depth instructions, take a look at our dedicated Angular 2 documentation.

TypeScript + Source Maps

The Raven.js project now provides a TypeScript language declaration file for static analysis of Raven.js API calls inside of your Angular 2 projects.

Additionally, Sentry supports Source Maps, which means that you can see your original TypeScript code in error stack traces.

TypeScript stack trace

Check out our documentation to see how to produce source maps as part of your build process and pass them to Sentry.