How RevDeBug can help shipping software at a scale. Part one.
Hewlett Packard Enterprise / DXC.Technology is a globally renowned software house. Their Polish division delivered a great software solution for processing and registration of every license plate in Poland.
The solution works online in every county’s magistrate in Poland and is owned by the Polish Security Printing Works (responsible for printing banknotes, government bonds and IT systems for Polish government). All details about cars, their owners and license plates are processed by it.
It means a lot, and I mean a whole lot of data. It has to work flawlessly and without stops. You can’t just take it down to maintenance and every error has to be fixed instantly.
Opportunity: Ideal conditions to use RevDeBug!
How did it all get started?
First, we began from a pilot implementation where testers would use RevDeBug to record bugs and issues, the ones they have already found or those they were trying to replicate and/or reported by users. After signing the appropriate NDA’s we could look up into samples of the source code and try to recompile the application using RevDeBug’s compiler.
Prepared with that knowledge, we met for the first workshops where we helped to attach RevDeBug to compilation pipeline on a build server so we could perform a first run of the solution under RevDeBug’s recording. That was the time we understood what “a lot of data” really meant. The experience can be only summarised as painfully slow. Additionally parts of the more tricky application’s code wasn’t recorded at all.
We were not really prepared for such a slowdown as we couldn’t see the data processed by the solution. So we’ve gone back to the drawing board and delivered a mechanism for limiting the recorded data so it was possible to not record parts that are not vital for application’s logic but generated by gigabytes of data.
Additionally, we provided a better way of handling large files, compression options and an advanced search mechanism. After getting back to HPE/DXC.Technology we deployed the changes and made the needed fixes on the build server so their testers and developers could work with RevDeBug.
The next milestone is enabling a dynamic on-demand recording for the testers to further limit what is being recorded and include only the timespan that is crucial for the issues they are working on.
Our aim at the moment is where “It works for me” shouldn’t be heard while shipping future releases of the solution.
After that we want to roll out RevDeBug’s usage to other applications by HPE/DXC.Technology.
We use RevDeBug with one of our solutions to record bugs while testing. It’s an interesting alternative for traditional debugging and I see it’s great potential for making fixing bugs quicker.
Software Architect and Team Leader
Hewlett Packard Enterprise