Rookout revealed today it has extended its eponymous debugging tools to include third-party applications.

Shahar Fogel, Rookout’s CEO, says most organizations today are building applications that rely heavily on code or modules developed by a third party. Rookout now makes it possible to analyze and debug that code before it is incorporated within a larger application environment, Fogel said.

That’s crucial, because many of the operational issues a DevOps team is likely to encounter can be traced to flawed code written by someone outside of the IT organization, Fogel said. This new capability will reduce the amount of time DevOps teams spend trying to deduce the root cause of an issue, he said.

Many IT organizations erroneously assume that all the code running in their environments has passed through a continuous integration/continuous deployment (CI/CD) environment, Fogel said. In reality, it’s not uncommon for developers to deploy code directly into a production environment in the name of expediency. Not all of that code, however, may have been written by the developer. Many developers wrongly assume the code they download from a repository was properly vetted and debugged.

Rookout now makes it possible to debug both open source code and proprietary code written by a third party or present on an application deployment platform, said Fogel. Rookout collects the local variables, function arguments, tracing data, call stack and other relevant data, and can identify issues down to specific lines of code. Support for third-party code has been extended to the call stack level to enable developers to see how code execution flows across their own and third-party code.

As more responsibility for applications shifts left toward developers, organizations need to provide them with tools to analyze applications and the platforms they run on. Beside building applications faster, one of the primary theoretical benefits of DevOps is the notion that developers can build more resilient applications, because it’s ultimately their responsibility to remediate any issues that arise after an application is deployed in production. In practice, that’s difficult to achieve when developers have no visibility into code that they didn’t write themselves.

Going forward, there’s going to be a lot more third-party code running in production, as developers reuse application code encapsulated in containers downloaded directly from registries, Fogel said.

The degree of accountability developers have for their appliations’ code currently varies widely by organization. However, given the right tools, and enough time, most developers would prefer to debug both the code they write and any they have incorporated, even if it were written by someone else. That desire, however, requires more time to build and test applications. Of course, it’s worth the tradeoff if developers encounter fewer incidents that require developers to debug applications after they are deployed in a production environment.