Keep Your Projects Nice and Organized

Despite the strong lack of interest that many of us have in organization, it’s not debatable that having things properly organized makes it easier to stay focused on your work. Forget about all those random studies that say messy people are smarter. That doesn’t mean you wouldn’t get more done if you took the time to straighten up your crap.

What does this have to do with Sentry? Did we write this just to shame you about your messy desk?

No, we would never do that. Even though our desks are immaculate.

What this has to do with Sentry is that the better your projects are organized with us, the easier it is to manage and tackle errors. Maybe you currently pour all your errors into a single project, and, if so, that’s a-ok, but if you’re expecting or seeing more than just a small number of events, then you can absolutely benefit from a little extra project organization.

Why?

There are two notable reasons to organize your app into multiple projects within Sentry:

• You can more easily assure every developer is looking at projects that are relevant to their work. This makes their issue stream far more useful, since they’ll only see the errors that they might need to jump on. If every dev is seeing every error then it’s easier to get inattentional blindness and miss issues that need attention.

• Alert notification settings are managed at the project level. You could have notifications going into PagerDuty and Slack in one project, but only Slack and mail in another.

Each of the reasons ultimately lead to the same thing: a more easily managed flow of information.

How might you break up your projects? Well, you could consider doing so by:

Service

Is your app made up of several micro-services? Split those into projects accordingly.

If you have a monolithic codebase, then it’s helpful to at least have Backend & Frontend projects. That’s exactly what we do here in our own usage of Sentry.

In this case, think of Sentry projects like GitHub repos. You wouldn’t dump the code for every part of your app and website into one repo. Why would you take a different approach for the errors generated by that code?

Language

A nice feature of Sentry is that an individual project can support multiple languages. If you want to look at errors from your PHP based web app and from your Swift based iOS app in one project, you’re more than welcome to do so.

That said, just because you’re welcome to do so, doesn’t mean it wouldn’t work better if you gave each language its own project. Then the three devs on your team who absolutely love Go can do all the debugging for it when errors come through.

And JavaScript is pretty noisy, so even if you want to mostly keep all your languages in one Project, your experience will probably improve if you at least separate JavaScript out into its own space.

Take a look at our detailed documentation on how to properly create and manage a new project.

No one likes organizing things, aside from interior designers and trained wizards from Hogwarts who know the spell for picking objects up and moving them around — that spell is Locomotor, by the way. Be sure to flick your wrist just a bit to the right when casting to make sure it works.

The fact remains, though, that a little extra organization of your Sentry projects can go a long way towards making the task of tackling errors that much more pleasant (in so much as fixing errors is ever pleasant). If you have more questions about this, please reach out to our support engineers. They’re here to help. And also to code. But mostly to help.