Preview changes on "Sonar Way" profiles possible?

SonarQube Server / Community Build Product Manager for a Day
1

Hello,

We are trying to update our local SonarQube server as early as possible to benefit from all fixes and enhancements.

With a new version most often updated “Sonar Way” profiles are getting deployed.

All our projects using the “Sonar Way” to not miss any update, but this leads us to unforeseeable breaking builds every time we update. This happens then for all current branches, from development to released branches (hotfix dev).

Yes we are taking them serious and will fix the issues asap, but stopping all development is making a lot of noise, and so it would be much better to see the potential issues and be able to plan the fixes.

Features we would need:

  • Automatically versioned “Sonar Way” profiles for selection
  • Global / Project / Branch switch to select which version to use

How would that work:

  • Active Sonar Way is set to (e.g. 10.6)
  • New update of SonarQube (e.g. 10.7) and so Sonar Way is installed
  • Activate Sonar Way 10.7 for a specific project or branch or also global
  • Start evaluation to see what are the new introduced issues
  • Be able to switch back to a former version to unblock

Branch-specific approach example:

  • Activate new Sonar Way for a feature branch of the develop branch
  • Start fixing in the feature branch
  • Merge to develop branch
  • Activate new Sonar Way for the develop branch
  • Merge to higher branches
  • Activate new Sonar Way for higher branches

Thanks and Regards.

4

Hi @jensheidrich_acn ,

Thank you for reaching out and sharing your concerns regarding the updates to the “Sonar Way” profiles. I completely understand the challenges you’re facing—I’ve encountered similar issues with “Sonar Way” updates, and here’s how I typically manage them:

I version each “used” Sonar Way Quality Profile and back them up. I don’t recommend that my teams use “Sonar Way” without scrutiny; instead, I always encourage them to challenge it or, at the very least, create a copy (Sonar Way 10.7).

Before each upgrade, we conduct benchmarks and tests on staging instances to identify the potential impact of any new or modified rules. Some updates do improve detection and can significantly affect the quality gate. We then share this analysis with each team. For teams where quality gates are not impacted, they can adopt the new rules and the new quality profile. For those facing breaking builds, they have the option to revert to the older quality profile until they can resolve the new issues.

As for the features you suggested:

  • Automatically versioned “Sonar Way” profiles for selection: This could be interesting, but it might lead to an overwhelming number of quality profiles. Managing unused profiles could become cumbersome, so any approach to that would need careful consideration.
  • Global switch to select which version to use: You can set a default quality profile other than “Sonar Way” and perform a bulk change of quality profiles, which might help alleviate some of the impact of an update.
  • Project switch to select which version to use: This functionality is currently available, so I’d appreciate more clarification on what additional capabilities you’re looking for.
  • Branch switch to select which version to use: While this could prove useful for testing, given that you have staging instances, I think implementing this feature might be complex.

One feature I’d find extremely beneficial for managing quality profile updates is a list of projects that currently use “Sonar Way.” Currently, I have to make API calls to retrieve that information, and having it readily accessible would streamline our process significantly.

Let me know if there’s anything further we can discuss or collaborate on regarding this matter.

7

Hi,
Thanks for your extensive and detailed reply.

I have created a script which clones all in-use quality profiles of name “Sonar Way”, which will be executed before the update and sets the clones as “default”.

With this I thought even after the update, the scans just continue as before. Then we can go forth and back on demand.

But dotnet builds did behave a bit unforeseeable. Some SQ rules (S1854, S1871) that have never shown up started to wave. These are rules that have been there before but were “not found” in prior analyses. So just a warning to all, this can happen and can not be undone. I think this is what you have meant with “Some updates do improve detection”.

Switching to the new profiles works forth and back for the sonar analysis step itself.

8

And one more thought regarding “branch” specific profiles request:

As many others we are following an hierarchical branching approach

feature
└ dev
   └ qa
      └ main
         └ release/x

After the update we are no longer able to merge or hotfix without development (fixes) invest on each branch, because builds are failing by the new detected rules immediately.