Case study: Hewlett Packard Enterprise / DXC.Technology
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 an excellent software solution for processing and registration of every license plate in Poland.
The solution works online in every county's magistrate in Poland. It is owned by the Polish Security Printing Works (responsible for printing banknotes, government bonds, and IT systems for the 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 you have to fix 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 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 the 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 "many data" really meant. The experience can be only summarised as painfully slow. Additionally, parts of the more tricky application's code weren't recorded at all.
We were not 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 not to mark parts that are not vital for the 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 limit further what RevDeBug records and include only the timespan that is crucial for the issues they are working to handle.
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.