PVS-Studio analyzer already provides dozens of integrations with various tools and services, and in this article, we'd like to explain why.
We develop and sell PVS-Studio static analyzer with a wide variety of features such as command-line utilities, diagnostic rules in various categories, support utilities, and so on.
Behind "so on", we usually mean numerous integrations with third-party tools (plugins, extensions, and usage scenarios). But why do we hide them? You can see that by yourself: the first PVS-Studio integration was a plugin for Visual Studio 2005, released 18 years ago. Today, the analyzer integrates with more than three dozen other development tools: IDE plugins, game engines, code quality platforms, build systems, CI/CD platforms, and more.
Keeping all these integrations up to date and working properly takes a lot of effort, and now we'll explain why we do it in the first place.
Convenience of use
The most daunting thing when you think about integrating a new tool is the complexity of the implementation process. What's more, this feeling arises among both managers and engineer—don't forget about the principle of "If it works, don't touch it".
And it's okay because every company or team has its own approaches and tools, and when it comes to implementing something new, it seems complicated. And often it's not just about inner feelings—the implementation process is often quite complex.
Actually, that's the main reason we're working to develop integrations for popular tools. If you're already using a specific set of IDEs or a particular web dashboard for DevSecOps, why force you to use something we've come up with? Instead, we suggest expanding the familiar set of features to include the ability to use our tool.
Also, different people on the team may need different tools: developers search for the easy run of the static analyzer during development, and manager would like to quickly view warnings' statistics in a web dashboard. That's why we're creating so many integrations.
Usage scenarios
Yes, the static analyzer doesn't usually seem like a hard-to-use tool, but its initial configuration varies greatly depending on the project and the required use cases.
Let's take a look at some use cases using specific examples.
On-premise analysis
The static analyzer runs on developers' machines so they can check their code before the commit to the version control system.
It may seem that a fairly straightforward and user-friendly CLI would be enough—we're engineers, after all. But in reality, "to each his own". Some people prefer a specific IDE, while others would sell their souls for Vim.
We need to know how to work with all of this, that' why PVS-Studio offers plugins for all the most popular IDEs used for development in the languages supported by our analyzers:
It might seem like all this isn't worth the effort, but IDE plugins can significantly reduce the time it takes to go from an idea to a result: open a project, click a button, and get the analysis results in just a few seconds or minutes.
As a result, we move all the tedious but important part of integration from the user to our tool: we ask the build system what language, type, and specifics of the project is here, then obtain a list of files for analysis, apply the main settings; display the progress and results; and provide user-friendly access to auxiliary tools.
For example, one way to suppress false positives is to use special comments in the code. If you're working from the terminal, you have to build the whole new process:
- find the warning position in the report file;
- go to that line in the file;
- add a comment with the diagnostic rule number;
-
try to remember how to exit from Vim.
It's not exactly difficult. The IDE plugins streamline this path to just a couple of clicks, without having to read the documentation or switch between tools.
If the IDE integration isn't an option, integrations with build systems can help. For example, you can configure the analysis of Java projects using integrations with Gradle and Maven, and for CMake, there are actually two integrations: one using our CMake module and one using the utility's own built-in mechanisms (official Kitware integration was added in version 4.3.0).
We wrote about the official integration into CMake in a separate article.
Continuous integration
The next major step in using static analysis is to integrate it into CI for automatic analysis updates. This stage involves a wide range of implementation options, which is why the list of integrations here is quite diverse.
For example, among on-premises solutions, there are integrations with Jenkins and TeamCity; among cloud-based solutions, there are GitHub Actions and GitLab CI/CD.
For automation, it may also be helpful if the tool can run in containerization and virtualization environments, such as Docker and WSL.
By the way, automatically running static analysis is important not only in CI but also for regular analysis.
Regular analysis
The regular analysis periodically runs an analysis of the entire project during nightly builds that helps determine whether there are any errors in the project as a whole, because during local analysis and in CI, we usually check only individual updates.
This stage, in addition to the mentioned integrations, requires web dashboards and code quality monitoring systems: the entire project is analyzed on the server, and we need to ensure that the whole team can collaborate on the resulting report.
Plus, this collaborative work involves both reviewing the report and marking up warnings. Managers, meanwhile, can use various metrics to track the results and distribute the work among team members.
A code quality monitoring platform serves as a centralized repository of information on how code quality has changed over time within a project, which is why this tool is of practical use to managers.
Among its web dashboards, PVS-Studio supports integrations with SonarQube, DefectDojo, and CodeChecker.
Specific usage scenarios
We don't forget about development specializations. Why does it matter? The reason is the same as before, we just integrate into other tools that are specific for a certain dev area.
The first specialization that PVS-Studio supports is game development. For game dev projects, we support integrations with Unreal Engine and Unity.
Our tool can be also involved into development of embedded systems. Due to the nature of embedded systems, there's a huge variety of compilers, and they can differ significantly from one another. That's why we strive to make sure the analyzer works with the compilers and SDKs our customers use, including IAR Embedded Workbench, QNX Momentics, Keil µVision, Texas Instruments Code Composer Studio, and others. You can always find the complete list on the website.
Conclusion
We hope we've managed to explain that integrations for PVS-Studio aren't just a checkbox in a checklist—it makes static analysis a convenient and seamless part of the user's workflow.
We use these tools to make static analysis a convenient and seamless part of the workflow.
From our very first Visual Studio 2005 plugin to the present day, we've been working to make PVS-Studio go where our users work.
If you haven't tried testing your project with our analyzer yet, you can start on this page.
And if you're already using PVS-Studio and have something to say about it, you can write to us using this form. For example, we'd be interested to know what integrations you feel are missing from the product.
Clean code to you, folks!
Top comments (0)