Projects and Application - How to deal with CodeCoverage, LoC and more

SonarQube Server / Community Build
, ,
1

Hi,

We have a large .NET Core 8 solution that contains different projects:

  • User Frontend built as MVC .NET Core Web Application
  • Backend WebApi
  • Several partially shared components

At the moment our pipelines has several steps:

  1. building & testing the entire solution (*.sln) and analyzing the code as one project with SonarQube
  2. build the Backend project
  3. build the Frontend project

if the first step fails (i.e. failing unit tests or failing the SonarQube quality gate), the second and the third will not run.

But as the solution is growing and more output projects are being generated, we want to create the projects in a parallel process.

I found out that, that there is the possibility of a “meta project” with SonarQube:

But somehow this doesn’t really help or maybe I didn’t understand it.

Because if I build just a part of the Solution with (i.e. Backend.csproj), it won’t run all unit tests so the code coverage will drop to a low number.
As soon as I build the second part, let’s say Frontend.csproj the projects we will have the same issue with the coverage file. I guess it cannot “merge” the “.coverage”? With the solution file, we currently have 100% Code Coverage, but not anymore with project outputs.

What about an issue in a shared component? I guess it will shown in project “Frontend” and project “Backend” - how will the Application meta project containing Frontend and Backend? Will it “know” that it is the same issue or will it simple show it twice?
How about the License? Will the code of the shared component will count twice or even more, when it is scanned by different projects although they are combined with an “Application”?

I could also use exclusions for the LoC license problem, but then the security scan might not work properly (Example: There is a security issue in the shared component that is referenced by Frontend and Backend. I could scan the shared component with the Backend part, where it is not an issue. When scanning the Frontend project, I’d exclude the shared component as it has already been scanned. But the issue is a combination of Frontend and the shared component)

What would you recommend doing?

Version Information

  • SonarQube 10.7 Enterprise (zib deployment, on Premise)
  • Scanner 5.20.1
  • AzureDevOps 2022
2

Hi @DominikTouring

Thank you for sharing the details of your current setup and the challenges you’re facing with the growing complexity of your .NET Core solution.

Based on what you’ve described, I recommend creating three distinct SonarQube projects: one for the Frontend, one for the Backend, and a separate project for the shared components. This approach will allow you to maintain independence in building and testing each part of your solution.

Here are a few key points to consider:

  1. Independent Unit Tests : Given your goal of building the Frontend and Backend projects independently, it’s essential to also have independent unit tests for each project. This way, the quality and reliability of each component can be validated without the dependency on the entire solution.
  2. SonarQube Application : Utilizing SonarQube’s “Application” feature is a good strategy for aggregating issues and metrics across the three projects. Even though each project will have its own quality gate, the Application can provide an overall view of the code quality and highlight issues across the three projects.
  3. Code Coverage Concerns : Regarding code coverage, you may face challenges with merging coverage reports when testing projects independently. You may need to explore tools or plugins that facilitate coverage report merging, or consider maintaining a comprehensive coverage report at the solution level to ensure accurate metrics.

By implementing this structure, you should be able to achieve a more flexible build process while maintaining a high standard of code quality through SonarQube.

Let me know if you would like to discuss further or if you have any additional questions!

3

Thank you @Bachri_Abdel for that detailed response.
Today we actually had a meeting with one of the product managers at Sonar.

Yes, it is possible to separate all into a separate und independent solution, still not exactly what we are looing for (security taint/sink analysis, 100% code coverage or at least an easy way to have the common code linked in all dependend projects).

Let’s see what people from Sonar have to offer, if there is something interesseting, I will post an update here.

1 Like