Which type of branch should be scanned with SonarQube and which type should be gated via a quality gate?

SonarQube Server / Community Build
1
  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)

SonarQube Version 7.9.1
Azure DevOps Services

  • what are you trying to achieve

After working with SonarQube for years I recently took a job offer as DevOps Engineer and I am now trying to introduce the Sonar ecosystem into the software development process of my new company. I thought I had it all figured how to implement SonarQube into the branching and build process - but apparently not so much. I’m looking for advice on which type of branch (defined by Git flow) we should scan with SonarQube and which type we should protect with quality gates for pull requests. I’m having a small existential crisis and could use some input.

  • what have you tried so far to achieve this

The current idea is:

  • Build and scan feature branches
  • create pull requests to develop, scan those pull requests, potentially use a branch policy with a quality gate
  • build and scan develop
  • create pull requests to master, scan those pull requests, potentially use a branch policy with a quality gate
  • build and scan master

Writing it up like this makes it sound not really practicable for some reason, especially with release branches added to the mix. But wouldn’t a developer want to know about issues asap?

How did you implement Sonar into your software development process?

Cheers,
Robin

2

Hi Robin,

Hopefully some other community members will chime in here with their experience and advice. I can offer you a few general thoughts:

I’d start with develop and master, along with any release/version branches. Then I’d layer in PR analysis of everything else.

Regarding your Quality Gate, the ‘on New Code’ conditions in your QG will be automatically applied to your PRs. There are a couple corner cases where something could slip through, but mainly I think you’re covered there.

Does this help?

 
Ann

1 Like
3

Hey Ann,

thank you for your reply.
Is there a reason for not scanning feature branches other than reducing build time?

That is exactly what I am hoping for! :wink:

Cheers,
Robin

4

Hi Robin,

No real need to analyze feature branches since you’re going to analyze their PRs before merge, right?

 
:smiley:
Ann

1 Like
5

Hey Ann,

you’re absolutely right. Not sure why I was unable to realize this myself.
Thank you!

Cheers,
Robin