Why should DevOps leads know reverse debugging?
DevOps is the union of people, processes, and products to enable continuous delivery of value to end-users. Building its culture requires the boss of the team is a renaissance man who can combine technical and interpersonal skills. In this article, I would like to share with you a quick tour of an innovative technology that may change the way companies meet SLA’s conditions in the next few years. I hope that it will help you to be up to date in the world of DevOps technologies.
What is reverse debugging?
When searching the internet for the definition of reverse debugging, you may come across many contradictions. It is because reverse debugging is a relatively new technology that is still dynamically developing. To convey what is reverse debugging in the easiest possible way, one can use an example. Do you know how a flight recorder on the plane works? Reverse debugging is a similar technology, but it is implemented in software, not airplanes. It records everything that happens in your program and delivers you a piece of detailed information about error-root-cause when it crashes.
You may be wondering – how does it work in practice?
Developing software is a game full of surprises, which may disturb the process of continuous delivery of value to your customers. Reverse debugging is a tool that may help to deal with those issues, related to errors appearing in the code. Let’s list its main assumptions:
Automating the process of errors detection
The applications built with an implementation of reverse debugging send information about occurring problems to members of the DevOps team.
Delivering detailed information about the cause of an error
Which version of the application contains the bug? How many users experienced it? Which line of the code is the problematic one? Which values reprocessed by your use caused the problem? Those are essential questions, and answers to are the key when looking for the solution to the problem.
Giving you the details of possible solutions
One of the most critical assumptions of DevOps is a quick response to appearing problems. Reverse debugging supports this process by boosting obtaining information about the current status of the application on production and giving you the details for solutions if some problem appeared. For example, you can check which commit of your use caused the error and to which part of the commit history you have to reset your project to receive a working / bug-free version.
How to get that information?
As we mentioned in the beginning, reverse debugging tools might be compared with a flight recorder. But what does it record? The answer is simple: everything. Everything that happens in an application while it’s running on production. Every value of every variable, method, exception, field, and many more. It brings to mind putting breakpoints on every single line of your code, and saving the results to a separate file, to dive into this data, when the crash appears.
How is this process carried out from the technical side?
First of all, we detect characteristic code structures, and it’s AST tree. That part of the process allows you to get to know what changes we have to provide to create code working with an implementation of reverse debugging. At the stage of compiling the code, we are changing it’s AST tree (by static code injections) to create structures responsible for saving everything that happens in the application.
Right now, you might be wondering: is it a viable undertaking to create a whole reverse debugging infrastructure for an application? To answer this question, I will share with you numbers that my team had the opportunity to observe thanks to cooperation in projects which implemented this technology:
| What developers spend their time on? | ||
| The project without implementation of reverse debugging: | The project with the implementation of reverse debugging: | |
| Coding: | 25% | 67% |
| Debugging | 60% | 18% |
| Other | 15% | 15% |
As you see from the comparison table, the longer a project lasts and the longer we provide maintenance to it, the more profitable it is to use reverse debugging. What’s more, thanks to the existence of some specialized reverse debugging tools, you can use ready-made solutions, instead of coding everything from scratch.
Conclusion
Reverse debugging, therefore, creates a fully automated debugging system. This technology focuses on transforming errors finding practice into a predictable process.
I and my team share the knowledge about reverse debugging and its implementation in .NET projects.
{{cta(’70c008c7-354e-48d9-98c1-e860b22f3c7c’)}}
Our most popular articles:
- Azure Functions: Overview and Common Use Cases
- How to enable error reporting and monitoring for Azure Functions
Our Linkedin profile: