In engineering teams/tribes, we often find ourselves stuck in a dilemma of choosing a suitable and efficient code analysis tool. A tool that will provide us all of the essential features and metrics to analyse codebases using best design practices in mind. Teams would want to prevent code problems from being merged by detecting code smells, bugs, and vulnerabilities sooner. Furthermore, they would want to view fast and accurate feedback from their respective pull requests and code merges in their repositories.

The primary goals of software quality engineering are:

• Process control and oversight
• Implementing standards and metrics
• Data collection and analysis
• Test development
• Identification of issues and solutions
• Follow-up to ensure corrective actions

Overview

Over the years, I have worked with many code analysis tools to help developers in various teams such as Codacy, Code Climate, DeepScan, and Sonar Cloud. After spending a considerable amount of time experimenting and setting up Sonar Cloud projects, I realised it stands out from the crowd. It has a comprehensive analysis engine that offers features encompassing all of the aforementioned software quality engineering goals. Some of those features which fascinated me and my team was:

• Pull Request decorators
  • Inline commenting through report annotations
  • Pull request widgets: Provides overall code quality health on your Pull requests
• Repository widgets: Provides overall code quality health on your project
• Scanning Old code vs New code
  • Code Coverage
  • Code Duplications
  • Maintainability Ratings
• Defining custom Quality Gate checks for different projects
• Defining New Code definitions for different projects

Some of the aforementioned features (Quality Gate, Profile, New Code Definitions) are in fact settings that need to be configured in Sonar Cloud. You will need to give your attention to configuring these settings as you will not reap the benefits of fully utilising Sonar Cloud.

We are going to explore the Sonar Cloud ecosystem and how all of its core features come together to provide you a comprehensive code analysis experience.

Sonar Cloud Ecosystem

Projects

In Sonar Cloud, a single repository corresponds to a single project. It is how they maintain a unique set of code quality data and metrics for each repository you have.

Monorepo Support

Sonar Cloud does support monorepo projects. You can create multiple projects, each corresponding to a separate monorepo project which are all bounded to the same repository. This will allow you to:

• Configure one Quality Gate per project
• Receive multiple Quality Gate results
• Read project-labeled messages from SonarCloud

Each monorepo project must have a unique project key in Sonar Cloud, which will be used to uniquely identify your projects using your CI tool.

The standard practice is to have the following naming convention: {organisationName-project-monorepoName}

Project 1: sampleorg-domain-frontend
Project 2: sampleorg-domain-backend

This is useful if your organisation maintains a big number of monorepo projects across various engineering tribes so the projects can be easily identified in Sonar Cloud. However, you can follow any naming convention you see fit that suits your needs.

New Code Definitions

Sonar Cloud follows the concept of Clean As You Code. The core idea is that you focus your attention and effort on new code. As you work on features and improvements, SonarCloud analyses your code on each new commit and alerts you to any code quality problems and vulnerabilities. This allows you to address the issues right away and ensure that all new code added to the project is always clean. You may read their documentation to find out more information.

Accompanying this are New Code Definitions. Setting up the right New Code definition for your project is vital to getting the most out of SonarCloud by determining which changes to your code are considered recent enough to merit your full focus and allow you to use the Clean as You Code methodology when addressing issues in your code. There are several options to consider when configuring your New Code Definitions:

• Previous version: Issues in the code that have appeared since the most recent version increment of the project
• Specific version: Issues that have occurred on a specific version of the project
• Number of days: Issues that have appeared on your code since the specified number of days (A numerical number)
• Specific date: Issues that have appeared on your code since the specified date

When you perform initial code analysis, it does not provide you a "New Code" analysis. Instead, it scans the whole project, providing you with an overall code quality health. As you go along and start analysing new commits, Sonar Cloud will present you with both an Overall and New code quality health analysis (depicted from the picture above).

You can set a New Code Definition either on a project level or an organisation level, with the latter providing you a way of automatically applying the definitions to new projects that are created.

Quality Gates

A quality gate is technically a metric of sorts that informs you whether your code meets a minimum level of quality required for the project. This consists of a set of conditions that are applied to the results of each analysis performed. If the results meet or exceed the quality gate conditions, it will show one of the following statuses accordingly: Passed or Failed. You can define conditions on New Code and Overall Code. Some examples of the conditions are:

• Coverage is less than 80.0%
• Duplicated Lines is greater than 3.0%
• Maintainability Rating is worse than A
• Reliability Rating is worse than A
• Security Hotspots Reviewed is less than 100%

The quality gates are analysed and calculated on Main Branch (master by default), other Branches, and Pull Requests. You can create any number of Quality Gates for your projects and enable them per project, or create a default Quality Gate that will be applied to all projects that have been or will be created.

An example of a customised Quality Gate is shown below:

Quality Profiles

Quality profiles as you may have guessed it are programming language rules that are applied during code analysis. By default, the programming languages that are supported on Sonar Cloud have a built-in profile, called "Sonar way", using the standard best practices that are currently in the market. Although the "Sonar way" is best suited for most projects, there are cases where engineering tribes would want to customise their profiles that best suit their needs.

Branches

In Sonar Cloud, there are 2 types of branch analysis: Short-lived branches and Long-lived branches.

Short-Living Branches

As the name suggests, these branches are meant to be used to temporarily perform analysis on them, usually via pull requests. Short-lived branches are deleted automatically after 30 days with no analysis.

Long-Living Branches

These branches are useful for when tribes follow Agile methodology, utilising Git flow techniques to maintain a set of upstream branches (sprint, release). These branches will remain in your Sonar Cloud project history until it is deleted. Some companies maintain upstream branches for a very long time, hence this option is extremely useful to conduct code analysis on these branches alongside your main branch (master).

Defining long-living branches

Long-living branches are defined on a project level. Simply navigate to your Project Settings > Administration > Branches & Pull Requests. The long-living branches follow a regular expression pattern.

By default, the pattern is (branch|release)-.*. This means that when the name of the branch starts with branch- or release-, it will be considered a long-living branch.

Project Settings

All of the aforementioned concepts and terminologies are in fact project and organisation settings (Quality Gates, Quality Profiles, Long-living branches, New Code Definitions, Monorepo Support). Accompanied with are general settings such as Code Coverage Exclusions, Test File Inclusions and Exclusions, Duplication Inclusions, Source File Exclusions and Inclusions, and many more. You may refer to their documentation to set these up.

Summary

I hope this Part 1 article has provided you with insights on how Sonar Cloud operates and the software engineering quality it follows. Part 2 of this article will provide you a walkthrough on how to set up a Sonar Cloud project with a GitHub repository and perform code analysis using GitHub Actions.

Image Source: https://alexandrebrisebois.files.wordpress.com/2014/05/2011-09-18_code_reviews.png