What is RevDeBug?
Say hello to Time Travels
Estimated reading time: 3 mins
Last edited: 18 Apr 2019
Salvation for everyone suffering from software errors
RevDeBug is a developer tool that can be compared to a black box on an airplane. It records all flight parameters so that in case of failure or disaster, the recorded details can be used to determine the causes of the accident. Similarly, RevDeBug records each line of the running program code so that in the event of an error - due to the recording, it is possible to quickly determine the direct cause of the bug.
Example of use: Let us assume that there is a program for processing and booking invoices in the company. An employee arriving in the morning to work states that during the night during operation one of the invoices generated incorrectly, ie with bad data. In the current situation, by reporting such an error to the developer of this software from the programmer you can hear that "it works on my machine” or that there is a bug of another program that works with it.
When using RevDeBug the whole event was recorded so the employee of the software producer will download the recording in which he will search the moment the error occurred, it will quickly diagnose what was the reason for it and where is the source of the bad data that caused the error.
RevDeBug is right now compatible with Microsoft .NET frameworks/ecosystem, such as .NET, .NET Core, Xamarin, Unity, and microservices AWS Lambda, Kubernetes, Docker and Azure.
RevDeBug for Personal Usage
This package of features is prepared for a single developer, works inside the Integrated Development Environment (Visual Studio extension), without connection to the application on production:
The benefits we give in: Tools supporting the programmer in the understanding of code on his own machine.
Large programming projects are characterized by a huge level of complexity. RevDeBug giving developers detailed inspect on “how the code works”, thanks to the implementation of reverse debugging. Standard Visual Studio debugging tool contains instruments such as step-into, step-over or step-out. RevDeBug allows you to travel in the opposite direction, to inspect what causes the bug in your project. How does it look like? Check here.
RevDeBug for Developers Team / for Enterprise
These tools allow you to monitor, inspect, manage and repairs software errors on every stage of application development.
The benefits for programmers that we give in: Tools supporting in the understanding of code and how it works on production.
The opportunity for remote recording of software (combined with reverse execution) is a game changer. The ultimate vision is full "Software Accountability" (What did my software really do, versus what I expected it to do). In the short to mid-term it's about replacing or rather supplementing logging, which given the complexity and speed of software deployment isn't good enough today and never will be (i.e. if you knew what to log then you probably knew what the problem was - not possible). In some markets, there is no real solution - serverless, microservices, DBaaS, etc - to address software quality issues in production. In the DevOps flow there is a huge gap, lots of tools aimed at static analysis of code, yet still, quality issues remain and dynamic analysis tools are required.
The benefits for management that we give in: Tools supporting the management and DevOps team in the managing the software errors.
You are receiving detailed information about how many exceptions are occurred on the production and how many users are affected by them. It’s connected another feature which we are giving included: DevOps Monitor
Is designed to give our users a detailed inspect on:
- How many users use a particular version of their application? In which countries are they located?
- What errors occurred at the application at users computers? How many users are affected by them?
- What versions of the application causes the error? To which version of application we have to rollback to receive a bug-free version?
- What errors were detected on tests? How many times did they occur?
After this theoretical introduction, let's go to practice!