Skip to content

How to Use SonarQube — Effective Usage of Static Analysis

Technology

Mar 2, 2021 - 8 minutes read

1464 Blog Post Devops Sonarqube 416X300
Marek Strzelecki Technical Architect

A technical architect working with Java and Python technologies. He’s a specialist in graph databases, ontologies, Semantic Web and GIS. Marek is an AWS Certified Solutions Architect (Associate).

See all Marek's posts
1553 Devops Whitepaper News Section 416X300 EN

Share

An efficient software delivery is more than just shipping any solution to the client as fast as possible. It’s also ensuring that you provide the right solution, both in terms of the overall quality and business requirements. Quality control is an indispensable part of the process—software should constantly be validated, verified, and tested. Introducing the DevOps tools and mindset makes it possible to improve the general quality of the solution and decrease its delivery time.

But even with the most sophisticated approach, it’s important to remember that the code always is the foundation of the software. Because of that, keeping it clean, fine-tuned and free of potential vulnerabilities is essential. Most of the issues regarding security, performance and extensibility are detected during the implementation process or later during the code review, where we depend entirely on the experience of our developers. However, due to the complexity of contemporary software, some vulnerabilities stay undiscovered even after extensive testing. They can then manifest themselves long after the deployment.

One of the recommended approaches, which is the one we practise at Objectivity, is to mitigate those issues with keeping our codebase clean and free of design and security issues. You can achieve that by using static code analysis, which as the name suggests, doesn’t need to run the code in order to process it. At Objectivity, we use a tool that offers this feature along with an extensive rule base. It fits our practices and is easily incorporated into our CI/CD pipelines. We decided on the Sonar suite (SonarQube, SonarLint and SonarScanner). But is it enough to just implement those tools, set up a few quality gates and strictly stick to the results of the analysis to then enforce our team to blindly “fix” their code? In our experience — it’s not. So after a few lessons learned, we established some handy guidelines for effective and stress-free usage of these tools. It allowed us to maximise the potential of the Sonar suite, without making our developers hate it with a passion.

How Not to Use SonarQube

SonarQube is a great tool that can help our team with writing better code. It highlights the problematic sections, provides clear explanations, and even proposes exemplary solutions based on similar cases. It also produces a lot of code metrics such as complexity, duplications, all kinds of issues, as well as test coverage. Moreover, it even tries to estimate the technical debt, assuming the time and effort required to fix all the maintainability issues. As it usually is with any kind of metrics, if used and interpreted correctly, they provide the team with helpful information about the current condition of the code base. However, if they’re used as an absolute indicator of the code quality, or even worse — as a KPI — it can have a negative effect on the entire project.

The usual setup for SonarQube in CI/CD pipeline uses quality gates with set threshold values for selected metrics. They’re often consulted with the customer before the implementation starts, or after making the decision to use the static code analysis. If any of the requirements made by the quality gates are not met, the rest of the process is blocked. At first, it sounds reasonable. After all, our goal is to ensure the code quality. The business is also content — it looks like now it’s possible to recognise and measure all the technical work.

As a result, the team isn’t able to release new features or even run any kind of integration tests, unless the code meets the standards imposed by the results of the analysis. It also prevents the team from making conscious decisions about the technical debt. This makes working with the legacy code, which is rarely covered by tests, even more difficult. Sometimes, the developers are forced to bypass SonarQube by hiding changes to the code by using different types of “hacks”, which is the opposite of avoiding the technical debt. The only way to continue the work is to constantly negotiate softening the quality gates requirements by overriding some of the rules. The team feels like they’re losing their autonomy. In turn, frustration rises and the project slows down.

The Golden Rule for Using SonarQube

One of the most popular approaches is to build agile teams around autonomy, where the team feels ownership of the solution they’re implementing. Using the SonarQube analysis results as an absolute indicator of quality diminishes the importance of the teams’ experience and skills. SonarQube, just like any other static code analysis tool, is a technical tool which should work for the team, not the other way around. It’s essential to remember this simple rule while presenting and discussing the purpose and scope of using SonarQube in the development process with the customer.

A mature and responsible team, empowered with the ownership, is able to use their experience and skills to make useful conclusions from analysis results to improve the product quality. At the same time, this approach strengthens the team’s autonomy and promotes transparency. Using SonarQube as a business tool, without the proper technical context and expertise, can cause a series of misunderstandings. The reported numbers have to be properly interpreted and analysed before they can be utilised to their fullest.

Making SonarQube Work for the Team

With this basic assumption in mind, the team can start using SonarQube for their benefit, but as it is with any other development tool, its impact should be constantly monitored and evaluated. Without any experience, it’s impossible to set it up correctly right from the start and use it without any change through the entire project. It’s recommended to start with “The Sonar Way” settings. They’re available out of the box, which allows users to get familiar with the tool. This setup works quite well at the beginning.

Being a part of the continuous deployment process, SonarQube’s configuration should be tuned in accordance with the changes in the project. All the quality gates conditions can be set by the team, starting from the easiest to achieve and gradually becoming stricter — setting a required 90% test coverage for an existing code base is not a good idea. The awareness of the team members will grow along with the quality requirement strictness.

When introducing static code analysis within legacy solution for the purpose of an overhaul, make sure that SonarQube analyses the entire code base, not just the new fragments of the code. It’s a great tool for checking the progress of refactoring. Of course, only if quality gates aren’t blocking the CI/CD pipeline.

The customisation of SonarQube also applies to the scope of the detected issues. It’s defined by the enabled rules, which can be changed according to the team’s needs. The changes can reflect the current focus on a specific topic — if one group of issues is starting to show up more often, additional rules can be enabled to support the developers. The SonarQube rule base can be easily extended with widely used external tools that include code style convention checkers such as Checkstyle or StyleCop.

As mentioned earlier, SonarQube is also capable of estimating the technical debt, using the time needed to change one line of code as the input value. However, this metric can have a great impact, so it should be used cautiously and only after a proper revision. The reliable input parameter must be set individually, because SonarQube sets it to 30 minutes per 1 LOC, and it’s not fit for each type of project. You also have to make sure that SonarQube analyses the proper packages. This is especially important with external libraries, where false issues regarding style can be detected. It greatly impacts technical debt metrics.

Another good practice when working with SonarQube is to export and store project configurations for further use in similar projects.

Achieving Excellence With the Help of SonarQube

Another important activity which should be done when integrating SonarQube into software delivery process is to educate the team about this tool’s purpose, ways of working, difficulties and benefits. The team should have a clear view on how SonarQube works, what is it capable of and how it can help them in everyday activities regarding working with the code and keeping it clean. Most importantly, you should highlight the fundamental rule described earlier — that Sonar tools work for the team. Of course, this also means that every team member should have access to an instance of the SonarQube.

Every detected issue has a permanent link. Users can open these links and leave comments, which adds a knowledge sharing functionality to this tool. Availability is also crucial for the purpose of transparency and the ability to use one of the most helpful features — issue explanation. It can improve the developers’ knowledge about bugs, code smells, vulnerabilities and security hotspots by providing an extensive explanation of every issue including:

  • the risk — the context of the issue and potential consequences,
  • a checklist, making it easier for the developer to determine whether it’s a real issue,
  • the proposed ways of fixing the issue or mitigating the risk.

This way, a team member can expand their knowledge with valuable information — not only which specific piece of code is vulnerable, but also what’s the reason of the issue, and how the threat can be mitigated. Next time, when a similar challenge appears, it can be tackled earlier or fully avoided. The proper use of this kind of knowledge base can be beneficial on the road to excellence.

Impact on Productivity

Introducing a new quality tool into an existing delivery process will always have an impact on productivity. The team needs to perform additional activities to meet the quality requirements, even if it’s not a blocker in the process itself. At first, we observed a slight decrease of productivity while delivering new features, when compared to the process without the use of SonarQube. It was caused by the fact that the team had to get used to the new situation, both in the terms of learning to use the tool, and the additional effort that needed to be made. However, the impact decreased after a few iterations of working with the static code analysis tools. That said, it remained noticeable.

Summary

Static code analysis is a great technique for improving the quality of the code, reducing the technical debt and mitigating the risk associated with vulnerabilities of any sort. Implementation offered by SonarQube alongside its other features makes it a comprehensive platform for automating and supporting team members involved in this task. Unfortunately, when used inappropriately, it can also become a hated and ruthless tool. This short article presented a few basic guidelines for a smooth integration and usage of SonarQube, while promoting transparency and autonomy of the team. Static code analysis can be valuable for many projects. It can provide simple recommendations that are worth taking into consideration. When used properly, SonarQube is a great technical tool that supports the team.

1553 Devops Whitepaper News Section 416X300 EN
Marek Strzelecki Technical Architect

A technical architect working with Java and Python technologies. He’s a specialist in graph databases, ontologies, Semantic Web and GIS. Marek is an AWS Certified Solutions Architect (Associate).

See all Marek's posts

Related posts

You might be also interested in

Contact

Start your project with Objectivity

CTA Pattern - Contact - Middle

We use necessary cookies for the functionality of our website, as well as optional cookies for analytic, performance and/or marketing purposes. Collecting and reporting information via optional cookies helps us improve our website and reach out to you with information regarding our organisaton or offer. To read more or decline the use of some cookies please see our Cookie Settings.