Debug production with Remote.It

Introduction

Debugging in production is surely a mission-critical process. It can always happen even with preparation, best deployment practices, 100% code coverage, or manual testing.

Most of the time, when a bug occurs in production, the first idea is to reproduce the bug locally and then fix it by making another deployment. But what if the issue is not about the code source? It can be a service used on the machine, for example.

Debugging in production is hard because when developing, the developers have control over the environment, the scenarios are well known and it’s easier to debug by putting breakpoints anywhere in the code to stop and examine the state of your application.

You can even dump your development database to get rid of certain bugs.

Thus, having a safe and simple process to debug in production can be significant when some scenarios of issues appear.

Why debug in production?

But with all of that, why debug in production? Well, it comes with some advantages.

• Development speed: Having the right tools to find the root problems and correct them without having to reproduce the error locally is definitely a great advantage in terms of velocity. This can be done via remote debugging (more on this later) by a developer directly accessing the server.
• Fast Issues fixing: In a world where a lot of people use tech services, 10 minutes of downtime is enough to lose a lot of consumers and also money. Having an efficient debugging strategy can help address the issues as soon as possible, then saving a lot of value for businesses.

5 safety tips

If you need to debug in production, here are some tips you can follow:

• Using Non-blocking debuggers: When debugging in a production environment, it’s important to not block the services running on the machine. This will block users or clients from using the services but also affect the user experience.
• Logging: One of the best ways to quickly debug in production is to log. And log effectively. Depending on your business, logging can quickly help you navigate through the events occurring on your services and identify issues.
• Defining the scope of debugging: For example, if you have a server running your applications inside docker, you might want to only debug on the container running the service from which the bug is coming.

This will reduce the risk of interrupting other critical services.

• Performance monitoring and Exception monitor: Having tools such as Sentry or Bugsnag or even Datadog can help have more details about bugs.

Sentry or Bugsnag for example will give you a traceback you can analyze to quickly identify the issues. You’ll have more information such as the state, the requests, and much more.

How to debug with remote.it?

Logging

remote.it gives you access to many pieces of information such as the events occurring on your machine called event logs, the connections logs, but also the list of your devices and their status.

These pieces of information can be valuable to have a better understanding of how your machines are actually working. And for example, by identifying a machine that may have problems, you are limiting the scope of debugging, thus making it faster and easier.

Having to jump between many systems or machines to find the bugs only adds more stress to deal with the issue.

SSH

If you are looking to debug in production, it’s probably certain you’ll have to access the machine. remote.it helps you simplify the way you connect to your machines via one and expiring links but also without managing SSH keys.

This can be useful to quickly access your machine and even grant permissions to the other members of your team to these resources just by using their email addresses.

And the big advantage is the security: No port forwarding is needed to allow this access. This means no attack surface for hackers.

Service Health

With remote.it, you can have access to information such as your device’s status.

This is really useful because you’ll get notified when one of your devices goes down. You can even configure webhooks to receive events with more details you can use depending on your needs.

Conclusion

Delivering a bug-free application to consumers is never a perfect process. Unprecedented scenarios can still arise, either because nuances were missed in the development or testing phase.

At the end of the day, debugging in production depends on one thing: data. The more valuable data you have, the quicker it is to solve the issue.

Having a production debugging strategy in your team is a must. And having remote.it as part of your debugging tools will definitely accelerate things.

‍